Forgot password
Enter the email address you used when you joined and we'll send you instructions to reset your password.
If you used Apple or Google to create your account, this process will create a password for your existing account.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Reset password instructions sent. If you have an account with us, you will receive an email within a few minutes.
Something went wrong. Try again or contact support if the problem persists.

Inside Job: It Takes a Method

This article is over 16 years old and may contain outdated information

In the past week I received three media requests for interviews, all wanting to know the same thing: What’s going on? Do things still suck? Have they gotten better?

I’m not sure what caused this precisely – maybe the time for re-evaluation was nigh, maybe there’s something in the collective unconscious. But after about a year and a half of the gaming media being content to assume the industry was clicking quietly along on its own, everyone seems to want to know the State of the Game all at once.

My answer is roughly the same as it has always been: Yes, there’s progress, and much of it should be celebrated; there’s still a long way to go; improving quality of life is a long and winding road populated by various jabberwockies and few sherpas.

But one of the most significant forward movements in the last three years, in addition to those documented by earlier editions of this column, concerns game production, the method by which we approach the making of games.

Primordial Ooze
Production methodologies have been discussed by a small contingent of the development community for a very long time, but by and large they did not reach the mainstream until just a few years ago. Prior to Scrum‘s galloping arrival onto the scene – online and at GDC and other conferences, primarily – game production primarily existed in the form of documenting the organically developed trial-and-error process by which games grew from independent single-person experiments into analyzed content delivered on a pre-set schedule. Most developers certainly did not bother documenting that process, even the ones who wanted to discuss the production pipeline, and in this long early period of game development, rarely was there someone whose sole function was what we would now call “Producer”; “Executive Producer” on a game usually meant the person with whom the buck stopped, and they were usually simultaneously a CEO and an Engineer. And very, very tired.

One of the earliest forays into documenting the production life cycle was Erik Bethke’s Game Development and Production, which wasn’t published until 2003 – considering the early-’80s start to the game industry, that’s quite a long primordial period. And yet Bethke’s book stands up today as one of the continuing landmarks in the documentation of game production.

In the relatively short time since GD&P, discussion of production methodologies has exploded, in part as a result of quality of life concerns and their immediate reflection on development process. The IGDA’s Production SIG has been making significant strides toward developing a knowledgebase of production methods, and last year’s related Leadership Forum was a tremendous success and a significant step forward in discussing better ways to make games from the top level down.

Can We Meet to Talk About That?
Discussing game production with a “front line” median developer is an interesting prospect. It’s a lot like politics; almost everyone has an opinion, often a passionate one, but the real answers prove complex and require a lot more debate and discussion than the average person has the stomach for.

Game production, being leadership at its heart, is a similarly difficult prospect to manage. On a basic level a producer often protects developers from themselves and the vortex of the creative process; they also frequently interact with the publisher more often than anyone else and so are the bearer of good and bad news. They may be a coordinator or a person with more authority, depending upon individual studio hierarchal structure – but in all cases they are dealing with “talent,” a volatile element that requires finessing and not simple “red stapler” style top-down authoritarian control.

This point requires emphasis: Game developers are a completely unique breed, often combining the finickiness of creative minds with the relentlessness and intolerance for inefficiency of hard-line engineers. And ideas are what they do. They represent unique challenges in management, and if they even think they’re being “managed,” you may well have problems. A producer who comes in to a game development environment with too much of a management mentality – a software development mindset of “I am the boss”-style control – is going to sink a game in short order, and may well get themselves lynched to boot. And this is without even considering the extra world of complication when you talk about integrating game design, and what exactly a game designer’s role is in the production process once it leaves the primary design phase.

Add to all of this a good dose of basic human nature and the conflicting desires of “let’s have the best production possible” and “I hate long meetings, let’s just get to work” and you have a brief sketch of why talking about game production is a fairly significant challenge. It must be Zen mastery, realizing that it is perhaps the lynchpin in a game’s development and simultaneously the least hands-on of all development roles, requiring therefore a certain egoless humility for effectiveness.

Recommended Videos

Who Wouldn’t Want to be Agile?
One of the most interesting recent developments in game production is the very recent application of systemic analysis to production methodologies. This is still very new, but is a natural result of the application of academic analysis to game creation, and the simple fact that we now have enough production methodologies to actually warrant comparative analysis.

A recent paper written by computer scientists at Utrecht University in the Netherlands uses UML diagram mind-mapping to compare four different production methods. The paper is titled “Developing a Reference Method for Game Production by Method Comparison,” and is a fascinating visual treatment of the differences between historic production methods, including those presented by Erik Bethke, those in IGDA Production SIG Chairperson Heather Chandler’s 2006 Game Production Handbook, S. Rabin’s Introduction to Game Development and observational data from the production of a casual game in Netherlands-based Zylom.

This kind of analysis represents a fascinating step forward in the study of game production methodologies. While discussion of the methodologies in places like the IGDA Leadership Forum is extremely important for the internal development of those methodologies, from an outsider’s standpoint, and from the perspective of a developer wishing to understand the production process, formalized distillation of these concepts hybridizes software development science with the game industry’s unique concerns. The advantages should be comprehensive and will be exciting to watch.

What the Method Comparison paper most notably does not include is the Agile or Scrum-based production methodology, which certainly has been all the rage in the game industry for the last couple of years. Agile’s concepts would radically alter any of the compared production methods, and a method for comparing its process to traditional methods would be exceedingly valuable. But the Utrecht paper is a valuable starting point, and discussion on its methods will be the subject of this month’s next column.

Book Learnin’
I deliberately left out links to the books mentioned above so that I could include them in consolidated fashion in what will be the Inside Job’s only bibliography. This is by no means comprehensive, but represents a starter library for anyone interested in game production. The IGDA Production SIG’s knowledgebase provides a reading list as well, but it is much longer, and fair warning that actually engaging a game producer on these subjects may result in a conversation that on its own will last until you grow old and die. These are the books I have individually heard developers swear by.

Game Production:

Software Development:

And the leading edge, containing Inge van de Weerd’s paper:

One thing is for sure: From its humble beginnings as a tacked-on luxury in the game development process, game production has grown into a full contact sport worthy of independent study. Varying opinions are legion (calling each production method a “cult” would not be far off the mark), but no one denies the importance of looking at these issues, preferably with the briefest meetings possible.


The Escapist is supported by our audience. When you purchase through links on our site, we may earn a small affiliate commission.Ā Learn more about our Affiliate Policy