Snap, Crackle, Crunch Time

Berglund Authority Level 3

by Chris Pruett <pruett@vvisions.com>

Talk to any veteran of the video game industry and you are likely to find that they have experienced "crunch time" at least once in their career. Crunch time is a period in a game's development when employees must put in extra hours in order to meet aggressive deadlines. While a team might be in "crunch mode" for as little as a week or two on a well-managed project, some games have been known to require months on end of continuous crunch. Crunching usually involves working 12 to 16 hour days, working weekends, and generally spending every moment of your waking life working on the project. Game developers naturally detest crunch with a deep passion, but it is so common in the industry that projects that require no extra effort are almost unheard of.

While crunching can get a troubled project back on schedule, the drawbacks are numerous: in addition to burning out employees and souring the moral of the team, work done under crunch is almost always of low quality. Crunch can even perpetuate itself, as problems created by low quality work during a crunch may themselves require crunching to fix. Crunch time is often sited as the reason that some developers exit the game industry once they reach a certain age.

Most chalk crunch time up to bad project management. The theory goes that well-managed projects maintain realistic schedules, thereby decreasing the need for crippling overtime. The fact that some level of crunch is still required to ship most games seems to suggest a general lack of experience in the game industry's management; after all, other industries that have aggressive deadlines do not seem to lose their employees when they turn 30. Even the best managers may find themselves in a situation where there seems to be no solution to the schedule other than to ask their team for extra hours.

I believe that crunch is a symptom of three basic problems with the video game industry: scheduling for fun is difficult, changes to the project scope are not well regulated, and that thinning profit margins require every project to be tuned for maximum profitability.

By scheduling for fun, I mean that many game companies find it hard to anticipate how many iterations of development particular mechanics of a game will require before they reach the magical (and highly subjective) benchmark of "being fun." A game designer's job is to produce rules and mechanics that the player finds enjoyable to interact with, and these mechanics should, ideally, be fun without requiring any support from visuals or plot line.

In third-person games such as Super Mario Bros. or Tomb Raider, the core mechanics that describe the principle interface between the player and the game involve moving the player's avatar around on the screen. These core mechanics are often easy to describe (Mario can jump, run, go down pipes, and shoot fireballs), but making them enjoyable for the player can be extremely challenging. How high should Mario jump? How fast should he run? Which set of parameters will yield the best experience for the player? How many enemies can the average player deal with before the game becomes too difficult? Answering these sorts of questions is usually a highly iterative experience: game designers will often simply tweak and tune variables until the mechanics seems to click.

The problem is that defining this type of iterative development in terms of a concrete schedule can be close to impossible. Usually design iteration will result in more work that needs to be produced by the rest of the team, which can cause a ripple effect in the entire team's schedule. Game developers seem to consistently underestimate the amount of time that will be required to make the experience absolutely enjoyable, which can easily lead to crunch time toward the end of the project.

Game projects invariably mutate as development progresses. In addition to the regular implementation of game mechanics and fleshing out of design ideas, it is quite common for more work to be added to the schedule during production. Such additions are often based on marketing decisions: if marketing research suggests that games with certain features are more likely to sell, they will often request that similar features be added to a project that already has a full schedule. Game teams themselves are also a common source for new work, as new design directions often become apparent as the game begins to take shape.

However, many game companies have trouble rejecting change requests, or modifying the schedule by cutting other features in order to make time for the new work. An extremely common theme in the game development postmortems of Game Developer magazine is that new work often ends up pushing the schedule out so far that crunch is the only way to finish the game on time.

I have had this experience myself. Towards the end of a project I worked on several years ago, we received feedback from our publisher that certain elements of the game's user interface were not acceptable to them. Though we had discussed possible features for the interface early on, it was clear that some miscommunication had occured. The project manager felt that we had no choice but to accept the changes, even though it meant several weeks of rework. Since we were still contractually obligated to provide a finished game by a specific date, the team crunched for a few weeks to get the new requests in.

In my case, the project was completed on time without any of the team members suffering from burnout. However, many less fortunate companies have grappled with crunch periods that extend for months on end, often because company management was unable or unwilling to adjust the schedule or cut features out to reduce the work load.

I believe that the reason that some companies react this way to unrealistic or changing schedules is that there is a push to make every game a blockbuster. In the competitive market of video games, quality is often measured in business circles by the number of features that a game provides. Gauging fun is a difficult and subjective problem, but defining quality by feature count provides an easy metric for business people to use when they run numbers. While it is true that many of the best games sport a wide variety of features, the idea that features equate to quality is fallacious. Nevertheless, the push to have more features than the competitor product often causes video game schedules to become bloated with tasks. At its worst, this approach can cause a dramatic decrease in the overall quality of the game.

Game development costs have skyrocketed in the last six years (partially, I believe, to this feature arms race), and costs are now so high that profit margins have thinned for all but the very best selling titles. Thus it is very difficult for a prudent game company to cut features from its schedule, as many believe that to make a profit you must have a wider breadth of features than your competitor (marketing calls this "added value"). The result, almost invariably, is crunch time for the development team.

Regardless of the causes, crunch time is one of the largest drawbacks to working in the game industry. The video game industry is filled with people passionate about the work they do (similar technical jobs in other fields almost always pay better), and it is possible that this level of passion causes game developers to accept working conditions that would be unacceptable in other fields. Whatever the reason may be, crunch continues to plague almost every professional game project produced in the US and Europe.

There are, however, a few studios who are actively trying to reduce crunch. A few first party and self-funded studios (such as Valve Software) have the luxury of setting their own due dates, and consequently have much more power over their own schedule. Some companies, such as High Moon Studios in Carlsbad, California, are experimenting with scheduling systems designed to keep projects on track even if the schedule changes dramatically. Software processes such as the Team Software Process[1], Agile Development[2], and Extreme Programming[3] are beginning to take hold in the industry. These approaches are based on the idea that perfect schedule prediction is impossible, and therefore it is better to use a model based around reaction to change. The common goal of these systems is to produce better, more reliable schedules and prevent overtime-induced employee burnout.

The introduction of formal development processes indicates that the video game industry is beginning to become more mature. More studios are realizing that the benefits of crunch are far outweighed by its detriments, and a few are actively trying to find solutions to the crunch problem. However, there is still a long way to go before the industry is mature enough to make crunch an exception rather than the rule. In the mean time, the employees in the trenches of game development have little choice but to put in extra time and effort to get an increasingly difficult job done on time.

References

[1] The Team Software process is a method by which schedules are continually updated by team members who aggressively track their own work time and attempt to improve it. http://www.sei.cmu.edu/tsp/

[2] Agile development is a framework by which a development schedule can be broken up into a series of small chunks in order to maximize the team's ability to react to changing requirements. http://en.wikipedia.org/wiki/Agile_software_development

[3] Extreme Programming is a popular form of Agile Development. http://en.wikipedia.org/wiki/Extreme_programming