Solkyoshiro

So I know Ork/Makinom has functions for enemy A.I, what I'm wondering is, is it the complete solution? Would Ork play nicely with Emerald A.I/Malbers/etc?

Also, how connected is Ork with the combatant spawners? Could I use an asset like Crux or Quest Machine for spawning as well?

gamingislove

Using 3rd party AI solutions will naturally require some custom work to integrade them - e.g. them calling ORK functionality (like using an action).
This also largely depends on the used battle system, e.g. turn based battles require the battle action to be selected when it's the combatant's turn, while in real time battles you can just use actions whenever. Though, you can also pre-register actions to be used next, so 3rd party AIs can still be used in all systems.

Btw, you can also use schematics to achieve stuff like that :)

As for spawners, the Combatant Spawners are just a component to manage spawning and respawning - there are other ways to add combatants to your scenes.
E.g. you can add a combatant to anything via an Add Combatant component - e.g. allowing other tools to spawn those combatant prefabs.

Solkyoshiro

gamingislove said: Using 3rd party AI solutions will naturally require some custom work to integrade them

I was afraid you'd say that, lol. As far as A.I I just like how preconfigured something like Emerald is.

The tutorials show some decent basic behaviors, but I'd love a tutorial or more in-depth doc on how to make various A.I logic.

gamingislove said: E.g. you can add a combatant to anything via an Add Combatant component - e.g. allowing other tools to spawn those combatant prefabs.

Ah-ha, I was wondering what the Add Combatant component did. So, to make sure I get this right, I just add that component to a third-party spawner?

I want to use Crux's texture based spawning for things like wildlife and low level mobs.

Solkyoshiro

Or, is there a way to use Ork's pooling to do a similar sort of texture-based spawned?

gamingislove

What kind of AI logic are you looking for?
Generally, ORK has 2 AIs, one for selecting battle actions and the move AI to find and move to targets - you can still use some 3rd party AI system on top of that (or e.g. not use the move AI and have that handled by something else).
E.g. you can have emerald handle whatever behaviour you want and keep using the battle AI to select actions.

The Add Combatant component adds a combatant to the game object it's attached to. Your 3rd party spawners will still spawn prefabs, i.e. you add the Add Combatant component to the prefabs you use in those spawners.

I wouldn't use pooling for spawning combatants, as that'll most likely lead to unexpected behaviour due to reused combatants. Also, pooling only reuses game objects and has nothing to do with where/how something is spawned :)

Solkyoshiro

gamingislove said: What kind of AI logic are you looking for?

I'm doing full Real-Time, so I'm interested in AI logic that makes them feel more alive.

Example 1: Wandering/Grazing for wildlife. Wildlife scatters when players are nearby.
Example 2: Enemies circle/strafe the player in between actions (that way it makes it look like they're studying the player during its wait time)
Example 3: Some enemies will retreat and call for backup (i.e alert nearby combatants of the same faction)

gamingislove said: The Add Combatant component adds a combatant to the game object it's attached to. Your 3rd party spawners will still spawn prefabs, i.e. you add the Add Combatant component to the prefabs you use in those spawners.

Well, let me tell you my use case to make sure I have this right.

Quest Machine has spawners that it uses to control mobs for quests. I want Quest X to spawn a Wolf enemy. I'd assign the wolf prefab to Quest Machine's spawner, then I'd attach Add Combatant to that Wolf prefab, select the right Combatant so that it's an Ork Combatant.

If so, then you have truly thought of everything.

gamingislove said: I wouldn't use pooling for spawning combatants, as that'll most likely lead to unexpected behaviour due to reused combatants. Also, pooling only reuses game objects and has nothing to do with where/how something is spawned :)

Oooh? That's good to know. I was thinking if a game object was used frequently like a mob, it was more performative to pool them for garbage collection savings.

Do you think there's a way to do texture-based spawning in Ork 3?

gamingislove

Solkyoshiro said: Example 1: Wandering/Grazing for wildlife. Wildlife scatters when players are nearby.

If wildlife isn't really fighting back, you could also handle that outside of ORK with other AI solutions.
Otherwise, this can be done using move AIs with e.g. random patrol and idle behaviours (schematics) to animate that. Also, Points of Interest can be used for that.
Scattering can be done via the move AI's fleeing setup, i.e. just have the wildlife flee when they notice the player :)

Solkyoshiro said: Example 2: Enemies circle/strafe the player in between actions (that way it makes it look like they're studying the player during its wait time)

That's basically what the chompers in the 3D action RPG tutorials do - they try to get to the player's back via the stop angle setup.

Solkyoshiro said: Example 3: Some enemies will retreat and call for backup (i.e alert nearby combatants of the same faction)

Will look into that :)

Solkyoshiro said: Well, let me tell you my use case to make sure I have this right.

Sounds about right - if the wolf prefab used by the quest machine spawner has the Add Combatant component (set up correctly, combatant, faction, etc.) it'll be a regular combatant when spawned.

Solkyoshiro said: Do you think there's a way to do texture-based spawning in Ork 3?

Maybe via schematics - Makinom 2 has the Texture Terrain Fork node to check textures of a terrain at a position, naturally that only works for terrains.

Solkyoshiro

