Trending
Opinion: How will Project 2025 impact game developers?
The Heritage Foundation's manifesto for the possible next administration could do great harm to many, including large portions of the game development community.
Dave Prout approaches the oft-discussed topic of crunch from a different angle as he searches for the root cause. "When a team is already in production without a compelling, fun gameplay experience, it's in trouble," he says.
[In this Gamasutra opinion piece, Spark Unlimited co-founder Dave Prout approaches the oft-discussed topic of crunch from a different angle as he searches for the root cause. "When a team is already in production without a compelling, fun gameplay experience, it's in trouble," he says.]
Before I begin my descent into what some might call an untimely piece, given the economy, let me start by saying this article is not about quality of life. Enough has been written on that aspect of crunch: the colorful legal history, the unhappy spouses, and PR debacles. In spite of this, the practice remains embraced to lesser or greater degrees by the vast majority of the industry.
For the purposes of this article, I'm defining "crunch" as "compulsory unpaid overtime". Time voluntarily given from passion and enthusiasm is not compulsory, and working hard on games we love is not a crime. I'm talking about the practice and reliance upon mandatory sustained overtime, working 80+ hour weeks for a month or more, with little or no weekend time.
Productions which employ crunch have deeper problems lurking in the darkness, which are far more damaging to our industry, and imperil its future.
I'll endeavor to touch on some of these, home in on their root cause, and present some solutions which can improve our course by making our games more fun, reducing budget overages, improving our forecasting, retaining our brain trust, and of course, reducing crunch -- all to the end of making our industry stronger in the short- and long-term.
While espousers of crunch often equate it with creative passion -- a necessary duty, a sacrifice shouldered in the realization of a nascent gaming opus -- I grow increasingly skeptical.
Any project, enshrined in the pregnancy of its own importance, is able to distort the realities of its true value to the world, skew the definition of success for team members, and inflate the supposed creative caliber of team leadership. Not all games are game-changers.
Nor is crunch correlated with hit titles. Now, crunch is certainly used by highly successful studios, but it's also employed on three-month-production shovelware. Crunch might help a sucky game suck a little bit less, but really... said game will still suck. Put another way, crunch doesn't make a game not suck.
But despite the arguments against it, crunch certainly continues to happen. So what causes it?
I suspect that many production-line developers intuitively grasp some core indicators: the production didn't get serious enough, fast enough. There was too much feature-creep. Early turnover killed the momentum. Gameplay wasn't proven until too late.
Crunch happens to the most well-intentioned of us. Having been a production artist as well as a project manager, crunch has certainly happened on my watch, and I can honestly say that in the back of my mind, just knowing the crunch option exists is a warm comfort in the unpredictable hell that game development can sometimes be. When the creative lead is saying "it'll be done when it's done" and the brass are saying "this quarter is your last chance", crunch is a relieving fallback for a project manager, and to consider life without it seems tantamount to assuring project failure.
However, I have to confess, the practice itself feels like something of a cover-up. Death-marches are rarely forecasted, and the overtime they feed off of isn't tracked. Instead, crunch is heralded by its implementers as the price of entry into our truly amazing industry. Common practice or not, one cannot make good faith assurances to an investor regarding budget and date targets, if said assurances are dependent upon significant, but unknown, quantities of free labor.
I posit this: if you hear of a studio that is on a death march, it's a good bet the project leadership doesn't know what it's doing, because it doesn't know what it's making. It doesn't know what it's making because the gameplay experience hasn't matured into demonstrable, compelling fun. And if it hasn't achieved fun, then it entered production too soon, and the leadership is investing blindly in the project.
Investing blindly in the project means lots of money wasted developing lackluster features that never even succeeded on paper. Bad ideas make it in, cuts are handled sloppily, and the project's costs balloon to try to contain a project spiraling out of control.
In the end, the game isn't as good as it might have been. It cost far more than it should have. The team is burned out (and facing probable layoffs). The project leads are probably considering leaving the industry. The investors feel burned by the project's performance and look for other places to spend their money.
For the game and the studio, it's a lose-lose-lose. For the game industry, these projects are mortal wounds that have devastating and lasting effects.
Let's back up to the root cause of all of this. When a team is already in production without a compelling, fun gameplay experience, it's in trouble. Crunch is a symptom of the root cause of premature production; by resolving premature production, the need for crunch will massively diminish.
In film and television, if an early treatment was suddenly plunged into full production, it would be considered a catastrophic failure of the development process. In the game industry, when a fledgling creative vision is suddenly staffed with talent, it's considered ensuring success. This is a fundamental fallacy in our thinking.
An unproven creative vision is not helped by prematurely burdening it with a production team, which waits around for something to do. When that happens, creative development slows as the preproduction team is forced to manage the production team. The new voices second-guess the direction before it's had a chance to mature. The larger team's burn rate makes executives anxious. Pressure to produce demonstrable results draws political boundaries. The creative vision holders are pushed to compromise, and development becomes reactive, rather than proactive.
In reactive development, crunch comes quite naturally. At this very moment, there are productions for which this situation is a true fact. Is it any wonder why we, as an industry, still employ crunch?
The benefits we stand to gain by protecting against premature production are immense. Better games come from improved early creative development. Eliminating creative unknowns facilitates stable production. Stable production facilitates massive savings, and the need for crunch diminishes -- in fact, crunch will become a warning sign that a project is off track (just like in other industries). Ship dates can become predictable, and our talent can enjoy long-term careers in the industry.
The road to a crunch-free game industry will ironically require sacrifice and innovation. As project leaders, we can't be satisfied with the familiar money- and talent-bleeding approaches; we need aggressive results -- projects that are more fun, created for less money, in less time. We need to work at least as hard at the beginning of a project, as we ask our talent to work at the end of one. Our success needs to be defined by higher quality games, reduced actual costs, and sustainability of the investment in our talent.
We are all familiar with the concepts of technology risk, pipeline risk, production risk, and visual quality risk. What we don't properly account for is "fun risk". "Fun Risk" is not the sum of the others; it's a totally separate thing.
Fun is the reason to buy a game. Fun is required for great sales and scores. Fun needs to be argued about, tested, iterated upon, sweetened, objectively evaluated, and it deserves a prominent place in project documentation and the schedule.
While many companies profess to have a green-light process which culls unviable projects before the full investment has been spent, I haven't heard of one yet that, in practice, truly requires projects to demonstrate the core fun factor before entering production. Green-light processes need to reflect the concept of "fun risk".
Fun Risk is the greatest of all risks. We should follow the lead of more successful creative teams in our industry: play it before we build it.
Our games must be compelling before the tech design and visual targets, and before production planning begins. To prioritize differently misunderstands the nature of what we make. People don't buy games. People buy fun.
Through quick-and-dirty rapid prototyping, even with the intent of throwing away this implementation once a viable proof-of-concept is achieved, we can ensure that fun happens first. The great thing about this approach is that "fun" can be proven for relatively little investment, utilizing only a small pre-production group.
If a game needs to be fun before production financing comes, it greatly simplifies the focus of pre-production. When fun is proven in pre-production, creative experimentation will not occupy a critical piece of the production schedule. The impact of properly addressing "Fun Risk" has on crunch is that the creative unknowns become known, the road ahead is predictable, and a sound production plan can commence.
The effort to resolve creative unknowns can also be aided by a few tools: cost transparency, early user testing, and a right-sized pre-production team. Even if your project is death-marching, if you have major unknowns, these tools can help decompress your project and make the production more bearable.
Cost Transparency. It may sound as exciting as tax law, but cost transparency provides an invaluable decision-aide: the stalwart cost-benefit analysis. A cost-benefit analysis of creative design features facilitates sound prioritization of those features around actual gameplay value, which reduces time wasted on dubious features.
In pre-production, a feature's perceived gameplay value can be paired to its estimated cost (estimated cost can be quickly gleaned on the back of a napkin). By estimating costs for the majority of a game concept's ideas, we can get a ballpark cost-benefit value range and use it to make informed decisions on which ideas, if invested in, will return the best player value.
In game development, almost all costs are labor costs, so we can't have true cost transparency if we don't have labor transparency, which includes overtime. Without including overtime, the cost-benefit analysis will produce flawed values; it's the equivalent to "cooking the books". By factoring it in, areas of waste in the production can be illuminated, and through their elimination will create savings as well as reduce the need for crunch.
When using cost transparency in production, actual costs can be captured (and again, for costs to be "actual", they need to include overtime labor). Actual give more precise cost/benefit values, and often reveal hidden waste in the process (for example, discovering long light bake times, month-long lead times for legal contracts, or time zone delays with remote vendors). Making waste visible allows it to be managed and eliminated from the flow of development.
Whether in pre-production or production, cost transparency begins to add value as soon as it is implemented. Even if a project is careening off the rails, this practice will help the team leadership gain confidence in its decisions and sleep better at night.
Early User Testing. Another way to validate fun is to solicit the feedback of an objective party, in the form of early user testing. Understandably, exposing a fledgling idea to group of insensitive players can be nerve-wracking. But over time, the criticism received will improve the team's knowledge of its customer, and its creative decision-making.
Start with testing small combinations of features that create a component of the game experience. As confidence builds and iterations grow stronger and stronger, test larger components or component combinations.
To do it on the cheap, enlist the help of local schools and make it a field trip event; to keep it confidential, keep the content generic and use the project codenames. If there are enough users, segment the tests to allow only a small portion of the game to be seen and played.
Charging a non-interested party (such as an experienced test lead) with design and execution of an ongoing user testing program will help ensure objective and accurate results. Beyond providing a sounding board for the creative team, the data gleaned from these tests also helps build confidence with investors and stakeholders.
Well-conducted early user testing serves to ensure the game resonates with the market and that it maximizes those traits which resonate best. Less time is wasted by taking fruitless paths, and the product can come into focus more clearly.
Right-Sized Production. "Right-sizing" is a concept borrowed from Lean development, and it essentially goes like this: design the composition of the early development team around pulling small increments of fun factor onto the screen, at regular intervals. It's important to design the team around the increments -- not the other way around. For example, building a team by hiring four members of each discipline is arbitrary; but hiring a system designer and gameplay designer, an art generalist, and a gameplay engineer and AI engineer can be a terrific rapid prototyping team.
As mentioned above, the first place for this right-sized prototyping team to focus is the fun factor. Wherever the original idea came from -- a character or story, a business concept, an imagined scenario -- work must begin immediately to realize the moment-to-moment game experience. Consider the implementation to be disposable -- you're after the realization of the idea, not an ideal tech design. Making this a rule will free up engineers to contribute to the realization of the vision (and hacks are perfectly acceptable).
A core element of playable gameplay, in prototyped form, can save hundreds of thousands, even millions, of production dollars over its document-based counterpart.
"Fun" has never proven itself in document form. If it's not on the screen, it's just an idea. What is on the screen should speak for itself. Allow nothing to distract the team from prototyping their ideas.
This sometimes includes the conception of the idea itself -- it's critical to put theories to the test and learn empirically from those tests. Don't ruminate and noodle for days and weeks on theories. Even setting a time limit for experimentation can help tighten these iterations. Test them, and see if they're fun.
While many techniques have been discussed surrounding rapid prototyping, the purpose for it often gets forgotten. Fun factor is difficult to glean from cardboard mockups or sandboxes. Test ideas on the destination platform, or as close as possible to it; for example, if you haven't gotten approval yet to get Unreal on a 360 Dev Kit, use a 360 controller on a PC using the UDK.
Nothing should distract from proving out the core gameplay -- not the game story, not the technology, not the art direction. None of these things are the core value the gamer is looking for.
Maintaining focus on the fun is the greatest benefit of a right-sized prototyping team. Keeping costs low is an added benefit. When right-sizing is used properly, quality will improve and costs will decrease compared to a typical paperwork-and-meetings-driven pre-production. By defining the fun early, production can truly be about executing on the proven direction. All three of these benefits reduce the need for crunch.
Employing all of these tools -- Fun Risk, Cost Transparency, Early User Testing, and Right-Sized Production, gives excellent control and visibility to project leadership, and provides a means to avoid the runaway costs which lead to crunch.
There are some consistent practices that I've seen employed over the years which are common to successful teams:
Very early on, identify the aspects of your idea that you expect will make it a compelling game experience. Get a sense for how important each one is to the game. Work hard to define them at the paper stage. They should be in plain English, free of marketing-speak, and easy enough for your grandmother to understand.
Set a time budget for creative experimentation and iteration. Force yourself to commit at regular intervals.
Embrace no-frills rapid prototyping to prove out the hoped-for player experience, and iterate like hell.
Start user testing early. Kill poorly performing ideas quickly.
Regard the fun factor as the number one risk, and design your pre-production around mitigating that risk. (Tech is never the primary risk. Neither are the visuals.)
Embrace cost transparency from the beginning of pre-production, and use its data to aid creative decision-making.
Measure overtime and assign a cost to it, even if it's purely symbolic. Tracking it will illuminate waste in your production.
Build in regular work evaluations and course corrections to your development methodology.
I believe that our industry's reliance upon compulsory unpaid overtime will end in the coming years, one way or another.
Though this piece has revolved around the root cause of early designs being thrust prematurely into production, it wouldn't be complete without mentioning the human toll that compulsory overtime has taken on every colleague I know. Crunch destroys our health, marriages, personal relationships, and relationships with our kids. The old incentives which were used to retain talent -- promises of future riches and power -- have proven empty for all but a lucky few.
The year 2009 was the most tumultuous for our industry since 1985. Letting entire teams go at Gold Master has become an accepted practice; these days it often doesn't even make the gaming news. Publishers -- not just developers -- closed their doors. The old incentives don't hold much water anymore.
This industry-wide loss of trust in these incentives bodes poorly for the practice of crunch; the talent is the wiser. As employment stability declines, so do developers' loyalty to specific studios. In its place, association with successful projects is more important to landing the next gig.
The proposals I've outlined here are intended to help us transition to what's coming. By remembering that fun is our core product, and employing proven ways to streamline its creation, our games can be more fun, budgets can shrink, street dates can stick, talent can stay, and overtime will once again be spent primarily through passionate creativity.
[Photos by Joseph Nicolia and Tim Patterson, used under Creative Commons license.]
Read more about:
FeaturesYou May Also Like