Animation Logic System Re-write

Admittedly, I’m still learning JavaScript and feel a lot more comfortable working within the wonderful Phaser framework.  As I learn and add new functionality and features, I am finding myself backtracking a little bit in order to fix and rewrite code that could definitely be considered “spaghetti.”

I’ve read and also feel that JavaScript is a very “dynamic” language, even when compared to lower level languages like C.  Because of this, there are several ways to write the same exact line of code.  You can outright call functions or you can assign functions to variables which immediately call the function and kind of attach its properties to that variable — and with Phaser you can play animations in a few different ways.

If you have one animation, it’s easy to manage, but as the game progresses and I begin to bring life into the monsters, the need for a much more comprehensive animation system needs to be done.  Starting out, the only animation within the sprite itself (not counting its raw movement), was an attack animation.  Adding idle animations such as blinking and movement animations like a jet-pack fire propellant is becoming a lot more important.  Keeping these animations working together like a well-oiled machine is important to maintain a level of immersion among gamers.

When writing a logic system around Phaser’s existing Animation Manager, it’s important to understand all of its behaviors so you can code accordingly.  The most precise measurement when dealing with timed attacks is to marry the attack functions to the animation itself which is done via adding a listener to the .onComplete fire of the animation.  There are some downsides to this which I’m working through now.

Say an Undead Mage is powering up to shoot a fireball.  When he reaches the end of the animation the fireball will shoot full speed at the player’s avatar.  But it’s also important to return the animation to the original Undead Mage sprite or else he’ll be looking Super Saiyan until he fires the next fireball and temporarily blinks back to his original form only to go full-mast again.  A temporary solution was to just deal with it, but as the polishing process begins in some key areas this has now been fixed to play off the peak of the animation and then let it gradually return to the original sprite by essentially playing the animation backwards.  This seems like a no-brainer, but because of the way I originally wrote the animation code, it wasn’t possible to attach two animations to a single sprite.  Instead, the last-added animation would only play, even if I was calling specific ones.

I initially thought of a spaghetti-code way to fix this issue by adding and removing the animation after it was done, every time.  But there’s no way I’m going to commit that now at this level of my personal JavaScript development.

So, after a few hours the animation logic is a lot more refined and also allows a high level of module-focused enemy insertion.  When the dust has settled, I should be able to plug-in the most basic of monster attributes like HP, Armor Levels, Level, and XP Reward and not have to write out animations for each one.  It should just know.