gamingislove said: Scattering can be done via the move AI's fleeing setup, i.e. just have the wildlife flee when they notice the player :)

Excellent. This is essentially using the Flee setup example from the 3d Action Tutorial, yes?

gamingislove said: That's basically what the chompers in the 3D action RPG tutorials do - they try to get to the player's back via the stop angle setup.

I've had a little problem with understanding how to stack A.I in a good way. I started with the Chomper A.I from the tutorial, but I added some of the things from the Turn-based A.I and they went dumb. I'll play around with it and post an example if I have problems.

gamingislove said: Maybe via schematics - Makinom 2 has the Texture Terrain Fork node to check textures of a terrain at a position, naturally that only works for terrains.

Sweet! I'm going to give that a try. That's quite exciting. My goal is to set up texture-based spawners for non-combat wildlife, more randomized combatants, and procedural generated levels, so terrain textures is perfect.

Here's what I imagine:

As the player moves through a scene, let's say a forest, I have spawners set to textures. Grass for various wildlife, and enemies on road tiles. Use the Combatant Despawner component to make them spawn and despawn around the player.

Then I'd have special spawners with a low chance to spawn, say 10%, that would spawn special/unique enemies or special merchants.

My goal is that I only have to set up spawners for special events and places outside of terrain textures.

gamingislove

The 3D action tutorial doesn't use flee, it's using caution, which is a mixture of hunt and flee (i.e. it keeps a defined distance) - but the setup is similar. Fleeing will just run away from the player.

The battle AI is used in the order they're added to the combatant (or in general settings) - and the first useable action will be used. So, if you have a base attack as the first battle AI that's added, that's all the combatant will use.

Solkyoshiro

So I'm trying to use the Terrain Texture Fork and I have a few questions. I don't quite understand some of the options.

- Game Object Direction:
The direction from one game object to another (i.e. subtracts the game object's position from the other object's position).

- Shot Velocity:
Calculates the velocity needed for a shot from a position to a target.

- Random Inside Sphere:
A random point within a sphere with radius 1.

- Random On Sphere:
A random point on the surface of a sphere with radius 1.

- Random Rotation:
A random rotation.

- Random Rotation Uniform:
A random rotation with uniform distribution.

This is what I'm working with so far. There's no Radius option which I kind of expected. Essentially I just want to set a radius around the player that will spawn combatants on the selected terrain textures.

gamingislove

I guess you're talking about Vecor3 Types? None of them are needed here - what you need in the Terrain Texture Fork is just a position, e.g. from the player.

If you want it to be a random position around the player, first store the player's position into a variable and add a random offset to it. You can do that via a Change Variables node:
- first, set a Vector 3 variable to Game Object > Game Object, using the player's (or machine's) game object position
- next, add to that variable a Value > Set Axis where you can use Value > Random on the X ans Y axes to add a random offset to it

The Terrain Texture Fork simply uses that variable as position.


As for the types you asked about:
- Game Object Direction is just that, gets you the direction from one object to another, e.g. to move into that direction
- Shot Velocity calculates the needed velocity to shoot something and reach a defined target, e.g. it's used in the 3D action RPG grenade schematics to throw the grenade where the player clicked
The others use Unity functionality for randomly creating Vector3 values - see the Unity API.

ChimpLogik

I am also currently working on a Real-Time game and trying to integrate ORK3 with a 3rd party AI solution (Behavior Designer).
The idea was leveraging the power of ORK3 for all my combat needs while switching to the external AI for non-combat tasks, like wandering and grazing wildlife.

What would be the best way to smoothly transition a combatant in and out of combat so I can decide which AI is driving it?
And especially going from non-combat to combat, what are the things I would need to set (or reset)?

RustedGames

@ChimpLogik I would say setting up conditional combatant prefabs, one prefab for Field (no Battle) and another prefab dedicated to Battles (less third party components on it)

gamingislove

You can also use Component Manager components to enable/disable components on a game object based on conditions. Using conditional prefabs might look strange when the prefab is switched out while the enemy is coming at you :)

ChimpLogik

Oh wow, the Component Manager looks such an interesting tool! Now I just have to learn how to use it. I have few questions, I hope you don't mind :)

1) What would be the best component in Component Manager>Components to enable/disable the ORK AI so it can be driven by the 3rd party AI?

2) How can I set via script the Editor variables to drive the Component Manager conditions?

3) How can I notify my code when the combatant has no more enemies in range/is not in a battle anymore so I can pass the token back to the 3rd party AI?

gamingislove

1) Hm, that's tricky - I'd say that's probably not handled via component managers.
Since the battle AI is only used when the combatant needs to select actions (i.e. in battle), the only thing you need to enable or disable would be the move AI - and here you can already set up a separate move AI for battles.
So, theoretically (haven't tested it), if you use the None (unselected) move AI as regular move AI and a separate (selected) move AI for battle that should do the trick.

2) That's pretty complicated - you'll have to create multiple classes/arrays and set them up correctly.
I'd recommend to check out the component manager's code for that.


3) Register to the combatant's battle state event handler:
combatant.Battle.BattleStateChangedSimple += YourFunction;
YourFunction has no parameters.
If you need to also get the combatant passed on, register to BattleStateChanged instead with a function that has a Combatant as parameter.