How to Predict If Your Game Will Need to Crunch
Talking to people who are disillusioned by crunch, we hear about a scenario that is becoming more and more common. A game studio goes through an intensive period of crunch to release a game. Everyone pulls together, works hard, and manages to meet their deadline. A few weeks or months of relative calm ensues. And then, in the distance, another deadline looms and the inevitable crunch starts again. These studios have built crunch into their game development timeline, creating a constant cycle of crunch that those companies cannot, or chose not, to break out of.
There is, however, a second, more shocking scenario. Management assembles, tensions are high, something has gone wrong. Everything was carefully planned out, calculations were done, but those plans now lay in tatters. Grimly the decision is made, the only solution is to crunch. These companies have fallen victim to accidental crunch.
Accidental crunch can seem inevitable when it rears its ugly head, but the key to preventing it is to be vigilant and to identify the signs and causes early enough that you can avoid the inevitable. We are talking months before you would be likely to crunch, not weeks.
Below are 6 important questions you should ask to figure out if your game is likely to fall victim to accidental crunch.
Do You Have Any Bottlenecks?
This one is the most obvious, and common, which is why we put it first. Bottlenecks in your production pipeline can make crunch extremely difficult to avoid, especially when there are only a small number of people qualified to do a specific task. Throwing more people at a task for which they are not qualified is never as effective as making sure the right people have the time and resources they need from the start.
Development tasks that are particularly vulnerable to crunch are ones that require contribution or content from lots of different sources. Things like the implementation of characters in the game. There are lots of dependencies (from art to AI) and tasks that need to be acted on in quick succession, meaning any breakdown in the pipeline can lead to a tight bottleneck that slows down the whole process.
How to mitigate: Identify bottlenecks and reallocate resources to manage them. Do this repeatedly as eliminating one bottleneck will often shift the load to another.
Are your technology solutions fit for purpose?
Which technologies you choose to use or create are one of the earliest decisions that get made in the development of a game. It also happens to be one of the most impactful at almost every stage of development. The story of Bioware and EA’s choice to use Frostbite for Dragon Age Inquisition is probably one of the most famous tales illustrating how early technology choices can have lots of ramifications.
You need to be careful to examine if you have made a choice early on which will handicap you later. For example, choosing to use javascript early on but then realizing that compiling is taking so long that you need to change back to native will cause the kind of disruption that absolutely can lead to crunch. Identifying these technology limitations early and rectifying them is always a better option than deferring the decision until you have no choice. One good way to handle this is to attempt an early vertical slice that is as polished as you can make it with the tools you have.
You should also focus not just on the technologies you do have, but also the ones you do not, or which you may need in the future. A good way to identify which tools you are lacking is to find out which menial tasks your qualified employees are finding themselves doing time and time again. If, for example, you have designers or developers wasting hours every day doing data entry, then you have a serious inefficiency. It is almost always worth spending 2 weeks making a new tool to automate a process than it is to spend 2 months brute-forcing yourself through the roadblock instead. Martin, one of our founders, will jokingly describe the job of a Level Designer on a new game as, “building a world with broken tools, half done tools, or tools you don’t have yet,” but it doesn’t have to be that way.
How to mitigate: Identify future needs, build the tools you need, and make difficult decisions about your existing technologies as soon as possible.
Have You Tested Your Game Early and Often?
One trap that is easier to fall into than people assume, is to lose track of the vision of your game, only to realize at the last minute that the game you are making is no longer fun. The solution to this is to test early and often.
Don’t test it yourself, you are too close to the game. If you are lucky enough to have a large studio with multiple teams, asking members of another team to test your game is a good place to start. But for best results, test with naive players. This can be anything from friends and family to people you found on craigslist, to testers provided by a professional service like Playtest Cloud. Do not use the excuse that testing is too expensive or you are getting enough data from your own team. You can be creative about the former issue, and you are probably wrong about the later. Be sure to measure the effect of each change you make against the one metric that matters, how fun your game is.
Something that can be a big help with this issue is to make sure that the very earliest version of your game is fun. If the basic mechanic of your game (think jumping from platform to platform in Super Mario) is fun, then everything you add to it from that point on either makes your game more or less fun. This gives you your true North. Everything you do that takes you off course from that should be looked at as suspect.
How to mitigate: Test early and often with people who are as naive as possible. Keep your vision in mind and prioritize making your game fun over other concerns.
Are You Suffering From Scope Creep?
Does the scope of your game keep expanding over time? Are you late in production and still adding features? One way to avoid this is to adhere to the above point. If you have identified what makes your game fun early, you should build on that and make an MVP(minimum viable product) that you could theoretically release. It’s a lot easier to resist the urge to add just one more feature when you know that you have a solid foundation that could stand alone if it had to.
Scope creep is sometimes healthy, and often when you look at a project a year after it started you say, “If I had told the developers we were going to do all this at the beginning they would have strung me up.” However, a lot of the time you are just putting layers of icing on a cake, or worse, a turd. Icing is great but at some point adding more of it won’t make things more delicious. A good rule to follow is this: If you find yourself saying things like, “Wouldn’t it be cool if ___” or “I really want to see ____ in the game.” Ask yourself if it is additive to your core loop. If not, then do a quick cost-benefit analysis on the feature. If the cost is high but the marginal benefit (in terms of fun) is low, you have your answer on whether to add it in.
Remember you can always add things to a wish list for DLC or LiveOps additions. If your base game is engaging and retentive, you’ll get to that list eventually. Just look at games like World of Warcraft or Clash Royale, and compare what they were like when they shipped to several years down the road.
How to mitigate: Try to make your MVP before you make your magnum opus.
Are Your Departments Communicating Effectively?
Identifying how your departments communicate early on will give you a lot of information about how issues can develop over time. If your departments ping-pong responsibilities back and forth with the mantra of “not my job” then you have a problem which has the potential to get worse over time. Such behavior can seem reasonable early on, but as deadlines get closer and tensions get higher. Those tasks stop being ping-pong balls and become grenades. With one department priming the grenade and then chucking it over the wall, causing an explosion that leaves a wreckage of broken timelines and short tempers.
Make sure that each department’s responsibilities are clearly defined, but that your departments are also willing to be flexible when it matters. Also, make sure they communicate consistently and constructively, telling the other departments as much as they can about what they want of them and why. No one benefits from a task getting kicked back because the person receiving it was confused regarding what was expected of them.
How to mitigate: Manage the communication between your departments carefully. Build a culture of open and honest communication. Make sure responsibilities are clearly defined but encourage your departments to be flexible when needed.
Have You Iterated Effectively?
The iterative process is one of the most valuable tools in game development. When done well, iteration can help identify what works and what doesn’t and can be one of the best safeguards against spending time and resources going down a path that turns out to be a dead end.
However, iterating poorly can be just as dangerous as not iterating at all. Specifically, over-iterating one feature or aspect of your game can lead to something we call compartmentalized iteration. This is where you spend too much time polishing something in an attempt to make it ‘perfect’ without examining how it interacts with the rest of your game. Or worse yet, without knowing if it should even be in your game in the first place.
It might be counter-intuitive, but it is often better to get something to the point where it is ‘good enough’ and then move on. Finish other dependencies, test how it interacts with the other aspects of your game, and then come back to it later with fresh eyes. This can make it much easier to find the fun and optimize efforts to polish the game. Take something like map creation: instead of making every map perfect before moving onto the next, try taking multiple passes at them. Start with a grey box pass, then a balance and art implementation pass, then a few tweaking passes, and a polish pass. Don’t look at the maps for at least a week between passes. Give your mind a break. You’ll find that you learned more doing all the other “stuff” between each pass than you ever would have if you had focused on the very first map till it was done. Doing things this way will lead to much fewer situations where you realize you need to scrap something and start from scratch.
How to mitigate: Fight the urge to over-literate. Move on when something is “good enough” and come back to it with fresh eyes once other dependencies have been completed. Learn when to scrap something that is not working, rather than continuing to polish it in the hopes it will become better with time.
We hope the above advice helps some of you to avoid crunching unnecessarily.
Remember, what we outlined above does not include all of the different reasons you might have to crunch, but it does include some of the most common (and more importantly) most avoidable ones.
