Now that I’ve reached the end of this class (although not the end of the project, as I intend to return to develop the work I’ve started) I wanted to take some time to reflect on the biggest road-block I found in my first foray into game design - I am a code breaker. Not in the way you might consider Turing to be a code-breaker but I have a incredible talent at destroying code. I broke my game in ways I never even thought possible. Although I don’t have many screenshots or videos to show the simply mind-blowing ways in which I broke the game due to panic and attempts to fix my mistakes, I wanted to document some of the more notable ways in which I overcame the curse of breaking everything I touch.

Lights Out

To avoid the UI narative elements repeating after the scene reloaded upon the players death, I created a second scene that was an exact copy of the first with different UI elements. I tested the new system, and half of the lights in the scene turned off when Scene 02 loaded.

I checked the lights, but could not see the problem. I decided this was a bug which could be solved later in development. I did not figure this issue out - however the lights stay on in the exe. build, despite the fact they remain broken in Unity after death.

The Dying Player

In order for the player to know when their avatar was taking damage, I wanted to create a UI element which would flash white anytime their currentHP decreased. I had some fairly simple code, which worked (I tested it with a Debug. print which called for the UI Image in flash) - however somewhere in the code I had created an error which I could not find to fix. I spent 4 hours trying to find the problem, taking all the new code and elements out of the build, for it still to be broken. This resulted in me having to reload an earlier version of the build to work from. I did learn it is extremely helpful to save separate builds in case you break the current one beyond repair. I did not figure out how I managed to do this in the first place.

The Floating Bear

When I first brought my bear model in from Maya to Unity to replace the place-holder, it seemed to be working quite well. I double checked that I copied all of the required components, moved a number of assets around to account for the increased size of the model; everything seemed to be working well. When I pushed the Play button however, the asset jumped in the Y axis. Just straight up in the air. Floating. 

I rebaked the nav mesh, triple checked the components - could not figure out why this was happening. Thankfully, after reading some advice on the Unity Forums, I was able to write 2 simple lines of code which would keep the thing grounded. I did not figure out why this problem was occurring.

The Invisible Bear

This happened almost immediately after the floating bear. I realized that the Bear would randomly not appear on Play. At first, I thought this must be an error with the model I’d brought in from Unity. I tried to re-import the model, tried to smoothing the mesh, tried to clean up the model - to no avail. I realized the issue had to be coming from Unity. After speaking to some of my colleagues, no one understood why it would disappear intermittently.  One of my friends asked me to screenshot or record what was happening to try and help, and this was how I finally figured out what was going on.

As you can see from the video - I knew the game object was still there since the Player could not move into that space; so I concluded that I was somehow turning off the mesh renderer. Around the 0:35 mark you can see the exact moment I figured out the problem.

The game objects which act as triggers for the Bear to move to the next location are child objects of the Bear. The code to randomize which of these are active at any point also turns all of the other child objects of the Bear to be inactive. When I transferred the components and child game objects onto the Bear model, I did not account for this code which would randomly turn them off on Awake. The solution was simple - I copied the Skinned Character Mesh component onto the parent game object, then changed the code to ignore the skeleton rig for the animator when randomizing which child object was active. This solution took 5 minutes to implement and wasted around 3 hours trying to figure out the problem.

Everything said, I’m very happy with what I was able to create in 12 weeks. I’m excited to continue working on this project in my spare time, and hopefully by the end of summer I will have more to show.