Crunch is Bad

Not mentioned in the "What went right" section was the teams passion for the project and without such enthusiasm the engine and blogs wouldn't have been as successful as it was. However, this is the "What went wrong" section, so we should talk how this passion wasn't useful for the project but rather how it was harmful. Developing an engine in 15 weeks requires a certain amount of persistence and drive, which translate into working about 70+ hours each week. This project became a 15 week crunch, which while we don't recommend subjecting yourself or others to this was useful for us to know what crunch feels like so we can recognize it in the future. We didn't treat this project as a marathon, rather a long sprint.

We spoke to some of our faculty near the end about how none of us had the motivation to pull from to make the target demo game. Creating the game at the end was no longer fun. For us, we attributed this to burnout; we were too tired to continue to develop. However, that might not be the full truth. The team was excited to develop the engine because it was a new experience where we had the chance to learn and grow as developers. However, the game signified the end of that. The game wasn't about learning, it was a statement that we were done learning with this engine.

Where we weren't excited to develop the game, we were still willing to put time into polishing and adding to the engine. So it's not like we were afraid of developing a game because of bugs or broken features; if we were we probably wouldn't have held a game jam where other could see the ugly pieces of engine. We couldn't even predict what features of the engine they would be looking at. Developing engine features, even if small, was a new experience when compared to game development.

As much as we say our project was about demystifying engine development, the project was more about learning. Specifically, it was about learning how game engines work, the intricacies of them, and how to be an effective software developer on a team, but learning nonetheless. Learning was what was driving the work and our motivation. This can be simplified to saying, we were excited to problem solve the unknowns of the project, so when the game came to be developed it was a list of "knowns", problems that we knew how to solve and had solved before. We had developed games before, games much more complicated than the one we were trying to generate; there wasn't a list of unknowns. Having to develop something that isn't challenging, having just a list of tasks that are "knowns", is demotivating.

As the 15 weeks neared an end, there was this added pressure in the room, as you would expect for a project running out of time. The team was able to combat the stress through the semester by having team dinners throughout the semester (rather than just one paid for by the school) and having game nights to relax; however near the end there was less time to do this. The pressure could be traced to be coming from two categories: 1) frustration and 2) "there is still so much work left". The latter is to be expected from any type of project, especially one trying to do so much with such little time. However, the former just a pressure from frustration isn't a positive sign. The frustration came from not learning. We weren't being given explicit feedback about the engine we were developing from our faculty or others and we were no longer learning engine development. At some point near the end, the project pivoted from its original goal and we had to do something that was no longer learning. And it just became a slog.

Comments