I’ve spoken previously about the importance of project planning for game development. However, there is a key element of the planning process that was not mentioned in that article, one that is the source of much debate.
What is Crunch Time?
If you’re not familiar with the term, crunch time is what happens when a deadline (milestone, ship date, etc) is coming up, and the team works hours above and beyond what is normal for the company. (For studios that normally work 8-10 hour days, this may go to 12-16 hour days, etc).
Ask many devs about crunch time, and they’ll groan, and retell stories of working through the night, delivered pizza every night for a month for dinner, or the mountain of empty cans of Mountain Dew they collected over the course of the project.
Unfortunately, crunch happens on almost every game development project at some point, and can cause strain to developers and their families. So, why does it happen every time, after all these years of the industry’s existence?
Why Crunch Happens
There are two main reasons why crunch happens.
First, if a project isn’t scheduled with enough flexibility in the timing, all it takes is for one key feature to take longer than expected to implement, and you’ve suddenly got a cascading series of dependencies which are now delayed. Over time, this can lead to significant delays in shipping, and the only solution is for the team to work long hours to catch up.
Second, deadlines. Particularly on titles involving major publishers, shelf deadlines are set in stone. Every day that a game slips beyond its ship date is time that the publisher is paying for shelf space on every retail outlet in the country. Because of the way publishing schedules work, and how publishers do their best to make sure their own titles don’t compete, as well as making sure that a title doesn’t go up against a major competitor in the same time slot (which ends up usually being really bad for one of the titles, or just mediocre sales for both), it means that developers are frequently given less time to develop a title than they actually require.
The end result? Crunch time gets put into the production schedule. This is where the debate begins.
There are also two main theories on handling crunch.
For the first scenario, where insufficient buffer time is put into the schedule for missed feature deadlines, the answer is generally to teach producers and developers how to better estimate the required time for features, and/or learn to break the tasks down into more manageable pieces, so that it will be obvious very quickly if a feature is going to cause a delay. It is not foolproof, and there is almost always at least one major case of a feature causing a slip, or a major bug causing a major rewrite of a component later in development. It is the unfortunate nature of software development that these things can happen, and little can be done to completely prevent them from happening.
The second is more difficult. Arguments have been made that for developers who are passionate about their craft, that crunch time is just part of the job. Conversely, there was the EA Spouse incident, which brought to light practices at companies with less interest in maintaining employee happiness.
Fixing the second scenario is harder than it might seem. Developers of AAA titles with hard shelf dates cannot just hire any programmer looking for work to boost their productivity. Many programmer positions at major studios require months to fill, because the qualification bar is set so very high. Also, increasingly high demands for improved visuals require more and more artists to be on staff, and likewise, require a high level of skill. When a publisher says that you get X million dollars for shipping by next Thanksgiving, but you have to ship by that date, there generally isn’t a lot of room for discussion.
A Future Without Crunch Time?
So, given the two scenarios, what can be done to prevent this in the future? Education of staff will help, but it’s only part of the solution.
More and more effort is being made to simplify development for programmers and art staff alike. Tools to simplify debugging and testing of code, reduce repetitive art tasks, and distribute computing load across multiple computers to cut wait time for level designers are all examples of how to use development time more efficiently.
Is it enough to prevent crunch time entirely? Certainly not, but it is a good start. As the training at game development schools improves, we will begin to see an increase in available labor for the market, but until that time, there will be high demand for those who are able to turn out top quality products in a short timeframe.