Rocketed so hard it broke the camera

Who taught that AI to fire a Carrocket Launcher?!

I’d expected to need to specifically code for each of the power-ups.  While that may be true, I just got beaten by the AI who accidentally collected a Carrocket Luancher power-up!  He blasted me off the screen!  Nice! 😀

This reminded me I need a new way to check players are still in-play.  Think I’ll add a infrequent Invoke() to check position validity within a per-arena ‘Bounds’.

(a few days later with no dev due to parenting load.)

I just integrated the WorldBounds system and it seems to work.  Snowmen are removed up to 0.5 seconds after escaping play area.  Decided not to apply to Shots, etc since they have time limitations anyway.  Removal timing and Bounds will need tuning per-arena since, in some, the play area intentionally has no floor so that Snowman who miss the edge can be seen watched falling like Wile E. Coyote to the sounds of slide whistle for a bit before dying.

Play-testing the WorldBounds change, I noticed another amusing bug.  In the interest of knocking a Snowman out-of-bounds, I gave myself the Carrocket Launcher, charged-up a full power carrocket and fired at the AI.  Amusingly 2 things happened:

  1. I’d forgotten the AI had a cricket-bat which can bat back to the sender, carrockets (or most other projectiles) and it happened to swing at that moment!
  2. that carrocket hit me so hard, it broke the camera!
    By that, I mean the camera was off-kilter due to camera-shake losing something and leaving the camera un-centered!
    Obviously this is a bug to fix but it also made me think about making super-powerful hits add a camera crack that takes a while to be repaired!  Hmm!  Silly idea?

(later)

A related camera issue, I was musing on that problem of the camera being inside geometry s in the picture.  The top shows game-view where the player would think they can move towards the camera.  The bottom shows debug view where we can see the player’s actually against a front wall.

Screenshot 2016-05-03 20.48.49.png

I’m wondering if I can re-use / adapt something I did for the Romeo & Juliet game we made for a previous Ludum Dare 30.  There, the world geometry would be faded-out when the camera entered it.  In SnwScf, the camera knows its ‘target’ (by a constantly calculated bounding volume consisting of all players and other CameraTargerables).  The centre of this volume is where the camera is aiming.  If I line-cast from that point to the camera’s position, any static geometry (and maybe other physics layers later) should have some action taken.  Romeo & Juliet did a simple swap to a transparent version of the shader and faded out.  It could get away with this since its a very simple world — all potentially blocking models were the same shader.  SnwScf will need to be smarter.  Perhaps:

  1. A general purpose default which checks the Shader being used and does a reversable swap
  2. A special-case per-shader action in a lookup table
  3. Optional explicit logic that takes precedence

All these will need to be reversable to ensure we don’t leave lots of models with un-shared materials (which breaks dynamic batching).  I suspect I’ll need all the options

Mountain biking this afternoon.  Not been for ages due to knee injury.  Would rather it weren’t on a #ScreenShotSaturday but I’ll try to make it up later.

Aside: Still have an ongoing assertion failure related to Shots being destroyed shortly after creation and their coroutines still trying to be active.  Added logging of which snowman is charging which Shot so can later determine cause of error.

Just seen an interesting error.  A* indicates it failed to find a path to its destination which means the AI cannot route to its desired destination.  Interestingly, A* logged a warning about the problem including mention that it had searched “all 2 nodes of the graph” (the graph should have several hundred nodes!).  I wonder if the problem is that, while rolling, the snowy floor is modified and an update to the A* graph is requested.  My experience of the A* graph updating so far has been that it’s pleasantly quick so I haven’t moved it onto another thread yet (just an option in the Editor).  Maybe if the timing is sufficiently unlucky, could the graph updating result in no graph when the AI requests a routing such that the graph appears much smaller — like 2 nodes?  (or is it something else entirely?)  Continuing from the error I saw a total of 13 instances of the error before routing requests succeeded.  Perhaps this is sufficient.  But perhaps I might need to implement something that spots repeated routing failures and switches to a direct movement approach until routing starts succeeding.  The Pathfinding component has probably retained its last successful path but, due to the pathfinding error, the Task (MoveSnowmanWithPID) is returning failure so something else can be tried… in this case, itself again.  Hmm… perhaps that’s best but the BT could keep a routing/movement failure count and do direct navigation if necessary.  I’ll leave as is for now and see if this happens much.

Whoops, another bug — the AI is a really good play-tester! 😀
Switching weapons while charging a Shot results in the Shot being Destroy()ed along with the Weapon — which breaks the pooling (of the Shots).
Ahha, as I thought, I had handled this situation — I was correctly depooling the Shot however Weapons re-parent Shots to themselves while charging so also needed to add the restore-parent call to the droppedBy() code.  Yep, that fixed it.

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s