At the bottom of the page is a video to a Unity game I have been working on at home. It is to be a scrolling platformer. It’s very early in its development, but is now playable to a certain extent, and so here I have a sneak peak of the game for you.

It started off as a means for me to get more familiar with Unity and C#, but has turned into me wanting to make the most well designed code structure I can come up with at the time, despite this being a simple game. For example my animation and AI state machines consist of separate classes for the different states (and of course, Unity’s excellent component system helps with this). This massively improves portability, flexibility and maintainability, and actually isn’t much work (when its up and running, it cuts down the work needed!).

Animation

Regarding the animation state machine, I have an abstract class (GLAnimState, GL for Green Lantern, the character) that is inherited by all of the other animation states, containing an abstract function VOnUpdate() that is overridden by all subclasses (in C++, this would be called a pure virtual function):

My motivation for this is that there are many different types of animations. We have some that will loop forever until a different state is implemented, such as the idle and running animation states. Then we have some that will play once and return to a different state, such as the ‘hit’ or ‘attack/shoot’ state which is followed immediately by idle, and then some that will loop forever but on the last frame (or the last few frames), such as the jumping animation. Rather than a tangled mess of if/else statements, which is not easily updated or maintained, separate subclasses make the code much tidier, and easily allow code to be swapped in or out.

As you can see, the constructor of each animation state class takes in an animator object, containing arrays of all the sprites (as passed in by Unity editor) and an enumerated type, defined below:

The enumerated type changes according to game logic. Then all animation states are stored in an array as type <Superclass> and simply looped through. The animation state that is active is then called.

 I did consider having subclasses instead named “Play once”, “Play looping”, “Play last frames” etc, which would have been more generic. But I opted to not follow that strategy, as specific game logic can be called by these subclasses (with references to player controllers, animation controllers etc in the superclass). For example the “CreateBullet()” function is called at the end of the “Attack” state class, creating a bullet at the end of the animation. For better encapsulaion an event system could be used, but for now this seems sufficient. An alternative could be to gave generic classes wrapped in more specific class names, such as “Idle” containing a call to “Play Looping”. But this seems convoluted.