The Making Of: Warping Warrior

Finite State Machines

I had just finished a course that taught me to create an FSM as a character controller, so that's exactly where I started when building this game.  Both the Player and Enemy AI are controlled using  their own finite state machines with each state written as its own script.  The implementation was so clean and well organized that I decided to experiment with creating a Game Manager in this same fashion.

Game Manager

This was my first time writing a Game Manager script and I wrote it as a finite state machine with each state having its own script.  Things quickly fell apart when I had trouble keeping the game state aligned as other scripts were affecting it.  One spaghetti bowl of code later and I decided to scrap the FSM (sort of).  I watched a YouTube tutorial on writing a Game Manager and restructured from there.  This design still used the concept of an FSM but each state was a case in a switch statement instead of its own script.  Also, the Game Manager became a singleton so I could call the SwitchState function from anywhere I needed to.  This really helped me keep the game state aligned with what was happening on-screen and stay in control of the game state.  I especially appreciate how simple it was to write a menu manager that activated and deactivated certain menus based on the game state.  The whole script only needed one method to do exactly what I needed!

Async Loading

I spent 2 full days trying to get my scenes to load asynchronously.  The whole point was so that my game manager could find certain objects in the new scene after they were enabled.  I learned that the progress can't go past 0.9 (90%) on the scene load until the scene is allowed to activate.  Not knowing this information caused an infinite loop (haha that was the theme of the jam) in which the next level never fully loaded.  After 2 days of blood, sweat, and research, I finally managed to get all my scenes to load asynchronously using an IEnumerator.  Unfortunately, the game manager was still unable to find objects in the scene.  I suspect that this had to do with the game manager being a static instance and I wrote another script to do this instead and just tell the game manager to switch states based on the results.

Spheres

Almost every aspect of this project was made more difficult by using spherical surfaces.  Every character controller had to be written specifically to walk/run along a sphere instead of a flat plane.  I was unable to use the NavMesh system for the AI because it would only bake the top portion of any given sphere and even if I rotated the sphere the baked surface stayed at the top.  The only issue caused by not being able to use NavMesh is that the enemies could run through obstacles.  All the colliders on the obstacles were changed so isTrigger was true so that the player could run through them and trigger a tripping animation.  I didn't have time during the jam to learn how to create a pathfinding system along a spherical surface to avoid obstacles and hunt down the player, so I just let them walk through obstacles.

Zombies

After 9 days of work the game was finally perfect.  Until an hour before submissions were due and we realized that enemies still chased the player after death.  We had been playtesting with just one enemy in each scene, so it wasn't until Taylor filled out each of the levels that we noticed this bug.  For the life of me I still don't know why they wouldn't play their death animations and then stay dead.  They weren't even playing the death animation at this point and we had little time left.  Desperate for a solution, I created a coroutine in the enemy state machine that would wait 1 second and disable the entire game object.  After all, the player runs around so fast you never see the death animations play out anyway.  I made this executive decision in the final minutes of the jam that allowed us to produce a final build in time for the submission.