Crunch

tim-cain crunch game-development production management unions scheduling

Abstract

Problem: Is crunch in game development always the result of bad management, and can it be eliminated entirely?

Approach: Tim Cain draws on decades of experience as both a developer subjected to crunch and a director who imposed it, examining the many causes beyond simple mismanagement.

Findings: While poor management is the biggest cause of crunch, numerous other factors — variable developer productivity, publisher pressure, the trap of feature decisions, third-party tool issues, and the inherent chaos of creative work — make it effectively impossible to eliminate. Unions, not magical scheduling, are the practical answer.

Key insight: Crunch is usually, but not always, caused by bad management. Rather than pretending perfect planning can eliminate it, the industry should unionize to ensure crunch is shorter, better compensated, and bounded by rules — much like the film industry.

Source: https://www.youtube.com/watch?v=QJHpuJxMqiA

1. Defining Crunch

Crunch is the extra work — long hours, weekends — that happens when a game's development falls behind schedule. It typically occurs at the end of a project but can also spike before demos or conferences. The goal is to make up lost time and get the game back on track.

2. "Crunch Is Always Bad Management" — Not Quite

Tim pushes back hard against the common refrain that "crunch is always the result of bad management." He rephrases it: crunch is usually the result of bad management. The word "always" goes too far.

Bad management causes include overscoping by designers, inaccurate developer estimates not caught by leads, production failing to spot bad schedules early, and not noticing areas falling behind in time to course-correct. Tim freely admits this accounts for "a lot to most" crunch. But there's much more to the story.

3. The Chaos Beyond Management

3.1. Developer Variability

From his experience teaching university-level computer science, Tim observed that students with identical vetting — SATs, prerequisites, admissions — took wildly different amounts of time to complete assignments, with quality that didn't correlate with time spent. Some turned in gorgeous work early; others submitted terrible work late. His Troika co-founder Leonard Boyarsky reported the same with art students painting portraits. Accurately estimating task durations is nearly impossible.

3.2. Publisher Pressure

Every publisher Tim has worked with "wanted a Ferrari but had the budget to buy a Toyota." They sweet-talk developers into adding more features: "Don't you want your game to score well?" He references being told to put paladins, druids, and bards into Temple of Elemental Evil or don't make the game at all. Another classic directive: "Figure out how to do a dollar of content for a quarter."

3.3. The Feature Trap

Saying yes or no to a developer's feature idea is a no-win situation for leads:

  • Say yes → game gets overscoped → "You should have said no, you have more experience"
  • Say no → you're the bad guy who never listens, and the game might suffer for lacking that feature

Tim calls this "a complete trap" requiring "perfect oracular foresight, which I've never met anyone who had."

3.4. Time Vampires

Developers who hate pointless meetings but talk endlessly in them. People who camp in your office for hours lobbying for features. All of it burns schedule.

3.5. Design and Art Bugs

It's not just code that has bugs. A design feature can cause game imbalance, tying up designers and programmers. A flawed art asset can cascade into rework. These are rarely scheduled for.

3.6. Feature Interdependence

You can't always "just cut a feature." If you've designed your economy around crafting and then cut crafting, you lose money sinks, recipe rewards, quest lines, and an entire player activity. You'd need fallbacks for every feature, and you can't predict which ones you'll need.

3.7. Third-Party Tools and Engines

Getting third-party vendors to fix bugs is "like pulling teeth." New engine versions are never 100% good or bad — they fix some things and break others. Features advertised as working may not work the way you need them to.

3.8. Self-Editing

Tim cites Arcanum as a cautionary tale: if the team had an idea, it went into the game. The result was a game "bursting with features it probably didn't need." Learning to say no to yourself is one of the hardest management skills.

4. The Illusion of Perfect Planning

Tim is skeptical of people who claim they can manage the chaos. When he asks how, he gets platitudes: "We'll put in buffers," "We'll have extra people ready." He's never seen anyone deliver on time and on budget while handling all these variables, especially on larger games. Everything listed above is something he personally witnessed — none of it is hypothetical.

5. What Should Actually Happen

Tim accepts crunch as an occasional reality and argues the industry should focus on making it better rather than pretending it can be eliminated:

  • Unions — Tim has believed this "for years, before it was really considered a dirty word." Film industry unions ensure crew get overtime pay, hard limits on hours, and mandatory rest periods (at least 11 hours before being called back). The game industry has nothing comparable.
  • Shorter crunch — Better management can reduce duration even if it can't prevent crunch entirely.
  • Compensation — People who crunch should be paid more for overtime or given time off in return.

6. Personal Experience

Tim has been on all sides: crunch imposed on him, crunch he imposed, crunch caused by others' decisions, and crunch at high personal cost. He's worked long hours on minimal sleep and knows firsthand it's not sustainable. His conclusion is pragmatic rather than ideological: game development is hard, perfect schedules don't exist, and the answer is protecting workers, not pretending the problem away.

7. References