{"id":31667,"date":"2016-04-26T06:00:13","date_gmt":"2016-04-26T10:00:13","guid":{"rendered":"http:\/\/www.shamusyoung.com\/twentysidedtale\/?p=31667"},"modified":"2017-08-01T07:43:59","modified_gmt":"2017-08-01T11:43:59","slug":"this-dumb-industry-in-defense-of-crunch","status":"publish","type":"post","link":"https:\/\/www.shamusyoung.com\/twentysidedtale\/?p=31667","title":{"rendered":"This Dumb Industry: In Defense of Crunch"},"content":{"rendered":"

Last week I derided permacrunch – the policy of working an entire creative team 70 hours a week all the time – as “the policy of simpletons and sociopaths”. This led to some people asking, “Why is crunch even a thing?” Can’t management just plan the schedule so that the project is done on time using only 40 hour work weeks?<\/em><\/p>\n

Sadly, I don’t think that’s a fair expectation at all. And it’s not because management is a bunch of soulless meanies who want to work our poor developers to deathI mean, management might still be soulless meanies, but not for this reason.<\/span>. The problem is twofold:<\/p>\n

    \n
  1. Scheduling is hard<\/strong>. To accurately predict how long it will take you to create software, you’ll need to know all the problems you’ll encounter ahead of time, and how long it will take to solve them. By the time you know that, the game has probably shipped.\n<\/li>\n
  2. There’s no upper limit on how much time you can spend making a game<\/strong>, and no matter how much time you give the team, some developers will always push for “just one more feature”. Not because they’re stupid or irresponsible, but because they really love games<\/em> and want to make this one really good. I say this from experience. Good Robot<\/a> shipped about four months later than we planned, because we had more features we wanted to add. And none of us were getting paid until the game was done. If we were willing to delay our own payday<\/em> to make the game we wanted, how much easier do you think it is to push for more features when you’re not the one who will have to bear the direct financial consequences?<\/li>\n<\/ol>\n

    Scheduling isn’t just a problem in videogames. It happens in all kinds of software development. When asked “How long will it take to accomplish X?” the most common answer will be given under the assumption that when you work on X you’ll never encounter hard-to-identify bugs, that the requirements of X won’t change, and that some obscure hardware problem won’t eat up a bunch of your time. It assumes you won’t have staff turnover that requires integrating someone new to the project. It assumes that no programmers will be pulled away for “just a few days” to deal with some horrible crash or exploit in the game you just shipped, which might actually stall the whole team because everyone’s work is interconnected. It assumes that the design itself is perfect, that all systems will work as imagined on the dry-erase board, and that everyone’s artistic and technical ideas will fit neatly together in the final product.<\/p>\n

    Welcome to game development. Please tell me how long it will take everyone doing jobs you don't understand to do all the things you don't know they're going to do in order to solve problems you don't know you'll have.<\/div>
    Welcome to game development. Please tell me how long it will take everyone doing jobs you don't understand to do all the things you don't know they're going to do in order to solve problems you don't know you'll have.<\/div><\/p>\n

    I hear you say, “So just multiply your estimate by some number!”<\/p>\n

    Okay. What number? Two? Ten? Should I just make up some random bullshit multiplier?<\/p>\n

    Keep in mind that when you’re giving a quote like this, you are basically making a promise to get the job done for a certain price. Management is trying to figure out how much videogame they can get for their money, and how risky that endeavor will be. Massively padding out your proposed schedule doesn’t help them make informed decisions. <\/p>\n

    If you make your quote too high, the project might get canceled, or they’ll start cutting features before you even start. The problem is that management has no ability to know if your estimates are accurate or not. They can’t know if you’re being conservative, or optimistic, or if you’re just padding your schedule to make yourself look good. They have other projects they could be risking the company’s money on, and if yours sounds too expensive then maybe they will cancel your project and do something that seems less risky. Maybe they will assume you’re a bad project lead and give the job to someone else. Or maybe – and this is the really terrifying one – they will pull one of your colleagues into the meeting and ask them for a quote. Better hope they come up with the same time estimate and the same bullshit multiplier!<\/p>\n

    But let’s talk about the biggest scheduling hazard of them all: You want to make the best game possible.<\/em><\/p>\n

    Feature Creep<\/h3>\n

    BE THE PUNCH GUY.<\/div>
    BE THE PUNCH GUY.<\/div><\/p>\n

    You’re about halfway done with Punch Guy 2: Punch Harder<\/em> when one of the gameplay coders shows you something he’s stumbled on. It’s an emergent behavior we hadn’t planned on during the design phase. Our new “destructible environments” feature combined with our “punch guys over railings” feature, and created this situation where you could punch someone through a window. Once people found out about this, they formed a little group around one of the testing computers. All afternoon there’s been a rotating group of five or six people passing the controller around, blasting dudes through windows with uppercuts and cheering. It’s the most enthusiasm the team has shown in weeks.<\/p>\n

    Everyone who tries it says, “We should add this to the game.” Moments like this are why you went into making games in the first place. It’s an obviously fun feature, its something your rivals making Fist Man<\/em> don’t have, and as a bonus it will look great in trailers. Obviously you’re a fool if you don’t put this in. And the feature is basically done, right? So this accidental thing is given the blessing to become a real feature. You don’t need to put it on anyone’s to-do list, since people were basically already working on it in their “spare time”.<\/p>\n

    But as time goes on, it becomes clear that the feature is not actually as close to done as it seemed. Over the following weeks, a gradual trickle of new issues get added to the global to-do list:<\/p>\n

    1) There are only a couple of windows in the game where this feature can be used. We should have the level designers go in and add a few more, where possible. <\/p>\n

    2) Windows were originally supposed to be un-breakable, so right now there’s nothing but a black void outside. Level designers will need to go back to completed levels and add some sort of facade for the world outside the window. (Which artists will need to design.)<\/p>\n

    POW! WHAM! BAP!<\/div>
    POW! WHAM! BAP!<\/div><\/p>\n

    3) The AI doesn’t recognize it’s been punched out of a window, which means the victim just stands outside of the level, shouting combat taunts. This might lead to players getting stuck in areas where their goal is to defeat everyone.<\/p>\n

    4) The lead artist is driven crazy by the fact that you shatter these dirty external windows and the lighting doesn’t change in the room, even though it should let more sunlight in. She insists that we add some dynamic lights to deal with this. In the end, she’s right. It really does give the window-breaking an extra visceral kick, because it gives the player an additional way to change the environment. But it also means a little more fussing around and generally adds a bit more overhead to building levels.<\/p>\n

    5) There are a bunch of strange edge-cases where you can punch a guy out of a window, but other dudes are between the victim and the window. The victim sort of floats through them, which looks horrible. We need changes to the AI or fight logic to handle this.<\/p>\n

    Um.<\/div>
    Um.<\/div><\/p>\n

    6) A tester punched the final boss out of a window and ended the fight in 5 seconds. Remember that being punched out of a window is actually just being punched over a railing, which was supposed to be an insta-kill as far as the game is concerned. But we don’t want players to be able to insta-kill the final boss. <\/p>\n

    We originally dealt with this by not having any railings in the final room. But we can’t remove the windows from the final room. The cutscene animator is adamant that this window is integral to the pre-fight cutscene. It’s major component of the lighting in the room, and one of the characters even looks out of the window and comments on something outside. Removing this window would mean re-writing this scene, re-scripting the action, re-recording the dialog, and re-designing the room layout. The artists say you should make the window unbreakable, which the gameplay designer hates because it goes against the established rules for no good reasonAs far as the player is concerned.<\/span>. He thinks the window should be removed, which the art team hates because they don’t want to throw away all this work and make the scene less visually interesting just to solve an “exploit””You want us to trash the room we’ve spent the most time on, because you can’t balance the fight mechanics?”<\/span>. <\/p>\n

    This debate goes in circles for weeks. Eventually some bright young kid comes up with the idea of making the window “strong”. It cracks every time you slam someone into it, and on the third impact it shatters. Maneuvering the final boss to be thrown into the window three times is actually more difficult than just doing the fight normally, although it is faster. This seems like a good compromise, and even a nice side-goal for skilled players. <\/p>\n

    This solves the problem, but requires even more work from everyone.<\/p>\n

    7) The art team thinks the glass particles need to be re-worked. They were fine if this was just a random bit of scenery shattering, but now that this is a major feature and it’s going to be in cutscenes and trailers, we really need the bits of glass to glitter in the sunlight. There should be dust. And there’s a three-day debate in email where the team argues if it makes sense for there to be flying blood particles or if lacerations from flying glass wouldn’t start visibly bleeding until after the body hit the ground. Suddenly everyone is citing Wikpedia, or Myth Busters, or their cousin who’s an EMT, all trying to give a definitive answer to justify their vision. <\/p>\n

    STAB GUY was a spin-off series that turned out to be a critical and commercial disaster.<\/div>
    STAB GUY was a spin-off series that turned out to be a critical and commercial disaster.<\/div><\/p>\n

    8) The really big foes – “bruisers” to the dev team – don’t look right when going through a window. They’re so tall that their head passes through the frame at the top and their arms often clip through on either side. We need to either make them immune to throws in front of a window (the gameplay guy throws a fit at this suggestion) or we need to record a couple of new animations where they… I dunno… maybe tuck in their arms and head so they fit through the window? Can the animators make that look good? (The lead animator looks like she’s going going to bite someone when you mention this to her.)<\/p>\n

    9) The flying glass particles we added? Now the sound designer says his effects no longer match. His sound was originally sort of a generic “something broke” sound, but it’s totally inappropriate for this cloud of flying glass shards we have now. He wants to add a few new sounds for this, and he needs the scripts for the windows to be changed to use these new sounds.<\/p>\n

    10) In the warehouse level, guys are scripted to jump IN through the windows for the set-piece brawl. This is confusing as hell for playtesters, who all wanted to stand in front of the window and punch guys back out the moment they jumped in. This doesn’t work the way they expect, and it would be lame if it did. We need to change something so that players no longer want to do this. Eventually – after weeks of back-and-forth – we have the guys enter through some sort of chute.<\/p>\n

    Suddenly this “tiny” feature has gobbled up a couple of weeks worth of development time. It’s not management’s fault. Nobody here is a bad guy. Nobody is incompetent. The only way to avoid stuff like this it is make a firm rule of NEVER EXPLORE AWESOME FEATURES THAT AREN’T IN THE SPEC, and I don’t think anyone – developers, players, managers – wants that.<\/p>\n

    Games are Never Finished, Only Abandoned<\/h3>\n

    You know you're at the end of your Halloween candy when you start eating these. It's like munching on a chocolate-flavored candle.<\/div>
    You know you're at the end of your Halloween candy when you start eating these. It's like munching on a chocolate-flavored candle.<\/div><\/p>\n

    And all of that was just one issue, out of the dozens that arise during development. There’s another issue – just as big and complicated – where we change it so the player can choose to push a button to kiss their girlfriend, rather than having the hero kiss her in a cutscene. That results in days of debates and arguments over player agency and which button to useYou can’t use X, we use that for punching! But Y is for jumping, and that doesn’t seem right. Grapple? Choke? A philosophical debate ensues: Which of our violent gameplay verbs is closest to “kiss”?<\/span>. <\/p>\n

    There’s another issue where – after weeks of struggling – we conclude the fistfight inside the car during a high-speed chase just isn’t working. The sequence is scrapped, but then someone tries to salvage it by having the fight happen in the back of a box truck, but it’s too late in development for all the required animations, cutscenes, and dialog, and the feature is finally cut for good.<\/p>\n

    The whole project is filled with these sorts of decisions. Every week is a new challenge of “Something we did last week created unforeseen consequences this week, which can only be solved by cutting features or doing more work.”<\/p>\n

    Actually, Scheduling is Impossible<\/h3>\n

    ALSO STAYS CRUNCHY WHILE GOUGING DEEP, SLOW- HEALING LACERATIONS IN THE SOFT PARTS OF YOUR PALATE.<\/div>
    ALSO STAYS CRUNCHY WHILE GOUGING DEEP, SLOW- HEALING LACERATIONS IN THE SOFT PARTS OF YOUR PALATE.<\/div><\/p>\n

    Even if the project manager is a genius that correctly predicted how long it would take to make Punch Guy 2: Punch Harder<\/em> according to the original spec, the game is still behind schedule because of all of those things that were added or changed during development. And note that if the project manager had doubled their estimate so there was lots of room in the schedule, people would simply have devoured that time by adding even more stuff. (For example: Maybe we would have stuck with that fight in the moving vehicle until we got it working.) <\/p>\n

    Even in a company where all of the executives are kindly saintsPlease tell me where to send my resumé.<\/span> and the project manager is a scheduling masterAh, so this company is apparently based in “Opposite World”.<\/span>, the game is still running out of time. Not because anyone was “evil”, but because the team itself wants to make the best game they can. This team enthusiastically added the window feature on their own, knowing full well that the ship date wasn’t going to move. They are stretching themselves to solve difficult problems to make the most entertaining game possible. That’s literally the reason they entered this field in the first place. That’s the part of the job they love. It’s a challenge to overcome, and they imposed it on themselves.<\/p>\n

    Crunch is simply the moment where everyone’s soaring ambitions come face-to-face with the limits of a cold, uncaring universe. Limitless ambition will always be at odds with finite resources, and the end of the project is where those two forces collide and are reconciled. <\/p>\n

    So then somebody says, “Then companies should adopt policy of releasing a game when it’s done, like Valve, Nintendo, and Blizzard!”<\/p>\n

    That’s nice if you’re sitting atop vast cash reserves, you’ve got the best talent in the industry, and your games are guaranteed to sell. Not all companies have the luxury of open-ended development. THQ folded in 2013<\/a>, and took a lot of jobs with them. Closing a company is brutally painful for hundreds of people, and you can’t really blame the managers who avoid this by restraining games to a finite budget.<\/p>\n

    And just to play devil’s advocate: Imagine you’re a corporate manager. You allocated $X million to Punch Guy for a Christmas release. And now the project lead comes to you in late summer and says he needs more time (money) to finish the game, and when you ask why he tells you about all this stuff – like the window feature – that you never agreed to and wasn’t in the design document. Pushing Punch Guy back would make the game cost more AND it will force you to pass up the massively profitable Christmas sales AND it will put Punch Guy 2 on the shelves in February, where it will compete with Shoot Guy, one of the other titles that you manage. It’s your entire job<\/em> to say no to stuff like this. Besides, you’ve only got so many dollars to go around. The Punch Guy team went off-mission and now they expect to be rewarded with more money? Why should it go to the Punch Guy team and not the Shoot Guy team? <\/p>\n

    Fans are still buying the SHOOT GUY games, but critics have been complaining that the shooting felt kind of 'played out' for the last few entries. Marketing thinks maybe what they really want is some punching elements.<\/div>
    Fans are still buying the SHOOT GUY games, but critics have been complaining that the shooting felt kind of 'played out' for the last few entries. Marketing thinks maybe what they really want is some punching elements.<\/div><\/p>\n

    Sure, you can probably schedule a project down to the day, as long as you’re doing something very familiar. If this game is just last year’s game with new maps, then I guess we can just turn development into a conveyor belt. If we don’t want to invent new gameplay then we don’t need to allow for the R&D that new gameplay systems require. <\/p>\n

    Crunch is most likely to happen to teams that are ambitious and try to do a little more than their budget allowsUnless we’re talking about crunch imposed as a “money saving” effort, which we discussed last week.<\/span>. It happens when people try to innovate. When they polish a game through iteration. Which, incidentally, are the very things needed to become<\/em> like Valve, Nintendo, and Blizzard. <\/p>\n

    So yes, I think late-stage development crunch can be part of a healthy studio. Which is why I’m adamantly against mandatory perma-crunch<\/strong>.<\/p>\n

    Like a distance runner saving some energy for the last sprint, you want the team to have fuel left in the tank when it’s time for the big push. You want them to have some enthusiasm left when it’s time to start making the tough choices about which features need to be cut and which ones we can finish in time. You want them to surge forward when they see the finish line, and that can’t happen if they’ve been working 6 days a week for the last year. If the team is wearing out, then their output will slow down just when you need it most. Sane work hours and good morale give your team the ability to sprint when it looks like the ship date is at risk. <\/p>\n

    Perma-crunch is stupid and destructive, but voluntary<\/em> crunch by people who are trying to push the medium is a good thing. Hard work is not bad or evil. Great things can happen when you’re willing to push. But people are not machines, and they need to save their energy for those moments when it will count the most.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Last week I derided permacrunch – the policy of working an entire creative team 70 hours a week all the time – as “the policy of simpletons and sociopaths”. This led to some people asking, “Why is crunch even a thing?” Can’t management just plan the schedule so that the project is done on time […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[102],"tags":[],"class_list":["post-31667","post","type-post","status-publish","format-standard","hentry","category-weekly-column"],"_links":{"self":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/31667","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=31667"}],"version-history":[{"count":0,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/31667\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=31667"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=31667"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=31667"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}