Dev Blog 23: The Kindler

While continuing my work on various fundamental game improvements, I took steps toward the new weapons that I mentioned last blog post.  I decided that a red wiffle bat had to be one of the primary weapons since many of us had one when we were little.  Having options for weapons meant that the code had to be adjusted so that it had a notion of what the player has equipped and like most things this required new graphics and animations.  The old attack graphic was always temporary, it was just a blocky brown sword thing. I converted this weapon into a stick since most children that pretend fight will often use one to represent their sword or light saber.  I wanted the weapons to be distinct but still even. So I adjusted the attributes of the weapons and each has a unique attack range.  The stick does a sweeping arc attack which can hit targets more easily.  The wiffle bat will be more of a straight line attack, which is slower, but does more damage and will knock the enemy further away when hit.  I'm still tossing around ideas as to other unique weapons and these attributes could change in the future of course.


I took the time to add a new enemy type. This one should be familiar, as it based off of the Plug. The Kindler, a cousin to the Plug, carries a small lit candle on his back.  Is it placed there or does it grow naturally? I don't know.  But it leaves a trail of smoke when the beast walks around and should alert the player, along with the Kindler's red skin that this creature uses fire.  I added logic for the Kindler and future actors to launch/spit projectiles.  In this case, the Kindler will occasionally shoot a fireball in the player's direction.  

While working on the logistics of shooting a fireball I realized that I'd need to know when in the animation that it should actually trigger.  Unity provides AnimationEvents, which are signals you can hook up in the animation that will run a function. While this is great, the UI to interact with this is quiet annoying.  You are presented a list of functions that the object has access to and you have to pinpoint the one you want.  I figured I could make a one off function every time I needed it and then do the same tedious hook ups so that all the things that need to know about an animation event get told. But that would probably lead to a lot of duplicate code and reinventing the wheel each time.  So instead I made a system for animation messaging that hooked into my animation controller that I wrote about way back in Dev Blog 7: Animation System.  Basically, I have one single AnimationEvent that Unity will fire for all my animations, the messenger system I wrote will pick it up, and pass on the event to the systems that care about it.  So in this example, when my projectile firing AI wants to know when a good time to shoot a fireball is, it'll tell the animation messenger that it wants to be told about any projectile events and then starts the animation.  When the animation gets to the frame where we want to fire the projectile all the stuff I just mentioned occurs and the end result is that the AI is told to fire a projectile.  The AI can then use its information to shoot the correct projectile, fireball, arrow, etc.