A couple of weeks ago, MovieBob talked about the problems the video game industry has with crunch and why it’s a bad thing. I was in the tech sector during the dot-com boom and I worked on several projects that required crunch conditions, so I thought I’d add my perspective.
The popular narrative is that executives are amoral meanies who work their employees long hours to save money. While there are lots of examples of that sort of behavior, this narrative misses the nuance in how tech culture works. I agree that crunch is hard on workers, hard on families, and generally bad for the quality of the game and the bottom line, but I think it’s a little more complex than the cliche sweatshop metaphor. Not all crunch time is created equal. Crunch isn’t always the result of malice, and sometimes it’s not even the fault of management. Before I condemn the perma-crunch that plagues the industry, let me defend temporary limited crunch as a way of meeting firm deadlines.
Scheduling is Hard
Scheduling for software development is notoriously difficult. It’s tough to predict how long a given task will take because you often can’t anticipate the problems you’ll face. This is particularly true if you’re dealing with tight hardware constraints and high performance requirements, which is the norm in gaming. Accurately scheduling a game means knowing how long it will take to come up with solutions you haven’t thought of to problems you don’t know you’ll have.
If testing reveals that the game is suffering from occasional but serious frame drops because the levels are just a little too big for the console you’re targeting, it’s not always obvious what the correct solution is. Maybe you need to take the really big levels back to the design phase and chop them up until they fit comfortably in memory. Or maybe the programming team needs to put in some time and see if they can make the engine more efficient. The first option will make the game less fun by giving you more joy-killing loading screens, while the second option is a bit of a gamble because there’s no guarantee that the coders will be able to save enough memory to make the existing levels work. Maybe they’ll spend weeks tuning the engine and then you’ll have to chop up the levels anyway. By that time, chopping up the levels will be even more difficult because they’ll be closer to completion.
These kinds of problems happen less often if your team is really familiar with the hardware. As everyone gains experience, they get better at estimating what challenges they’re going to run into and what sorts of solutions work best. Then the industry moves to a new console generation and everyone goes back to guessing. This is why the janky games tend to happen early in the lifespan of a console and things get smoother and prettier as the tools mature.
Scheduling is also hard because game development is inherently a creative and collaborative process. Many people have to work together for years to create a game, and that’s not a recipe for predictability. I’ve watched and read a lot of postmortems, and I’ve never heard of a team making exactly the game they had planned out in the original design document. At some point, the specs will change. A designer will come up with a better idea. Analysis will reveal the original design contains degenerate strategies or major imbalances. Gameplay fads will shift, making some of the original design seem stale. Playtesting will discover some emergent gameplay that’s really fun and should be embraced as part of the design.
On top of that is the normal tendency to engage in feature creep. There will always be someone on the team advocating “just one more little feature”. It’s hard to say no to ideas that sound fun, but the cumulative effect is that the spec grows and all those little features combine to create a lot of extra work.
Consider the case of the 11th hour change of the art style for Borderlands. Originally Borderlands was supposed to have a much more gritty and photorealistic art style. Very late in development the team realized the realism wasn’t working and decided to embrace the comic book design the series is now famous for. That move created a ton of additional work for the team, but it was also an immense improvement to the quality of the experience. It’s possible this move saved the franchise. A grim and gritty Borderlands may have faded into the background like so many other forgettable shooters of the time period. The developers had to make a personal sacrifice to make this change to the game, and while I don’t know any of the developers personally, I’m willing to bet they would say the sacrifice was worth it.
The problem is that games often have a fixed release schedule. If the new version of Microsoft Office is taking longer than anticipated, Microsoft can shove it to the next fiscal quarter without crippling the company. It’s much harder for a game to miss its release window, because the marketing campaign (which often costs as much as the budget for the entire game) is usually paid for and planned a year in advance. More importantly, the release schedule is usually set to avoid conflicts with competing games. If you’re releasing an open-world third-person game set in a big city, you really don’t want to release too close to the next Grand Theft Auto. A delay might push your project into a release slot against a stronger title, which can kill a game. For contrast, Microsoft Office is a well-established product and it isn’t going to live or die based on its release date.
More People, More Problems
When a project is late, it’s easy to blame management for not hiring enough people. But even if budget wasn’t a concern, there’s only so much work you can get done by throwing more bodies at a problem. If a project is late, adding people will usually make it even later, because now everyone needs to stop and train all the newbies to bring them up to speed. As the team size expands, collaborative friction increases. The bigger the team, the more time needs to be spent in meetings to keep everyone coordinated. It’s like the human resources equivalent of the tyranny of the rocket equation: The more people you have, the more everyone’s productivity will be consumed by office politics, interpersonal conflicts, and efforts to organize, measure, and coordinate work.
To sum up: Assuming your game isn’t a cookie-cutter title, it’s hard to predict how long it’ll take to develop the mechanics and write the software. Even if you predict correctly, ambitions will grow and features may creep into the design because your game is being made by gamers and overcoming challenges is in their blood. The end of the project is where the irresistible force of creative ambition meets the immovable object of the ship date. Sometimes it’s necessary for the team to work extra hours to close this gap.
In these cases, there’s no villain. The publisher isn’t being a cruel taskmaster and the developer isn’t irresponsible. It’s just that we live in a complex world where we find ourselves up against difficult problems and we have finite time and manpower to deal with those problems.
Farmers work long days around harvest time, retail workers are busy around Christmas, and video game journalists basically stop sleeping when E3 rolls around. There’s nothing insidious or exploitative about having a few weeks of long hours at the end of a project. I’ve worked on projects where we had to crunch a little to meet our deadline. It was sometimes fun, sometimes frustrating, but I always understood it as a natural byproduct of living in an imperfect world where ambitions are at odds with available resources.
However, none of that excuses perma-crunch.
People like to cite the various articles or studies showing that worker productivity drops off sharply above a certain number of hours worked. Those studies all meet with my personal experience and observations, with one small qualifier: I think people can effectively crunch for short bursts of time without suffering from the predicted falloff in productivity. The exact threshold varies from person to person. Some hit their limit after a couple of weeks, and some can go as long as six before the high workload begins to take its toll. Young people can crunch for longer than old, but sooner or later everyone runs out of momentum. Enthusiasm fades, fatigue sets in, workers become estranged from their families, and output plummets. After that point, additional crunch mode makes them angry, disloyal, and uncreative, without getting the job done any faster.
While I defend brief short-term “sprinting” at the end of a project to make sure you hit a ship date, I insist that prolonged crunch is the work of fools and idiots. It’s all cost and no benefit. If your team spends six months in crunch mode and is still falling short of the ship date, what’s your plan? If everyone is already working at maximum capacity, then you can’t speed things up.
Morale matters. Video games is a creative industry. Developers aren’t digging ditches. The product is the result of their collective creative output and their ability to collaborate. If everyone is tired and irritable, then the quality of their work will fall. Even if you’re an amoral manager who doesn’t care anything about your staff, you still need to avoid prolonged crunch because it lowers the overall quality of your game. You’re creating a situation where your top talent will leave, the game will take even longer to develop, and the product will drop in quality. You’re inflicting both short-term and long-term damage to your company and your products. There’s no way that makes financial sense. It would be better to miss your ship date.
Perma-crunch is more proof for the thesis that I keep revisiting in this space: Executives at the big publishers do not understand the industry they’re trying to run. If an executive understood game development, they would be able to intuitively understand the reality of crunch. If an executive understood the business well enough that they could understand the schedule and project milestones, then they would be able to observe how dangerous long-term crunch mode is. Even if that boss cares nothing for their staff and has purely selfish motives, they ought to be throwing people out of the office at 6PM rather than let the team burn itself out early.
I said that scheduling is hard, but it’s not impossible. You can get projects done on time. It takes knowledge and experience, but companies do pull it off. You just need a leadership that understands the business they’re trying to run.
As one final warning to executives: There will be consequences for all of this. Maybe folks will unionize. Maybe there will be congressional hearings and legislation. Maybe there will be large protests. Regardless of what form the backlash takes, it will be a bad time for you. The loot box thing came back to bite you, and that’s not going to go away. If you have any sense at all — any shred of self-preservation — you’ll stop the death march crunch mode now. When the outrage boils over to the wider culture, it will create new headaches that you haven’t even dreamed of. At that point, a missed ship date will be the least of your problems.
