The Alpha presentations were a huge success! The instructors provided tons of useful feedback and overall our presentation was received very well. This blog post is about problems though, and thankfully all of them happened behind the scenes and had no impact on Alpha. We learned about Unity3D workflow issues resulting from unintended consequences of adding our menu.

Lesson number 1: Do not make running the menu scene the only way to access complete game functionality

Our implementation of the menu system did just that: it call the gameplay level scene when the user pressed play, and ensured that all scripts referred to the correct scene while it was playing. The end user's perspective on the build was unaffected by the consequences of this design error. Where the problems began was when I started editing the main gameplay scene after the menu implementation.
Some things were the same when you pressed play while editing the main gameplay scene, but some were not. Playing this scene in the editor resulting in minor bugs that did not stop gameplay and still allowed the designer to productively edit and play the scene in the Unity3D Editor. Or so we thought. Ultimately, there were some important bugs disguised as minor bugs that were preventing the enemy AI behaviours from responding to inspector and even hand-coded changes.
The specific issue was that while loops seemed to failing to stop even when their conditions were set appropriately. This meant enemy attacks would last forever and never do damage! It also meant that values I was tweaking in the inspector were not actually resulting in changes, so the damage values were way off when I eventually did play the scene from the menu. ALL OF THIS seemed to due to an unimportant error message which linked to a line of code in the Health class. It merely stated that the health bar was not initialized, the known (and previously thought acceptable) bug that was a side-effect of our menu implementation.

Lesson number 2: Do not make the HUD element (i.e. health bar) the primary reference for health or other values

Display elements should always refer to abstract values in the code. For example, it is not a good idea to make the health bar script contain the code that modifies health. That is the mistake we made, and it created a lot of latent problems that ended up destroying our productivity for a few days. The reason to rely on abstraction is because it has less requirements to run effectively. In our case, the HUD elements could only run properly when the menu scene was run and would not function when the main gameplay scene was run from the editor. This problem could also have been caused if the health bar had errors due to assets for the HUD reaching beyond system requirements or not being properly accessed for other reasons.

In Unity3D, it is best practice to allow designers the ability to play and test from any scene. Especially for small teams!

The time has come for Alpha presentations. Team STARSTRUCK is finally ready to show off a vertical slice of our game to the students and staff at Vancouver Film School Game Design campus. Today I worked on fixing up bugs in the code that plays audio provided by our collaborators from the Sound Design campus: Marc Sander Montant and Ricardo Ochoa. I am also working on post-alpha tasks like implementing physics-based AI code for the trucks in our game. Marcus Lembi has kindly provided us with some old code which address this issue, and I will use his code to replace my previous attempts to create a traffic system.

The fully functional M2 version of traffic I created has several important drawbacks: it requires trucks to be created and destroyed instead of looping their paths, it makes traveling up and down hill visually buggy and quite slow due to excessive collision with the ground, and the player can push the trucks around just by walking into them. Marcus' system requires looping, which is fortunately easily accomplished in our level and prevent the need to instantiate trucks out of thin air. The physics-based system makes moving on hills simple with the added benefit of creating a large chance for humourous accidents which show off Unity3D's inherent physics system and add to the realism of our cardboard world. The AI also aggressively tries to hit the player if they touch any trucks. The final benefit is by far the most important because trucks can not be used as a hazard if the player knows they can push them around. The old NavMesh-based approach I used does not create good traffic systems when collision with a player (who is also on the NavMesh) is required. Before getting help from Marcus, I also tried coding the traffic with character controller based on the scripts for the old NavMesh system. This approach led to far too many bugs that were difficult to fix because they were embedded in scripts that used concepts and functionalities that were custom built for the previous approach.

The take home message of this post:  If you want hazards in your level that hit the player without being pushed around or passing through them on collision then stay away from NavMesh. Start with a simple character controller and build scripts around that strategy because switching strategies after the fact leads to buddy coded. Or for advanced Unity3D users with the time and smarts to build a physics-based traffic simulation, try using the built-in Wheel Colliders to make trucks move.