Rogue Zombies

Written By: Gage Gayler

5/30/2022

Introduction

Rogue Zombies is a rogue-like take on the Call of Duty Zombies mode. I was asked to start working on this project by a friend, because he knows how big a fan I am. I agreed and came onto the project as a Game Designer & Developer. I went into this project with some experience working on my own versions of this mode, but not to the level where I wanted to publish; more of an experimentation on recreating Call of Duty Cold Wars features such as  damage pop ups, and heath bar hovering.

Starting Problems

Starting out, this is the first time that I have worked on a game of this size without making or being given a game design document. This ended up causing plenty of communication issues and repetitive questions that wasted a lot of time and slowed down development; mainly due to lack of confidence when developing. This was also the first time that I have joined a project mid way through. When I joined quite a few of the main mechanics that had already been developed, a lot of the code and systems were worked on by different people and left in a non-finished state. For example I took on the responsibility of reworking the UI system, switching from HUD to paused UI. The current setup didn’t allow for more UI panels to be added so I had to choose to either work around this or completely restart the entire system from scratch. I ended up restarting this since I knew that it would pay off later when adding new menus. However, this was a recurring issue throughout the project happening again with the powerup system where I couldn’t even find the old system in the first place due to lack of organization. 

Design

The biggest challenge that I faced throughout was feeling like my design input wasn’t being heard, and feeling like I did not have a place or a reason to add input to the other designers’ choices, since I had come onto the project so much later. It more felt like his game so I would back down much easier on design choices, I felt would make the game more fun. I did have some ways to get around this idea of the game not being mine, such as including an additional game mode; starting out only the basic survival mode was planned. I pushed for adding in more with the promise that I would solely work on it and still work on the main game. I was really happy that I was able to start working on the mode, gungame. It was the only place in the project where I was fully responsible and in charge of the design. This helped me feel more confident when discussing where to take the main game in design meetings. Although I don’t feel like I got a lot of my ideas into the game I am still happy that I stood up for my ideas. 

Final Thoughts

Overall I think that this project was a good experience for me. I hadn’t had much experience working with designers that have such different tastes than I do. I am proud of the work I did, especially the gun game mode; It’s one of my favorite things I’ve worked on. It’s something that I actively want to play all the time. I also really like the polish work I did when it comes to wave start delays, and working with sound effect areas I usually don’t really enjoy working in. This project helped me gain a lot of confidence in my programming skill, and gave me necessary experience working with people who don’t see eye to eye with me on everything.

Extra

This section is more of a place for me to come write down slight optimizations and oversights on specific features of the game that I realize solutions to after the fact.

Spawning System:

Starting off the zombie spawning system, though I did not work on this system in this game, I did make it in my own zombies project the same way. The way it works is each spawner has a range that the player must enter in order for it to be active; as well as spawners that are behind doors wouldn’t be active until the door was purchased. On paper this was exactly what we needed, however after playing through the game I started to notice that once all the doors are opened zombies would start spawning on the other side of the map. Thus, having to walk all the way around, taking forever to get to the player. This was caused by the player being within range of other spawners through the wall.Plenty of issues with pacing arose, and if you want to keep a good pace with this system it would limit the way that we design levels; requiring more areas to be connected or spreading to new areas so the player is not in range. Both of these are massive limitations showing that this system doesn’t give us the control that we thought it did. The solution I have come up with is instead of having each spawner individually check the player position on range, we instead need to make a trigger in all areas. These triggers would have a list of all the spawners we want to be active, and recognize when doors are opened to add the new spawners to that list. This solution is both less expensive, and allows designers to have more control with pacing in all areas in their levels. I believe that this is a good thing to keep in mind when working on games with similar spawning mechanics.