Programming so far

Week one:

Tuesday 19 ► After our group discussion about how the game should work, I built a quick modular rig in unity. That rig included a main camera with a shooting script (using raycasting on click), a spawner prefab and a makeshift zombie (a cube) with the beginnings of an AI script (which causes the cube to moves towards the camera). The rig allowed you to place spawners, which would spew cubes, at regular intervals (spawn rate and spawn delay could be adjusted from unity). The cubes moved towards the camera at a slow pace and would disappear when shot.

I felt that building in simple path finding early on would allow for easier experimentation of spawner placement around an environment later in development. So I started on a collision system by which the cubes could avoid tagged obstacles (tagged “obstacle”). This was a script placed on a trigger sphere around the cube. At the end of day one this functioned at a basic level turning 45° to the left when an object was encountered (and moving in that direction for a set number of frames). This broke the shooting mechanic temporarily.

Wednesday 20► Started work on more in-depth pseudocode. I made a good start with a list of functions that would need to be covered by the final code. Then I got bogged down writing pseudocode for menus. By the end of the day I had come to the conclusion that this was a pointless exercise as well as being super boring. Later that night I started writing pseudocode which just covered gameplay functions.

Thursday 21► Finished writing the pseudocode which should provide a decent map of the code that needs to be written. Found the one box that needed to be ticked to allow raycasting to pass through triggers.

I also got the obstacle avoiding part of the AI working. Instead of just turning 45° as it approached an obstacle it generated a random number between -90 and 90 and changes the direction the cube faces and travels based on that.

Tuesday 26► Changed the part of the AI which made the cubes avoid obstacles to turn over several frames rather than just one.

Started writing code to deal with the cubes actually hitting an obstacle. Initially I experimented with using the same code which made the cube turn before hitting an obstacle. This worked ok, but it looked wrong for the cubes to turn as they were moving backwards. I then messed with a system which would cause the cube to move straight back and then execute the code for avoiding obstacles.

That system worked fine except that when there were multiple cubes in the same area they would grind against each other and break everything.

Example Scenario:

Cube 1 approaches obstacle. Makes a 20° course correction but still hits the obstacle, pretty much, head on.

Cube 2 approaches and makes a similarly small course correction.

It hits cube 1 as it reverses and keeps moving forward.

Both cubes can remain stuck on that obstacle indefinitely and cause more cubes to pile up.

As my first attempt to fix this problem, I modified the section of code that dealt with obstacle collisions, and made it check for objects tagged “zombie”. This was functionally ok. It fixed the problem, but it created some strange behaviour. The cubes would brush against each other and immediately reverse and change course. Even worse was that cubes hit from behind would reverse back with the cubes that had hit them.

So, I started fiddling with collision.relativeVelocity. It took a while but eventually figured it out. By making sure that collision.relativeVelocity.z was a positive number before accepting a collision I was able to eliminate most awkward collisions and even allow cubes to grind against each other a bit.

At the suggestion of my teacher Justin, I downloaded and implemented a free third-party animated zombie as a placeholder asset (complete with walk cycle)

Thursday 28► To fix everything broken by adding the zombie model I reverted to my original zombie cube prefab, turned off the mesh renderer on the cube and made it as tall as the zombie model. Then I added the zombie model on top of that.

By this point my zombie AI had gotten super messy so I wrote some, more in-depth, pseudocode and started rewriting the script around the five tasks the zombie needed to perform. These tasks were

Spawning: For the purpose of spawning zombies off screen and behind objects, zombies need to travel in a straight line for a period of time before they make for the camera.

Walking: Most of the time all the zombies need to do is walk towards the camera.

Avoiding obstacles: If a zombie is near an obstacle it can change course to avoid walking into it.

Hitting obstacle: After hitting an obstacle a zombie needs to move away from it and pick a new course.

Attacking player: The Zombie needs to attack the player if it gets close enough.

Francis