[RAIN Starter Kit] Basic Behaviors

[primeKeymaster]

You can specify a navigation target in an Expression field via

navigationtarget("target name")

You can move to a navigation target (returns success when it gets there) via
— MOVE (Move Target = navigationtarget(“target name”)

For #4 - yes, we understand the utility of being able to treat waypoints as navigation targets. We do plan to update the implementation of waypoints so that you can do it (and get additional information about waypoints while navigating them).

[BrokenHelmetParticipant]

OK so I gave it a try, however it was only half successful. In both the case of your (@Prime) suggeted BT and that of @CodersExpo in the Mecanim + RAIN tutorial, the NPC will move well until they get to the last target. If they are on a “loop/ping pong” LOOP TYPE, that is cool.

However, if there is only one target (or the final destination) and the NPC has root animation, they will keep moving, then RAIN kicks in and makes the NPC move back, so the NPC just “circles” the final target, but doesn’t actually stop.

I tweaked it a little to see if I can get this desired result. This is where I have landed (edited severally as I was still testing while I wrote this reply)

SEQUENCER(“root”)
— TIMER (“InitializeNPC”) 3 sec [NPC is generated at runtime, so she needs a sec to get ready :D]
— EXPRESSION (isMoving = true)
— SEQUENCER(repeat forever) [so that it doesn’t go all the way back to the root]
— PARALLEL (succeed & fail ANY. Tie breaker SUCCEED)
— — SEQUENCER
— — — MOVE [navigationTarget(“Target_1″)]
— — — EXPRESSION (isMoving = false)
— — ANIMATE (MOVING) [“walk”] (repeat FOREVER/?NEVER?)
— — CONSTRAINT (isMoving == false)
— — — ANIMATE “idle” (repeat NEVER)

So this worked. However, I felt as though it was too bulky and there must be other easier (lighter) ways of accomplishing the same, i.e. when the NPC reaches the target destination (MOVE(to target) RETURNS a SUCCESS), the Idle/Stop animation is played…

And also, how would you use “MOVE(to target) RETURNS a SUCCESS” to the CONSTRAINT node, thereby eliminating ‘EXPRESSION “isMoving = bool”‘ all together?

• This reply was modified 8 months, 1 week ago by  BrokenHelmet.
• This reply was modified 8 months, 1 week ago by  BrokenHelmet. Reason: Got the solution and had to rewrite the entire post (oo,)'

[primeKeymaster]

Are you using Mecanim Root Motion for turning? Sometimes that can cause circling problems - if the turn radius is too large the AI can’t turn tight enough to reach the target. In those cases, we do one of two things:

1) Write some custom code to detect situations that require a too-tight turning radius, then override root motion rotation.
2) Override root motion rotation anyway. You can let the mecanim animation do root motion as normal, but RAIN can override the final rotation and make tighter turns. This is a checkbox on the Mecanim Motor.

If you are using Mecanim for animation, then you don’t need to use the isMoving or the BT nodes for controlling the animations. That’s probably the preferred choice.

[BrokenHelmetParticipant]

No, I had already tried the Mecanim Root turning, and because it did not work out, I leave RAIN to control the turning process. Well, only until I learn more about RAIN, then I will re-explore the idea.

If you are using Mecanim for animation, then you don’t need to use the isMoving or the BT nodes for controlling the animations. That’s probably the preferred choice.

What would you suggest?

[primeKeymaster]

I would suggest setting up your Mecanim State Machine to automatically transition between walk and idle animations based on the AI speed. You can add a parameter to the Mecanim Motor (pulldown near the bottom of the inspector) for Speed. Then use that parameter for state transitions and to control the playback speed of your walk animation.

[BrokenHelmetParticipant]

Oh, that’s already set up 😀

I have the parameters for both direction and speed set up, and the State Machine is transitioning well. In addition, the animations for walk forward, left, right, backwards and the running counterparts are all ready and connected.

I like using Animation in the BT because I’m still working on the animations speeds I would like to use, and the final speeds that I will use may vary. With that said, when the BT is simply reading from the available animations in the AI Rig, I won’t have to change any values in the BT or (scripts), if I simply want to make a point (.) something difference in my walk or run speed, especially if the script or BT gets super complicated.

I hope that makes sense, or maybe I’m over-thinking it?

Anyway, in the end, whether we decide to use the “Mecanim > Set Params” in the BT or just animate (and both seem to be working), either would still present us with the same situation; we would need to detect that the NPC has reached the “final” target, so that we can tell it to stop…

[primeKeymaster]

Actually - I don’t think the two situations are the same.

When using an animate node in the behavior tree, you do need to specifically manage what state you are in. You would then put your animate nodes in a constraint and let them run until they shouldn’t. Essentially:

PARALLEL
— EXPRESSION (isMoving = true)
— SEQUENCER
— — MOVE
— — EXPRESSION (isMoving = false)
— CONSTRAINT (isMoving == true) (repeat forever)
— — ANIMATE (walk)
— CONSTRAINT (isMoving == false) (repeat forever)
— — ANIMATE (idle)

If you use a Mecanim state machine based on your speed parameter, then you don’t need any of that - just a Move node. The state machine deals with the rest (when you aren’t moving your speed is 0 and it should transition to idle, when you are moving speed is > 0 and it should transition to a walk anim)

[BrokenHelmetParticipant]

