Week 10 was a set of seven days that occurred. I’m “David,” a programmer for Turtle Collective, as you may or may not know.
This week one of our biggest priorities was player feedback. From our QA testing results, it was clear that there were several points in the game where players were unsure what to do or were unsure of what was happening.
One of my first tasks was to add some player feedback for the jetpack. This consisted of two things: particles that emit from the jetpack to simulate the jetpack’s thrust, and secondly, a meter on the back of the jetpack to display how full it is. We wanted the meter to be somewhat diagetic.
More player feedback: another thing I did was add particles that would flow from the drone to a trap when the drone was activating that trap. This helped to show players if they were activating a trap, and if they were, which trap they were activating. I also fixed some bugs with adjusting the drone activation sphere across the network because unfortunately, NetworkTransform doesn’t automatically handle scale across the network, so you have to set it up manually (using Commands/ClientRpcs, or SyncVars).
More player feedback: I added a little UI popup (using coroutines) to display info to the player like notifying them when a round starts or if they are waiting for the other player to finish placing their traps.
Another one of my priorities for this week was to get the new traps that Eva had designed into the build. Two new traps were designed (actually there were three, but we decided to focus on the two most important ones): the quicksand trap and the laser trap.
The quicksand trap consists of three lanes. The drone can either decide to activate the two outer lanes, or the inner lane. If the runner steps into one of the activated lanes, they are slowed down.
The laser trap consists of a panel inset into the wall. The laser is invisible at first, but flickers if the runner gets close, so they have some time to avoid it, but they have to react fast. If the runner gets caught in the laser’s beam, they are stunned for a short duration. The laser, in theory, will encourage players to be more carefully when going through a level so that they don’t get stunned. Implementing these two traps was fairly simple.
Alexis finished up some more animations for the runner – the idle and backwards walking animations – so I implemented these in the build. At first I was going to have a separate state for the backwards walking animation, but then I realized I could incorporate it in a much simpler way: by having a blend tree containing both the forwards and backwards walking animations, and then just adjusting the blend value depending on whether the player was moving backwards or not. This way both walking states could be contained in one blend tree, and I wouldn’t have to over-complicate the animation state machine.
This week, I also refactored some of the Grid code a bit. Originally, all objects with the “environment” tag were populated with invisible grid cubes on all of their surfaces, which are used in trap placement. However, this posed a problem with our wall objects, which were fairly sizeable, but obviously, we didn’t need grid cubes on most of the faces/surfaces of the wall objects except the ones facing inwards towards the level. So, I first refactored the code so that it was now only one small function, and all you have to do was pass in the direction of the face you want to populate. This way I could make it so that certain objects could only populate one of their faces with grid cubes.
To improve performance, I also increased the size of the grid cubes by 2 (thereby cutting the number of grid cubes in half). It didn’t really seem to affect gameplay that much, and it definitely improved the performance of our game.
So, that’s what happened in Week 10.
who am i