Crunch does not always mean Quality of Life or Quality of Work has to suffer, it’s just that in most circumstances it does, because of the way it’s implemented. I have gone through two sets of crunch, both mandatory, one long, one mitigated, and both sucked. But there are a few things that I found helped me, and I think would help others, get through any period of crunch:

1. Provide All the Information: Inform everyone how much more you expect them to work, what needs to be done, and where the deadline is. If ANY of this information changes, make sure the team knows. I have been in and heard about crunch situations where information about deadlines or cut features was withheld, and this only makes people angry
2. Allow people to choose their extra hours: People are different and have different home lives. Some people work better in the morning, others at night, others over the weekend. Do not blanket ask everyone to stay late. Instead, let them choose when to work and they will choose times that will not only make them most productive, but will interfere with their lives the least.
3. Allow people to work from home: Set up your infrastructure to let people work from home. Some people can be just as productive at home as they can be in the office, and this removes the stress of a long commute and improves QoL since they can be around for their loved ones.
4. Allow people during longer periods of crunch to take some time off: This is huge for me, and I’ve never been anywhere that does this. If your crunch is going to last a long time, or looks like it will need to be lengthened, give people a day off. Say “Okay, everyone can take a day off free sometime in the next two weeks.” Giving them a time frame allows them to plan for things like short trips, or time with their family. They’ll come back rested, happier and more productive.
5. Make sure they have and know the reward: In a start-up, the reward is in the stock, but in larger companies, make sure people know they will be compensated of extra hours, and then compensate them.

Hopefully this makes sense. I don’t like crunch either, and it is avoidable for companies that have really experienced teams and a certain amount of give, but some companies do not and will not have the luxury to avoid crunch entirely. Obviously, great companies will always avoid crunch, usually because they’ve learned from their mistakes. But realize that a good company may crunch, but will always find a way to mitigate it when and if it happens, and will learn from their mistakes on their way to becoming a great company.

[For more insights from Jeff, stop by his blog at JeffOnGames.com and follow him on Twitter at @FuzzyBinary]

In this post, I’ll look at what causes management to enforce mandatory crunch.  Everyone looks at crunch as solely a failure of management. I think there are a lot more factors to it than that. Here, in my mind are the general causes of crunch.

1. Company Policy: This is the Epic model. There are no important deadlines coming up, there’s nothing that’s actually requiring crunch, but the company has decided to require everyone always work 60 to 80 hour weeks. Not okay. There is no excuse for this other than management being completely inept. It affects work quality and general quality of life. Don’t do it.
   
2. Bad Information: This is what happened to Team Bondai. They were constantly told (and believed) that the game was almost finished. In such cases, many team members, believing the end is in sight, will do self-imposed crunch, which eventually will lead to de-facto crunch. In addition, this is where a death march starts, and tends to never end.
   
3. Bad Planning: This is the most common cause of crunch, and management gets rightly blamed for it all the time. But there are two types of bad planning:
   
   1. Bad Low Level Planning: Even the best management team can make a mistake, because they can only make decisions based on what they’re told by the people below them. If what they’re told is wrong, their planning will be wrong. So, if you’re at the low level, don’t fudge your numbers. Tell management the truth so they can make the right decisions.
      
   2. Bad High Level Planning: Even with all the right information, managers, especially bad managers, will plan incorrectly.
      
4. Shifting Requirements: Even with good planning and good information, games are a highly creative and highly iterative product, and when something’s not working or isn’t fun, it has to be changed. Unlike other industries where you can work “to spec”, the “spec” of a game is frequently fluid, which makes planning for the long term almost impossible. This, unlike the other causes, isn’t anyone’s fault, per-se, since a team can come to the mutual decision that something needs to be reworked, but it’s something that frequently gets ignored while doing planning
   
5. Deadline: When all is said and done, this is the real cause of crunch. When a deadline is involved any amount of error in planning or requirements hits a head when the deadline looms. Some studios are in a position where the deadline can be pushed, but not all, especially when dealing with a multi-game publisher that has to allocate resources at various times (QA, marketing, operations, etc) to make sure the game launches without a hitch, so they can move on to the next one. In these situations, moving the deadline is impossible. 
   

The Myths: Crunch is a Given and Crunch is Always Avoidable

