Sponsored By
Seth Sivak, Blogger

April 24, 2014

5 Min Read
Game Developer logo in a gray background | Game Developer

These kids have been pulling 60 hour weeks ever since asking to be "crunchatized." 

Work/Life balance has been a hot button issue in the game industry since back before EA Spouse. “Crunch” has become a dirty word, a word that makes engineers and artists shiver and producers hang their heads in shame. I’m here to argue that crunch, in small doses, is actually good for your team, your process, and your game.

I am not, however, advocating for prolonged crunch; months and months of 6-day weeks hurt the creative process.

­

The common opinion is that crunch is unnecessary and happens as a result of poor planning, or that it is counterproductive because work during crunch has more errors and worse quality, leading to a net-negative benefit. Like anything else, crunch can be done wrong. I believe crunch can be a way to ramp up, reprioritize, and bring your team together to complete a significant goal—as long as it is done right and not that often.

1. Pick a Goal

External groups will impose goals on the team, whether they are publishers, investors, platform holders, or something else. These are not the goals that the team should focus on. The team should factor in external goals but, ultimately, the final choice is up to the team. If the team is not invested in the goal, or if they don’t think it’s the right goal and reasonable given the available time, the entire process falls apart. Passionate people will sometimes crunch on their own because they care so much about the goal that they are motivated to push themselves independently. If possible, set a goal that motivates, excites, and challenges your team.

Goal setting is hard. Your goal must be realistic, but also aggressive enough that the team needs to push to complete it. The better the team gets at working together, the easier this will become—but don’t expect it to be perfect the first time.

2. Track Progress towards the Goal

At Proletariat, we do weekly sprints and 4-6 week milestones. We try to include 1-3 weeks of polish time that is used to iterate and fix bugs. Our philosophy is to get things into the game as quickly as possible and recognize that it will never be right the first time. We track goals weekly and get bids from members of the team to make sure that the goal still seems realistic. We almost always end up eating into the polish time, but that is also the block that is reserved for possible crunch.

If you do not track your progress, it becomes impossible to plan and set expectations around hitting the goal. This is real work and it is important, so it must be prioritized.

3. Crunch

As soon as possible, the team should decide on when they want to start crunch. Communicating this early is the fairest way to let everyone prepare. At the start, it’s important to have the tasks properly prioritized and the team members balanced. Bidding tasks is difficult and—this may sound silly—it’s important to include the person doing the work in the discussion to make sure that the planning makes sense. This also allows that person to buy-in to their tasks and call out an unrealistic workload early.

There will inevitably be a few members of the team who fall behind. It’s not their fault; it’s the nature of building this sort of product. This is a chance for other members of the team to step in and help them, to creatively solve problems and work together to hit the goal. This will serve to strengthen the team and allow members that may not work together often to have the chance to gain experience together.

The last, and probably most important part of the process, is the re-prioritization of tasks. There will be too much work to complete, even with the team pushing hard, but the goal date should not be moved. It’s time for the team to take a hard look and pick which things are absolutely needed to make the experience that the goal required and which things don’t make the cut. This is a very difficult process, but it will make the game better, more elegant, and more refined. It will also force the members of the team to separate themselves from the project enough to take an objective, holistic look at it instead of only the pieces that they are responsible for.

4. Post Mortem

After each of these milestones, it’s important to leave time for the team to recover. We usually reserve a few days to reflect on what went right and what went wrong. We take those lessons and try to refine the process for the next time around. The whole team had a chance to push themselves and each other and learn more about what they can accomplish together. This process also surfaces more issues about the game, and this down time is a chance for the team to think hard about why they chose to cut or prioritize certain features and talk through what this means for the game.

In the end, it’s healthy to push the team. It is a challenge for the people who are executing and a good forcing function on the people who are prioritizing the work. Each goal that is hit builds momentum and each one that is missed is an opportunity to learn. However, it’s important to remember that when asking the team to crunch, you’re taking them away from their friends and family, so always make sure you're doing it for the right reasons and with the right goal. 

If you’re constantly crunching then, yeah, you’re probably doing something wrong. But a well-timed crunch can be an important part of your process. Crunch doesn’t have to be terrible. The changes that go into a game during crunch are often the ones that really improve the experience in a noticeable way. Crunch can bring strengths to light, forge bonds on your team and, of course, create crucial pieces of work. At the very least, it will teach you something new about your team, your process, and your game. Who knows, you might even feel good after.  

Read more about:

Featured Blogs

About the Author

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like