A recent post by Keira Peney got me thinking about crunch time. One of Keira’s points is that managers need to work to avoid crunch time. But I’m not sure that’s where it should start. It’s a losing battle from the trenches, because from the perspective of the company, crunch time works. It’s only when we bring the perspective of the individual into the picture that the problem arises.
The trouble comes at the very beginning of a project, long before most of the team is even on the job. It happens quietly and without fuss.
Attacking the Time Estimates
Let’s look at engineering. Game company engineers are not inferior to programmers in other industries. An experienced game engineer can create as good a time estimate as an engineer in another industry. We all know that no estimate can be perfect, but … if the game industry’s problem were just about flawed estimates, then every software company should have similar crunch issues to the gaming industry. (They don’t, in general.) So what happened? Someone cut the engineer’s time estimate.
Snipping the time estimate is easy for a manager to do. They can do it in such a way that they don’t even feel like they’re doing something bad. Hell, they usually feel good about how they’ve reined in the project’s budget. At least at first.
The trick is to cut something nobody is paying attention to right now. For instance, nobody will notice if a manager trims the beta from six months to two months. At least, they won’t notice early in the project. But later, when they do realize what’s happened, everyone will agree that a six month beta is mandatory. Since the budget has already been finalized, that means everybody just has to get done four months faster so that there’s time for the beta! Four months of crunch time for everybody!
Other easy places to cut: QA passes and bug-fixing time between each milestone, padding time to account for unexpected surprises, art revision time to rework content from contractors. Attacking these boring, tedious parts of the schedule is infinitely easier than cutting down the schedule the right way by cutting features from the game. Everybody on the team squawks and squabbles and gets demoralized when you tell them there’s no time for Crafting, but nobody cries when you cut bug-fixing time from the schedule. Who wants to fix bugs anyway?
Crunch Time Works
The trouble is that, although we often create elaborate explanations about why crunch time doesn’t help a game, it clearly does work in the short term. EA didn’t create a culture of permanent crunch time — and become incredibly rich — by mistake.
For perhaps a year, you can get more work out of your people by grinding them up. It doesn’t work forever, but over the period of, say, an expansion pack? Absolutely. Later, these people burn out and quit the industry. But you can hire more because there’s tons of people who really want to work in game development. You can pay them squat, abuse them for a few years, and let them leave. In fact, in many areas of game development, the economics seem to demand that you do just that.
Economic (Dis)-incentives
Every mainstream game team does this, to some extent. Publishers demand amazing games on shoestring budgets. If your game company doesn’t force slave labor out of their team, some other company will.
For a company like EA, I don’t know why they would ever stop crunching. They can create tons of reasonable-quality games while paying people terrible wages. They are amazingly successful, monetarily. You can’t deny that it works.
But ahh, MMOs are a bit different from your average FPS game, aren’t they? For one thing, they take 3 to 5 years to make, which means if you burn your people out every year, you notice the productivity hit whenever you have to train up new people. And because the project is so long, you can get into morale issues: the team morale can get so amazingly low after a year or two of crunch time that the entire project can easily disintegrate. You can lose everything by over-crunching an MMO.
So in a way, MMOs are safe havens. Smart MMO companies don’t want to perma-crunch their MMO developers. They wait until the home stretch — the last year — and then they crunch them to jelly. But hey, the employees at least got a few years of non-crunch-time work out of it first. Maybe they should feel lucky.
Fixing It
Fixing it has to happen at the corporate-culture level. If your company is content to be a faceless corporation with constantly-changing underlings, then there’s no incentive not to grind people up. A culture that values longevity is a good starting point.
Longevity can bring its own rewards. The best games come out of teams with a lot of experienced team members. But on the other hand, in order to get longevity, your company has to somehow survive long enough to reach old age. If you don’t crunch in the mean time, how are you going to meet publishers’ insane demands? That’s the question you have to answer, at a company level, before crunch time can end.
It is my firm hope — not quite a firm belief, because I have yet to see it first hand — but a hope that it’s really true: that having a team full of folks with 5+ years of experience is much more efficient than having a team full of brand new folks who are working twice as many hours. I can’t prove this is true. But I hope it is.
Other Venues
Crunch is a hard problem to solve for traditional games. It’s not something a middle manager can just fix unless they’re ready to have some epic battles with the senior staff.
The traditional answer to this problem is a union. I don’t think we’ll see a game developer’s union for another decade or two, because the job roles are too variable to create much common ground.
But there is an easier avenue. There are new audiences for games, like XBLA and Kongregate. These don’t yet have the same baggage as mainstream games do, so it’s a bit easier to avoid crunch time. On the other hand, these new niches don’t have a lot of well-defined genres or conventions, either, so the risk of screwing up is very high. But nothing worth doing is without risk.
