Team NAH: We’re Going To Woodstock!


“By the way you guys, I signed us up for GMGF.” Being told this was somewhat frightening news. GMGF, or Green Mountain Games Festival was about two weeks away, and our game was not in a state that I would be proud to show off to the public. It was in a raw state that many would consider to be visible still in the early stages of development. Not that much thought was put into the game itself, the systems were there, but there was not that much attention put into how they were structured. Various bugs were in the game that made restarting the game a thing that had to be done very often during QA Tests. Getting the game to a point that I would want to show it off to the public would take a large amount of work, but we managed to pull it off.


On of the primary concerns with the game was that spawning enemies was very rudimentary. You hit a trigger and it would spawn X amount of Y enemies spread across Z spawners. There was no way to offset enemy spawning or make conditional spawning. One of the first tasks I set myself up to do is rewrite how enemy spawning works. After a few hours working on a side branch, I emerged back with a much more robust way to handle enemy spawning. Now, each area has a set amount of waves. Each wave has a set amount of spawners that that specific wave can spawn from, what types of enemies can spawn in this wave, and how many enemies will spawn in this wave. The most important feature of this new system is that a designer can set if the next wave spawns off of a time delay, or off of a percentage of enemies being dead. This allowed us to set up a much longer level and more unique spawning systems. The best part of having this new spawning system is that it is very simple to create a new area and set up how the enemies spawn there.


The second feature that I primarily worked on in order to have the game be ready for GMGF was adding Quality of Life features to our grenade weapons. Heading into this sprint players had an unlimited number of grenades, couldn’t control how far they went, and couldn’t tell where they would end up. To address these features, there were a few simple changes, and some more complex changes. The simple one was to have the grenades use an ammo system that you regained more from enemy drops. The more complex fix was to preview how far the grenades would go. Due to how the grenades gain their trajectory, the path of the grenade is unknown until the object itself is spawned. To allow for a preview, I had to move a lot of the calculations from the grenade itself to the object that spawns the grenades. After that, it was a matter of graphing a kinematic equation, which thanks to some google-fu turned up Line Renderers being able to do such that.


Adding these changes to TRotP made me feel much more confident about how we showed the game off at GMGF, which a full report of how it went will be written in the upcoming weeks