Just a move node? Not a”Set Params” node?

I thought, (based on my original BT) it would go a little something like this (no pun intended):

SEQUENCER(“root”)
— TIMER (“InitializeNPC”) 3 sec [NPC is generated at runtime, so she needs a sec to get ready :D]
— EXPRESSION (isMoving = true)
— SEQUENCER(repeat forever) [so that it doesn’t go all the way back to the root]
— PARALLEL (succeed & fail ANY. Tie breaker SUCCEED)
— — SEQUENCER
— — — MOVE [navigationTarget(“Target_1″)]
— — — EXPRESSION (isMoving = false)
— — SET PARAMS (param name “Speed”, value = 1 [or whatever], damp = [whatever])
— — CONSTRAINT (isMoving == false)
— — — SET PARAMS (param name “Speed”, value = 0, repeat NEVER)

This one, essentially changes from the animate node to the set params node. Then based on the figures being passed, the state machine will do the rest.

However if you could just use the move node to accomplish all this.. I am super curious how that would work, because it makes the BT quite light and flexible… Basically, all the user (we) have to do is indicate the destination target and everything else figures itself out…

[primeKeymaster]

Yes - just a Move node. That’s a typical setup for us with regard to locomotion animations (walking, running, strafing, idle). We transition those based on parameters passed into Mecanim via our Mecanim Motor. We typically only use the SetParam nodes to trigger individual single-shot animations or to set specific animation states.

Consider the following state machine for example:

Idle --> Walk [trigger the transition when Speed > 0]
Walk --> Idle [trigger the transition when Speed < 0.001]

We would usually make Walk a Blend State that can manage varying speed based on the Speed parameter, but generally this works even with a simple Walk animation state.

[primeKeymaster]

Keep in mind that one of the advantages of Mecanim State Machines is that you don’t have to explicitly manage the starting/stopping and transitions. It’s one of the main reasons we prefer to use Mecanim, even with legacy animation setups.

[BrokenHelmetParticipant]

I think I am beginning to understand.

Basically what you are suggesting is that, while using a move node, the “move speed” will be transferred to the “Speed” parameter in the Mecanim State Machine, thus affecting the animation to be played AND actually facilitating the actual movement. After the target reaches the nav target, the “move node” (now no longer needing to move the townie) automatically reverts to 0, and the NPC stops, both in animation and actual movement.

Is that about right?

[primeKeymaster]

Yes, that’s the idea.

When using Root Motion animation via Mecanim, the state machine really does control both animation and movement. In that case, the Move node is simply providing information to guide the state machine to play the right set of animations at the right speed.

When not using Root Motion animation, the Move node and the Motor directly control movement, but then pass the parameters to the state machine so it can play matching animations.

In either case, the Move node and Motor are controlling the Speed, Turn Angle, and other Mecanim Parameters based on where and whether the AI wants to move.

[BrokenHelmetParticipant]

OK, I think I have the basic idea down, and now that we have the theory, I believe it is time to do it practically 😀

I gather we have to make a small script to be able to pass this information from the move node, which is in the BT, to the Mecanim State Machine.

Now, it seems as though RAIN has a bunch of different scripts that can be used. However, I am thinking that a customized script which we can add later to the AI Rig would be the best way. (I say this because I was introduced to Customized Scripts long before any other). Maybe an action script? I’m not sure…

Though, just to be clarify, I’ll mention this. It would make sense to use a script type that allows us to add on future animations, and do further tinkering. This is, for example, interacting with the environment and making more complicated decisions (wandering, making dynamic navigation meshes etc.)

In the Starter Kit, I saw this was handled exclusively by the Custom Action Scripts, being called by the Custom Action node. So I am not quite sure the best one to use. Would please elaborate on the various scripts (or a link would work just as well)

[primeKeymaster]

I gather we have to make a small script to be able to pass this information from the move node, which is in the BT, to the Mecanim State Machine.

No, you don’t need a script.

The Mecanim Motor does this for you automatically. Movement information is automatically passed through via the Mecanim Motor, and any other parameter data can be passed directly using a Mecanim->Set Parameter node. Just make sure you have the RAIN motor set to Mecanim Motor and the RAIN animator set to Mecanim Animator.

The Starter Kit only uses 3 custom actions. The purpose of each of those scripts is simply to select a position in the world that the AI wants to move to. They aren’t used to manage movement or animation. Custom actions are, as you said, a good place to add code for more complicated decisions.

• This reply was modified 8 months ago by  prime.

[BrokenHelmetParticipant]

No script? OK, you have lost me a bit.

Just so we are on the same page, let me put forward a super simple BT. The NPC only has to head over to a single navigation target and stop.

Let us assume a “Speed” of 1 means a full walk animation.

SEQUENCER (“root”)
— MOVE [Move Target = navigationTarget(“target1″), Speed = 1]

This should simply get the NPC from the start position to “target1″, and will stop moving as soon as it gets there (No animation is currently playing during this sequence).

The AIRig Motor is currently set to Mecanim Motor, with a speed of 0, and the animator is set to MecanimAnimator, as per your instructions above. (Both the “Apply Root Motion” in the Animator and the “Use Root Motion” in the AIRig are currently NOT checked)

So how exactly, do we tell the AI to set the State Machine parameter “Speed” to follow the Move Node “Move Speed”? I am trying everything, and it is not quite working out.

[Author]

Posts