Crunch! (part 2)

This the second part of an article talking about crunch, where I give my opinions and share my experiences with regards to that subject, and try to explain the origins of my very cynical point of view. It was all sparked with a very unfortunate twit from the Ryse guys and in the first part I share some of my early experiences which hopefully explain my currently cynical way of looking at this subject. During this second part, in order to avoid problems with NDAs and so on, I'll try to stick to talking about generic stuff rather than focusing on a concrete experience. I'll try to compile a set of things I'd like to see and I think should be avoided by managers and game directors when dealing with this sort of issues. All of this is based on my personal experience throughout my whole career, not on a single project.

There was some controversy with Rayman Legends' team working overtime only to get the game delayed

I take some things for granted when I talk about a manager. I take for granted he's smart, tha he has experience in the industry and that he's capable of planning with a relative accuracy. I understand the last part is a byproduct of the first two. If you have a manager that doesn't have these (I sometimes have had the 'pleasure' of meeting some who doesn't) you're in for a lot of trouble, because that guy is going to make a lot of mistakes and, most probably, it'll blame everyone but themselves for the failure. They just can't understand what went wrong or why since they lack either the wits or the experience.

Anyway, assuming your manager has all that, which is fair and usually the case, there's other reasons that may cause crunch and could easily be avoided or improved. The first and most important by far is bad planning. What do I mean by bad planning? Basically set stupidly tight milestones that you know can't be achieved.

For instance, if you have a multiplatform project for consoles where you need to go through the 1st party 'LotCheck' (check for errors in the game and things that will make it not want the console manufaturer to publish the game) you know you need to allocate a sensible amount of time for QA. If your game has networking, local co-operative or competitive gameplay the time should be even bigger. Experience dictates that multiplayer, both local and, particularly, online is bug-prone and should be handled with care. I have only been in the industry for around 9 years, yet I have to work in a console project, even with limited multiplayer functionality, with less than 10-12 weeks of QA. If your planning for the next 'Call of Honor' only contemplates 4-6 weeks for QA, you're doing bad planning. And you know it, which is the part that annoys me the most. Oh, and please, don't try to sell that to me, I'm not buying. No way.

A 'beautiful' picture of the latest entry of Call of Duty

There's a variant of that bad planning thing which is also quite common too, planning for features you know you can't get into. Let's say you have time to do your 'Call of Honor' with multiplayer but your publisher decides that they not only want online competitive multiplayer but also co-operative, both online and local. You know there's no way in hell you can add all that. You're way too late for everything, you know you need to do overtime just to reach your current goal. But you had to give in because they are the publisher, you know, they have the money, so you promise something that can't be done, knowing it, just waiting that in 3 months time, when there's only 10 weeks left to hit the street date, the publisher will realise what they asked is impossible to reach and they give up on that. But in the meantime, you ask your people to work on that feature all the same. You know hundreds of man hours are being thrown out of the window, many of those could help alleviate the crunch problem you already have, but also to improve the final product, spend these hours balancing and polishing.

I understand you may think, hey but it's not your manager's fault, now is it? It's the suits publisher-side the ones who fucked him up. Well, you're right, but that's still no excuse to lie or mistreat your people. He's expecting the publisher will eventually realise that's not possible, that the game is good enough as it is, that it's going to sell a gazillion copies anyway, just like the competition, 'Battle of Duty 7' and 'Medalfield 3', and that they have to realise the investment is done and, since delaying the game is not an option since you'd lose the Holidays' sales, they'll roll with what's there. And he's right, that's good enough, it's going to be a great game as it is, and the publishers' requests were unreasonable. But the same way he can blame the publisher for being unreasonable, I can do the same and I can blame him for asking me to spend my time working on a feature neither me nor he believes there's a chance in hell it can make it in time.

Another 'beautiful' picture, this time from Battlefield 4

Finally, the part I hate the most in these cases is when there seem to be no self-criticism and you blame overtime on games. Because, hey, you know, you can't do great games without overtime, right? Rod Fergusson (Epic) seems to believe so: "I am a believer that if you're going to make a great game, and there is that caveat, I believe that crunch is necessary". And he's not alone, infamous McNamara somehow did the same at the time, and even Ken Levine is somehow guilty of it. Justifying that crunch was necessary because you're doing something new and innovative is hardly going to help anyone nor is it something you should say publicly, IMO. I've seen it personally too, how managers justify crunch by saying "sorry, I couldn't do any better but that's normal when you're trying to do something new and innovative and creative and cool, right?"

Well, I don't know if it's normal, but definitely shouldn't. And justifying yourself instead of saying: "hey guys, I know it's been tough, but I assure you we will put the means to avoid this happening in the future because I believe this is wrong and shouldn't be repeated" is not right. You need to acknowledge the fact that this is a mistake and it's not good neither for the product nor for the team, before you can address the issues. As long as you blame the industry, the innovation, the polishing, etc., you're not acknowleging that the problem relays somewhere else: you're incapable of planning with all that in mind. It's bad to make mistakes, but only as long as you don't learn from them. Probably, if you do recognise the issues and try to improve it, people will appreciate it and believe in you. If you don't I believe you're in for a lot of trouble in the long term.

So in this world is great to hear stories from people that aim to avoid crunch and manages to do so while developing Klei Entertainment (Shank, Mark of the Ninja, Don't Starve) is apparently trying to do so (and probably with some rate of success) which is great to hear, as explained here. I personally think Mark of the Ninja one of the most innovative games in the treatment of stealth in the last few years. I think Infinity Ward tried and managed to minimize crunch time, and that while developing Modern Warfare - the first one was not only successful but innovative too I'd say. I may be wrong about that one though I can't find references on the web to back my already fragile memory. There are more, definitely, which means developing great games doesn't necessary need of long periods of crunch. We can learn from our mistakes, and try to improve the quality of life in this industry.

So, please, no more self justification with regards to crunch.