AI getting stuck

The Snowman AI gets stuck sometimes when moving tactically.  Perhaps switch to both A* path and PIDCtrl for all movement?  (background: they’re using direct movement in vector of desired movement at the moment).

Atm, roll has 2 big differences:

  1. It does 1 pathing then
  2. the move action can work the path until completion (by returning TaskStatus.Running).

In contrast, move & shoot continually:

  1. determines destination
  2. moves towards it.

In contrast, the AIPath supplied with A* project does its own periodic repathing by taking a destination point (that might be updated).
To use pathing, M&S would need to periodically:

  1. determine new destination (perhaps using pathing to determine ‘good’)
  2. path to destination

Probably a good time to investigate the Tactical Pack! (and updating it to A*.)

(a week passes where I work on updating Behavior Designer A* Integration pack from a start the author Justin began — see notes elsewhere.  Here’s the thread where we mooted the idea.)

So, Tactical Pack uses a single Task per tactic to do all of the work bar actual pathing which it delegates to the pathfinding solution’s default approach — for A*, the AIPath or RichAIPath.
As noted above, those have an updatable destination point and a repathing rate.

Perhaps we could do similarly by:

  • using MoveSnowmanWithPID
  • set inDoPathfinding
  • unset ‘useRoll’
  • add repathing rate — which tactical movements would have as very small.
    Background: Snow gathering roll would have this as a very large value but it unsets inDoPathfinding since it uses a different pathfinding approach — PathToMaximizeSurface which analyses data embedded in the A* grid from some preprocessing while generating to convey how likely rolling over this part of the A* grid is to get a snowman some more health.

What experiment could I do to determine whether this would be a good course of action?

Gonna try switching my “Move To Point” subtree (an external behavior tree) to use MoveSnowmanWithPID as above.  I’d expect it to work but with no path updating yet.

Yep, works surprisingly well since, when the snowman runs low on health, his ‘reactive planner’ / ‘goal oriented’ behaviour tree design to interrupt his current action (subtree) to path and roll for snow health which causes the attack action (subtree) to be restarted.  Of course, the ‘circle the player’ aspect of this is lost due to the lack of repathing so let’s fix that.

Again I’m struck that I’d like a “Find Usages” facility in Behavior Designer to find where a Task is used in all of my behavior trees!  (and I use lots of external trees so it’s not a crazy ask!)  Luckily, since (a) I keep them all in one hierarchy of directories, (b) I’ve opted for JSON persistence and (c) I’m master of UNIX command line, I’ll just do some quick grep/awk magic to tell 😀

$ find . -iname '*.asset' | xargs grep -aE 'MoveSnowmanWithPID|MoveToWithForceAndPID'
./Snowman/RollForSnowHealth.asset:                                      "Type":"MoveSnowmanWithPID",

Yup, just the one usage.

We’ll also need to add a State for TravellingAndPathfinding so it doesn’t stop to wait for the next path (currently the states are { Unknown, Uninitialized, Pathfinding, Travelling, Arrived, Finished, Error } ).

Decided to move over to my AIDev project since iteration time is much lower.
Sadly, since I’ve updated to Unity 5.3.4, I need to update all the same things in that project as in SnwScf — namely the excellent Unity Test Tools (which is now more integrated into Unity Editor anyway — such that it has DLL collisions!) and Behavior Designer including  redoing this bug fix!  Along the way, fixed a bug in my break-on-change for SharedVariable (when there are no global variables, the GlobalVariables.Instance is null!).

Hmm… with the updated versions, my AIDev project creatures don’t move at all!?  Great.  Guess something happened with the upgrade that’s messed-up some target.  Perhaps the inOptPidController or PathfindingHelperAStar is getting a value from serialization rather than GetComponent()?

End of section for now — afternoon with the kids.  I might continue this later this evening after they’re abed.


[ Decided it’d be OK to continue a post — as long as it’s already published. ]

So, it looks like a change to Behavior Designer I’d suggested, which the author agreed with but made a slightly different way isn’t working properly.  Ahha, it’s not in 1.5.6 — guess I missed it from my patch work?  Yep, that was it.  Hm.  That’ll teach me not to use my usual patching process and just copy over files after a quick diff.  Better go do the rest!

Rest looked fine.  Odd.  Investigated why didn’t see originally.  Worryingly undetermined.  Have to leave for now with note here to remind if see again.

Modified MovementController to be an abstract super-class with MovementRigidbodyController and MovementCharacterController concrete implementations.  Updated MoveWithControllerAndPID to use move information from its MovementController — specifically moved position and velocity into MovementController too.  First run was *veeeery* odd — stuttery jerky movement … which eventually started moving towards its goal — ahha, PID Controller values need re-tuning for CharacterController (rather than rolling Rigidbody).  Set to P:1, I:0, D:0 and it looks pretty good — followed the path perfectly.

Next oddity: it’s not finding its second goal?!  It’s stuttering re-pathing to the shelter.

Background: The test-scene uses the old “find food and shelter” scenario.  The food is tagged “Food” and the shelter is tagged… wait for it… “Shelter”!  Right?  I know!  Amazing.

Each are sought by an included instance of an external behaviour tree “DetermineAndPathToClosestTaggedItem” using Behavior Designer’s overriding variables facility.  Worryingly, when inspected before running, they show the correct string but at runtime, the food-seeking one is showing “Shelter” and the shelter-seeking one is showing a blank!?.  Uh oh, I’m 90% sure this used to work — I /miiight/ have an extra layer in here but don’t believe so.  Could Behavior Designer 1.5.6 has broken something here?  Let’s ask.

Well, I’m due to be at school with my 1.5 year old tomorrow morning who’ll wake at 6-6:30 so think that’s all for tonight.  The mystery will have to last till tomorrow.


2 thoughts on “AI getting stuck

  1. Pingback: AI getting stuck, part 2 | Snwscf's Blog

  2. Pingback: AI getting stuck, part 3 | Snwscf Dev Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s