AI getting stuck, part 5

Continuing from yesterday’s oddity of the assertion failure, a half day today.

Continuing to think about it, I don’t believe MoveSnowmanWithPID should need a Rigidbody since it’s all delegated through SnowmanInputController and SnowmanRoller.
(funny how one thinks one is making progress in the night but morning brings clarity, eh.)
Makes me wonder why it was working before but let’s see if this fixes it.
MoveToWithForceAndPID should really be an abstract class MoveTo with MoveToWithForceAndPID and MoveSnowmanWithPID as concrete subclasses.  This would be much easier if this was just code — with all the serialization mess of values persisted in behaviour trees, etc it’ll be a bit of a quagmire of changes.  Probably best to manually record the values first (screenshot them all).  Not much time right now so gonna leave as is.  The cost is minor technical debt + an unused Rigidbody variable in the Snowman version.  Not too bad.

Yep, that fixed it.

Right, time for some play-testing.  Started game, played for a bit.  Turned down some logging.  Yep, AI player is not a complete push-over but… when I decided to actually push him — get up-close and attack — I got a couple of oddities!  Once, I pushed him while he was rolling and he got fatter after entering a narrow canyon and got stuck!Screenshot 2016-05-03 11.54.41.png

That’s actually kind’a reasonable!  The AI kept wriggling trying to get out but all the same as a human player.  Guess I would know to try shooting to reduce my size.  Perhaps something to detect and implement but perhaps it’s also funny to let the players spot and attack the sitting fat duck!

The other pushing oddity, I somehow pushed him out of this world!  Checking the debug view, it’s a bit of a Laputa moment!Screenshot 2016-05-03 12.43.47.pngOh!  Googling for a link, I didn’t know Lapupta was originally from Gulliver’s Travels!?

Sidebar: GameDev intro background: Physics keeps you in!

Anyway, this sort of error is pretty common in 3D game development.  If you think about it, all games take place within some 3D geometry that bound you in but, if you could look at it from outside, you’d see it’s all floating in an endless (*1) space with the skymap behind.  *1: endless within the bounds of computers’ floating point representations!  (A skymap is a static picture for the background — often a cubemap — a picture that wraps all the way around.)  So you’re kept in by the physics system — a series of Colliders and a collision resolution system.  If you escape that accidentally, there’s usually something to ensure you don’t drop forever but are considered dead and restarted / whatever.  I have such a system in my game but my push was somehow strong enough to bypass it!  Good to find now!Screenshot 2016-05-03 12.54.58.png

The green boxes visible here are the Colliders.  They overlap to ensure nothing escapes!  To top it all… well, to bottom it all, that giant bottom Collider should have killed the Snowman!  I wonder what happened!

The bottom Collider is a Unity Trigger with a script WallUnderneath that attempts to reset onto the ground or kills if too far / no ground.  It didn’t even get touched implying the physics system moved the Snowman past its Collider in a single step!  If the pushed snowman was rolling, perhaps something is badly tuned?  (I mostly tuned pushing for when they’re standing and against my physical objects — perhaps the values are too big for rolling?)  I’ll have to investigate this further since it could potentially really break the game!

Anyway, that’s all for this morning.  Maybe an hour tonight.  TTYL.

Time for an evening play test!

Camera-relative steering

Becoming increasingly convinced that controllers should move Snowen relative to camera orientation.  I’d previously discounted this since the camera is expected to be generally facing along the positive Z-axis.  However, it is possible to get the camera pointing up or down the X-axis or even along negative Z-axis if enough of the players move fast enough.  I’ve had this suggested only once by a player — during football mode — which makes some sense since the players rush from one end to the other, together (along with the ball which is also a CameraTargetable).

Actions when AI unable to reach

Had a couple of moments where the AI couldn’t route to the destination it wished.  I’ve written this to pause for now since I want to investigate.  In these cases, it was the AI having been shoved out of the world.  (Oddly enough, can’t navigate when it’s falling through space!)  That said, I could see valid situations where it might happen.  I wonder what I should get it to do — sitting doing nothing isn’t an option.  Thoughts welcome.  I guess the AI should appear to switch to a different approach.  Maybe one or more of:

  • Try harder:
    • find a way to flush them out, e.g. rocket launcher the area!
  • Wait:
    • gather health if low-ish
    • gather other benefits
    • find a tactically advantageous position to wait
  • Give-up:
    • select a different target if possible

(These are the sorts of things I’d probably do if I couldn’t get to my opponent.)  Nicely, given the goal-oriented / reactive planner design I implemented for the AI, this can just be placed in as lower-priority goals with appropriate pre-conditions.  They should then become active whenever higher-priority goals (e.g. attacking, desperately seeking health) aren’t necessary/viable.




One thought on “AI getting stuck, part 5

  1. Pingback: Rocketed so hard it broke the camera | 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