Final Asymmetric Game Writeup

My role during the second week of development was to write the generator scripts, which were used for the win condition of the game. I also spent time designing the roles of each player, and wrote some of their scripts. Lastly, I was tasked with the visual design of the game, which I admittedly dropped the ball.

 

 

above is a screenshot of the game in it’s semi-finalized state. In the center are all the players, and the capsules on the edges are the minions which spawn in from the translucent cubes. The goal of the game is for the three support players (the trap setter, the speed runner, and the attacker) to escort the engineer to the generators so they can be fixed. Once all four generators are fixed, the engineer must make it back to the center where the game ends.

For the generators, I wrote a script that allows them to be fixed when the engineer player is in close proximity, using a trigger. once in range, the engineer can press A to begin fixing the generator. This takes roughly 10 seconds, and will slowly drain if the player stops fixing in the middle of the process. At first, all that indicated the fix progress was a bar that would fill up on the top of each generator. However, we quickly noticed that this was difficult to see, and that even when It could be seen, players were unclear when it was fully fixed. To remedy this, I added lights to each generator, which turn green when fixed. I then spent a good chunk of time figuring out how to create animated “pulsating” signals around the generators, as well as the traps that players can set. To accomplish this, I created the outline of each object in illustrator, and used a PNG of that as a texture on a particle system. The particles were set to scale up over time, but not to move. Additionally, they changed color and faded over lifetime. Once I did this, I could simply change the rate of emission to control how quickly the objects pulsated. Although this proved to be a cool trick, I spent way too much time tweaking it, and ended up neglecting other visuals in the game, like characters and environment.

For the players, I thought about what roles would be most diverse and allow for the most varied gameplay. I decided that their should be a player concerned with direct intervention with minions (the attacker), a player focused on passive defense (the trap setter), and a player who could help their teammates (a speed runner). I wrote the scripts for the trap setter, and originally wanted the player to be able to block off avenues for minions by boarding up doors. However, this proved too difficult, as I couldn’t figure out how to lock the ability to the doors and not to any surface in the level. Additionally, Luis’s ai scripts for the minions would ignore any barriers made to the map, and therefore the doors were useless. To fix this problem, we pivoted and had the player lay down traps instead of barricades, that would kill any minion who walked over it. This way they could still block avenues as well as spaces.

After play testing, I realized that players ended up sticking together no matter what. The game was simply easier to play if everyone stayed in one unit. To fix this, we could add objectives or points in the map which individual players would thrive more. Additionally, one of the most glaring issues was that the abilities each player had left them doing nothing at most times. The speed runner’s and trap setter’s cool downs meant constant downtime.  Moving forward, we would need to consider secondary actions the players could take which would allow a constant feeling of engagement. This could actually be tied to the point made above regarding group clumping.