Both of the above statements are wrong. If the causes of crunch are listed above, avoiding crunch is as simple as avoiding those mistakes. Don’t make crunch company policy, always give your employees all the information, plan well at all levels, have a solid design document, and don’t have a hard deadline. Simple. But, if any of those slip, you have to make a hard decision: cut features, cut polish, or crunch.

If your company has a lot of experience or a lot of leeway, you can always avoid crunch. However, if you’re a start-up working for a publisher, on a hard launch deadline, under contract, and you want to make the best game possible, chances are someone, and it’s not necessarily management, is going to make a mistake, and that mistake is going to cause some amount of crunch.

Was it avoidable? Yes, probably at some point it was, and yes someone made a mistake somewhere. Crunch is always a failure somewhere down the line. But at some point in the project, it will become obvious that some amount of crunch will be needed. The next step is to mitigate it.

In the final part, I’ll look at ways a company can mitigate crunch, if it becomes a necessity.

[For more insights from Jeff, stop by his blog at JeffOnGames.com and follow him on Twitter at @FuzzyBinary]

Crunch has been coming up in the news again, mostly because of the Team Bondai issues.  As a disclaimer, I have never gone through what anyone would call a “death march,” which is what Team Bondai had to deal with. I’ve had to do crunch, but never on a huge magnitude, which I’ll get to. I’m also going to take what some would say is a “controversial” stance on crunch. Here’s the not controversial part: crunch is always bad, never required, and always avoidable, and a team should do everything it can to avoid it. But it’s not always that simple.

Types of Crunch

The thing is, there are lots of types of crunch. And they’re all different, and affect the team in different ways, and on different levels. In my mind, there are three major types:

1. Self-imposed crunch: This is the crunch that some people in the game industry do on their own accord. They stay late every night because they want to. They want to get that one last thing in, they want to polish the hell out of whatever, or get that one last boss battle in. This is a personal choice, and there’s really not much you can do about it. However, it should be clear to other team members that this type of behavior is not condoned or required. Don’t reward them for this behavior. Otherwise you get into the second type of crunch.
2. Team de-facto crunch: This is where the team “decides on its own” that it’s going to crunch, when the culture necessitates it, or when management does nothing to stop it. When too many people start self-imposing crunch, other people at the team will start to look down on those that “aren’t working as hard,” and peer pressure will cause them to stay later, or work longer. This is particularly true in companies with lots of younger workers who are not only particularly vulnerable to this type or peer pressure (they really want to impress their superiors) and also believe that this is just the way the game industry is. If this bubbles up to management, there becomes this situation where long hours are expected, and people that don’t do them are considered less valuable employees. Don’t let this happen. As a manager, it is your job to make sure self-imposed crunch is seen as an anomaly, and to do your best to keep people from doing it.
3. Mandatory Crunch: Just what it sounds like. Management, for some reason, requires longer hours. This is the most common form of crunch we hear about, and the worst. To producers / managers out there, just because you do the same hours does not make mandatory crunch okay. Actually, nothing really makes mandatory crunch okay. There are no excuses here. Mandatory crunch is always a failure somewhere down the pipe.

The first two types of crunch are cultural and occur at all studios, but can be mitigated once you recognize the warning signs.

In addition there are three levels of crunch:

1. Mitigated crunch: The increase in hours is not huge, maybe 10 extra hours of work during the week, the length is known and can be planned for.
2. Long crunch: The increase in hours is high. Working 60 to 80 hours during a week with no break. The length can still be known, but may be a long way off.
3. Death march: The increase in hours is high, and there is no end in sight, or the end is repeatedly pushed back.

A Mandatory Death March is the worst type of crunch, and when we talk about “crunch” we’re usually talking about mandatory long crunch or mandatory death march. There are no excuses for them

In part 2, I’ll take a look at the causes of crunch to figure out if crunch is avoidable.

[For more insights from Jeff, stop by his blog at JeffOnGames.com and follow him on Twitter at @FuzzyBinary]

Today Sharat and I gave a talk at the Singapore MIT GAMBIT game lab on rapidly building video game prototypes. It’s something of a rip off of Ethan’s and my IGCE talk from last month but this has a stronger focus on development and how to make different types of prototypes. I suggest checking it out! For more info on prototyping you can also see my guest blog from last week on Sande Chen’s game design website.

