Managing Scope and Crunch: Lessons from a Small Student Team

There have been a number of excellent blog posts concerning crunch and overtime in game development lately, especially concerning the widespread culture that often seems to glorify these mistakes. This mentality is not just limited to games, or even the software or entertainment industries, but it is equally common in other areas of life, such as higher education. In a student game that I worked on recently, our team encountered this culture head-on and handled it in an interesting way.

I am currently finishing up my time as game development student at The University of Texas at Austin. UT has an intensive Capstone program, in which students in teams of 5-6 work for three months to make a game from concept to release.  The program is designed to provide students with a taste of how real-world game development works, and as a soon-to-be graduate preparing to fully join the workforce, I find myself reflecting on the Capstone often.  I believe that our team’s experience offers valuable lessons for any team facing scope issues with their game (and I also believe that any team that says they haven’t dealt with scope issues is lying). Due to the pervasive crunch culture, reducing scope midway through a project is often seen as or feels like giving up. With this post, I aim to demonstrate that this should not be the case, and that reducing scope is ultimately better for your game and your team than going into crunch to try to solve the problem.

Our game, Schism, was initially conceived as a first-person, dialogue-heavy narrative game with strong platforming and exploration elements (that’s a mouthful; you might be beginning to see why we had a scope issue). Think Mirror’s Edge meets Wind Waker meets a Telltale game. The story was based on a novella one of our team members had written a couple years ago. We began pre-production and prototyping in late January, and had a rough gameplay demo within a few days. So far, so good. We had some issues building out our dialogue system (we eventually went with a custom Ren’Py plug-in for Unity that a friend of ours had written) and first-person animations proved to be a challenge, but these were fairly easy technical problems to solve. The real issues centered on the game’s narrative and our very ambitious vision for our project.

In early March we realized we had a problem. During our weekly external playtesting sessions, it was apparent that our game’s development had fallen significantly behind most of the other teams’ in the Capstone – all we had was a broken tutorial and a very rough prototype of our hub environment. Even more worrisome, it seemed that each week that went by we were accomplishing less and less, while the other teams’ games were looking better and better with each sprint. Something had to change.

If you are at all familiar with software project management, you have likely heard of the triple constraint. Essentially, there are three attributes that any project has – scope, budget, and time. You cannot (or at least should not) change or affect one without altering at least one of the others. For example, if you want to release your game earlier than previously planned (affecting the “time” attribute), you must either reduce the scope of your game, or increase the budget (effectively by working overtime or hiring more employees). All the attributes are highly interdependent, and the triple constraint is an extremely useful lens through which to view many production issues. Since our game was being developed exclusively by students for a school project, we were in a circumstance that closed some options to us that a professional studio might have been able to consider. However, I think that the results of our decision will prove valuable to any game or software developer, regardless of professional status.

We all realized that our game’s development was not progressing as it should be. According to the triple constraint, we had three options: extend the deadline, increase the budget, or reduce the scope.  As it was a school project, there was a hard deadline of the end of the semester to have our game reach Beta. This was non-negotiable; if we wanted to pass the course, we would have to turn in a complete, fully-playable version of our game as close to release-quality as possible. In addition, since we were all full-time college students juggling multiple classes and jobs/internships, our development team was effectively composed entirely of (unpaid) part-timers. This made it very difficult, if not impossible, to increase our budget (since we had no money, I’m using “budget”  to refer to time devoted to development from existing team members), especially as the semester wore on; our other classes had exams to study for and projects to work on as well. That left us with only one option: reduce our scope.

This was a very difficult decision to make. Since Schism was a highly dialogue- and narrative-based game, reducing our scope would inevitably mean changing the story somewhat drastically. We had all grown very attached to the story by that point, and the fact that it was based on an outstanding original novella written by one of our very own team members made this choice even harder to make. It truly felt like we were giving up on our vision for the game, as well as failing our team member who had originally written the source material. However, we gritted our teeth and sat down to go through the narrative beat-by-beat, marking sections that we could either cut immediately or might cut in the future. At that point, our narrative team worked to reconfigure the remaining plot points into a coherent story that remained as true to the source material as possible.

Reducing our scope did not initially feel like the right thing to do. I think I speak for the entire team when I say that it was pretty disheartening at first, as it seemed like we were betraying the story we had set out to tell. After all, couldn’t we just pull some all-nighters, go into crunch, and make it work? This is the problem that I wish to address here. All too often, our first instinct is to buckle down and go into crunch. It can almost feel like you’ve given up, like you didn’t even try, if you don’t crunch. However, this is a mentality that we have to get away from. Crunch is not a solution to development problems; it is a half-hearted excuse to not deal with them directly. This is why I am so proud of our team and the decision we made to reduce our scope instead of trying to crunch out all that additional content that we ended up cutting. We realized that we had an issue, and instead of instinctively trying to work faster or pull a bunch of all-nighters, we calmly evaluated the problem and went forward with the only true solution: reduce scope.

Very quickly after we reached this decision, we noticed a complete change in how our game’s development was progressing. It was (naturally) much easier to prototype and iterate on smaller, more linear levels than sprawling, open environments with multiple, location-based gameplay features. We began building out content at a much more rapid pace (being that there was less of it to create), which allowed us to get assets in the engine faster and to test more often. As a whole, our productivity increased dramatically. Whereas before it had felt like we slogging through sprint after sprint with few visible accomplishments, now our game was coming together much, much more quickly. Classmates from other Capstone teams regularly remarked that our game had improved remarkably in just a couple sprints after we decided to reduce our scope. This is not to say that everything was immediately better after that decision. As I mentioned earlier, we still felt like we had lost something or that we had given up. But as the semester came to a close, it became very clear to all of us that we had made the right decision. Our game was much smaller than we had originally envisioned it back in January, but it was also completely playable, we didn’t kill ourselves trying to crunch out the content we cut, and most importantly, the game was fun to play.

This took foresight, but most of all, it took conviction. Making sacrifices is part of game development. Our team learned that with this project when we were forced to make a choice about what to sacrifice: we could abandon features and content that we were already far behind on, or risk straining our team dynamics and relationships (not to mention losing sleep and grades) through crunch. At the time, it felt like we were doing something wrong, that we were giving up, but I believe the decision we made saved our game’s development from itself. In conclusion, I would encourage anyone dealing with development issues to remember the triple constraint; either reduce scope, increase the budget, or extend the deadline. Doing a little bit of crunch is fine, but that is not a legitimate, long-term solution to any development problem, even if contemporary culture continues to glorify the long nights spent programming, designing, and generally producing (often lower-quality) work. If you have no other options available to you, reducing scope is a perfectly viable decision that may just save your game and your team.