For those who haven't read it yet, here's my old post on a [typical day as a game designer]. When we're crunching, we just have a longer work day. Tasks don't really get more difficult or time-consuming when we're crunching; we still need to be able to complete each task in a reasonable time frame. Instead, during crunch the number of tasks we need to work through increases significantly, so the "identify the problem, iterate on solutions, try and test solutions, submit a fix" process just happens more often each day.

Normally, I can get called in to prioritize new tasks as they come in, get assigned a new task, or ask/get asked for help about an existing issue during the work day. During crunch, that time frame increases into the evening (e.g. late breaking bugs/issues) and sometimes into the wee hours of the morning. In addition, the bugs that must be fixed during crunch get a little weirder because not everyone is around or available at all times, so I would often fix bugs outside my area of expertise. There have been occasions where I got assigned a critical issue for the sole reason that I was still awake and at the office. That kind of trial-by-fire experience is what hiring managers are looking for when a job description asks for shipped games.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

• Short questions: Ask a Game Dev on Twitter
• Long questions: Ask a Game Dev on Tumblr
• Frequent Questions: The FAQ

Over the course of my career, I've worked crunch hours (10+ hours a day) on at least ten separate games, two of which never shipped. I worked weekends on nine of them. Some crunch periods were intermittent (crunching near the end of milestones to make the deadline) and others were ongoing due to overly ambitious schedules and constantly-moving goalposts. Crunch period length was determined primarily by the project - some were short (shortest: two week crunch periods and not more than four weeks total over the entire year) and some were long (longest: eight months of sequential crunch leading up to launch).

I like Mark Darrah's perspective on this - crunch often brings completion urgency, which is the feeling that the team must make final decisions and commit to them, rather than second-guessing and redoing work or just not deciding. Significant amounts of work are gated by committing to large decisions - and crunch is one of those things that tends to force commitment. The longer major decisions go without commitment, the more work piles up on the other side of the decision commitment, thus often necessitating crunch to finish. Looking back on all of the games I've worked on, the projects that committed to the big decisions early were the ones that had the least issues with crunch.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

• Short questions: Ask a Game Dev on Twitter
• Long questions: Ask a Game Dev on Tumblr
• Frequent Questions: The FAQ