Sande Chen recently asked me to a guest post for her monthly blog on game design. I was happy to help, and honestly a little bit flattered/stupefied that she would even ask me to help. Nevertheless I was happy to help, and I’ve copied the entire post below. It’s a bit of a how to on video game prototyping, with emphasis on getting shit done and why this is important. Enjoy!

——

So you’ve got an idea for a game, but you’re missing an artist, you don’t have the design nailed down, you need to find funding, and you don’t know what platform you’re going to develop for, you’re not sure that the concept is even feasible, or you [insert development hurdle of your choice here]. How do you even start? With prototyping!

Prototyping is the process of making a small, crappy, slapped-together version that demonstrates certain key aspects of your final vision. It’s a great way to start making games since it is far less daunting, and during the process you’ll learn a lot about what you should actually do in the full version. Prototypes are throw away, but that’s a good thing since it’ll give you more freedom to experiment in ways you might not normally try.

Starting out

Take stock of what you have, and make a list of your strengths and weaknesses. When we started out at Fire Hose we were 3 MIT nerds with a good amount of design experience. We were especially good at programming and game design, but we completely sucked when it came to art and we had almost no money whatsoever. As a result, we decided to focus on the technology and design, and to just rip off artwork from other games. A larger, more established studio might have strengths of lots of money and a large code base, but weaknesses of time and manpower. Whatever the case may be it’s important to focus on what you’re good at and (for the time being) ignore the rest.

Scoping is really important as it dictates how big the prototype will be. We recommend making a few rounds of prototypes, starting with quick + dirty one day versions, then a 1-3 week build, and then a 2 or 3 month final prototype which is a good vertical slice of what the game eventually might feel like. Of course this will vary team by team, as larger groups can accomplish more, and not everyone has 3 months or so to devote to prototyping (though we certainly recommend spending at least that long if you can afford it). It’s worth noting that there is a limit to how big a prototyping team should be; larger than 10 people will probably not be useful since the goal is NOT to make a final version, but just something quick and dirty that can be tested. We find that 3 – 4 people can do a good job of rapidly comping up with something worth playing with.

Let the development begin!

Once you’ve got your team, get to it! Remember, the standard rules of development don’t apply, so feel free to take shortcuts. Want to steal assets/code from other games? Go for it! Want to use stand in, crummy programmer art? Why not! Code in whatever is faster, not most robust (i.e. python, not C). In fact, you should do whatever is necessary to get it done quickly. We’ve done prototypes where someone sits behind the monitor and reads the spoken parts to the user, pretending to be the computer. Don’t feel bad about taking such shortcuts, remember that it’s all throw away anyway.

The one rule that DOESN’T change during early prototyping is that you need to test, test, test. In fact, you should be testing more than you normally do, since you’re probably throwing more new features in front of your users now than during any other part of development. Test on a weekly basis, ask lots of questions, and try to direct users towards rating the features you actually care about (but don’t be leading when you do this!) It’s amazing how much users are willing to forgive when they are presented with an obviously half-assed prototype, so don’t feel bad about asking for feedback.

Finish the job!

It’s easy to stop after making one prototype and calling it a day, but don’t stop there! Analyze testing results and iterate on the prototype, taking what you’ve learned and making it better in the next version. Feel free to try out completely new, different, orthogonal, or contrary features/designs in subsequent builds, since you’re trying to learn more about what will work. You should also start looking to fix your weaknesses during this phase – hire that artist, find more funding, or start putting together a schedule that is actually appropriate for the full title.

Deadlines are your friends, so be sure to schedule them in. It’s easy to just keep iterating with prototypes forever, don’t fall into this rut. Set hard deadlines for when you will finish certain versions and stick to them. Testing days are generally useful as deadlines since it’ll force you to have finished builds that users can play with.

And when you’re done…

Throw the prototype away and start fresh! Trust me, this is the right thing to do. It feels rotten since you’ve spent a lot of time working on it, but you can’t build off of a hacked together prototype full of spaghetti code, stolen assets, and written in a non-robust language. Prototypes serve a purpose, but should not turn into a final game. The main things that should survive are the design and lessons learned.