After a long absence, there's an update on methodblog!

Hopefully more are to come. It's been far too long.

Meanwhile, I have some material for you to check out, based on the talks I've given recently at the DICE and GDC conferences.

First, a video of the DICE talk has been posted at AOL videos here:
http://video.aol.com/video/aol-gamedaily-dice-lectures-7-michael-john/1857347

The DICE speech was my first ever public talk, so it... wasn't great. But the quality is very good, and it got this whole ball rolling so worth checking out.

Second, you can get a copy of the audio from the GDC talk here:
http://store.cmpgame.com/product.php?id=2110

I also put the slides up as a flash file on my own website here:
http://www.methodgames.com/gdc/

The audio and the flash files go quite nicely together btw.

Last but not least, I re-wrote the "Apron Strings" portion of the GDC talk and published it as a .pdf file here:
http://www.methodgames.com/gdc/mj_gdc_2007.pdf

The file there is only half the presentation (it omits all the discussion of a union), and is kind of rewritten and abridged from the actual talk. But the key points are in there.

Enjoy!

I recently discovered a GDC presentation from 2006 by Clinton Keith, of High Moon Studios. High Moon is now well known as the principal proponent of agile methodology in game development.

I found Clinton's presentation compelling, especially in the manner in which he tweaks the 'agile manifesto' for the context of game development. Here is his tweak on the manifesto:


The Agile Manifesto (modified for game dev):
We value…
• People and communication over processes and project management tools;
• Working game over comprehensive design documents;
• Publisher collaboration over milestone definitions;
• Responding to change over following a plan;

When I read this, it caught my attention, because these are four principles that I believe in without reservation. And what's more, they are principles that are rarely adhered to with consistency in the industry, especially as we scale our projects. I was particularly taken with the third point:

• Publisher collaboration over milestone definitions;

This was a point that Mark Cerny and I made in our Cerny Method definition back in 2002, but is an element that has been understandably lost in favor of the core concept of preproduction. I'm going to focus on this point for the purpose of this blog entry because it is crucial, IMO, to improving the overall creative and business health of games development.

It's an Entertainment Medium, Stupid
The first thing to remember is that making a game is not like making a widget. I know, obvious, but if you look at a typical "milestone" schedule agreed upon between a publisher and a developer, that has "widget" written all over it.

Keith uses an example of creating a core moveset for a character. The moveset is well-defined heading into the development, but just after jump is developed, the creative team discovers that the game will be significantly more fun if a flight mechanic is included. The smart, 'agile' team recognizes this as cool, but also speculative and high-risk, and bumps it way up in the queue, to be developed in their next scrum "sprint".

Oops, you just fucked your milestone schedule.

In order to give space for that key creative magic to kick in, the team must not be held to strict deliverable lists. To reprise (and quote verbatim) the Cerny Method, "traditional milestones should not exist during pre-production." (Just for the record, I most decidedly do not reject the notion of highly specific milestones, when applied during actual production. These become key metrics for a team's capability to deliver the game on time once production begins.)

Still, it's not unreasonable for a publisher to expect some accountability and tracking capability for a team who is probably spending a great deal of its money and absorbing a great deal of its opportunity budget. To me, the solution is really obvious, but seems really hard to get implemented in actual development: publishers should pitch the milestone schedule in the trash, and get closely involved during pre-production.

Sadly, both the publishers and the studios seem to find this idea distasteful.

"Those Guys are Idiots"
This is what most development studios feel about publishers. Tell me I'm wrong. I've read it so many times in internet postings, heard it in conversations... even said it myself far more times than I'm proud of. This is an incredibly short-sighted and just not very bloody smart way to conduct business as a development studio.

First, it's very unlikely that the publisher really is idiots. What is likely, is that their agenda is very different from yours. Publishers' producers rarely work on only one or even two projects; their attentions are divided, and what's important from one week to the next probably blows like the wind based on corporate priorities. One week it's your project, the next week, you don't exist. Not a good recipe for collaboration. But it's the nature of the beast. Publishers are corporations, and corporations by definition are unwieldy, inefficient and fickle. But, they also have money. And without money, you probably have no project.

Second, let's assume the publisher really is a collective idiot. You are now in possession of that idiot's money, and if you expect the money to continue to work on your behalf, it is your responsibility to educate the publisher. If you're unable to do so, one or the other of you has failed, but your project is in trouble.

A third possibility is that you've got some secrets you're hiding from the publisher you'd rather they didn't know about (where are those dev kits, anyway?). This obviously is no excuse at all, and you shouldn't be in business.

Assuming the above, development studios should be inviting publishers into their buildings. By having the publisher present, you can be more assured that you are on the radar, and that your agendas align, and if the publisher really is kind of a dope, well this is your big chance to show them what's what. Get them in-house.

"Those Guys Don't Have a Clue What They're Doing"
Meanwhile in the halls of the publisher, a studio has missed another milestone, and is trying desperately to convince you that no, really, this time they're on the right track. Yeah, right.

Chances are, your studio is struggling with genuine creative issues. I know from experience that the tendency when this happens is to 'turtle' vis-a-vis the publisher, and buckle down to really push through the problems. Maybe you will...maybe you won't.

Here's where the publishers fail. When a studio misses milestones, the publisher should be trying hard to determine whether the studio is in over its head, is slacking, or maybe just has found itself having to redefine its project in order to 'chase fun'. Regardless, simply turning down a milestone and putting the studio in a money bind is probably the single least productive thing a publisher can do in this case. And yet, this is exactly what 'the book' suggests they do. Instead of investing the effort of paying a couple-day visit to the developer to really see inside the project, publishers turn to their business affairs staff to try to see what 'leverage' can be applied.

The Actual Solution: No More Milestones
Which brings me back to Clinton Keith. His manifesto calls for "publisher collaboration over milestone definitions." I'll do him one better - let's get rid of "Milestones", meaning deliverables attached to payment, altogether.

So what do we do instead? How do we get accountability and transparency without these 'milestone' deliverables? How can we continue to do business?

Well, the answer is right there in agile methodology. Have a look at a definition of 'scrum', one of the currently popular renditions of agile methods. Scrum involves "sprints" in which digestible chunks of work are done, followed by a review of the work. Hmm, sounds like accountability to me. At the end of a sprint, the team assesses, plans, and sets up for the next sprint. Hmm, sounds like planning to me.

So why aren't we doing this?

Studios: Open Up the Doors
I alluded to this already, but the replacement for a development studio is simply to open your doors to the publisher. Let them see what you're up to. Of course this is a little scary, especially if you feel your publisher's representative is not sophisticated. But educating them is your job. This is what you do in exchange for removal of that horrid Sword of Damocles called the 'milestone payment'. Sure they may disagree with your processes in uncomfortable ways, but is that really worse?

Publishers: Shit or Get Off the Pot
Publishers: You're either funding a project, or you're not. The most obvious meaning of this is with finance... I know of no examples where choking the money supply for a project actually improved the project. I can understand a publisher wanting to avoid giving the studio the money in a single lump sum, so monthly or bi-monthly stipends would be fine. More importantly though, milestones give publishers an opportunity to "fire and forget" on a project. The statement "we'll see how it plays next milestone" is a sign of managerial failure on the part of the publisher. The publisher's commitment to a project should go well beyond the financial; if you plan on exercising any control at all over the project, that control needs to be applied constantly and consistently, not at essentially random "milestone" intervals.

I'm Warming Up...
As you can see, I'm beginning to warm up to agile methodology, as the particular game development version of it evolves. When looked at in this particular light, I'm even beginning to feel that the agile approach may be able to function as the can-opener to eliminating some of the most destructive current business practices in games.

Stay tuned for more.

Making games is rightly characterized as a battle against complexity and inefficiency these days, and there are many approaches to solving this issue. Certainly Agile Development, a recent topic of this journal, is an important response to complexity. But the most important trend, and one that I'm quite sure is here to stay, is the powerful shift toward data-driven development.

First a definition of data-driven development as I understand it. The simplest way of describing it would be to say it is a shift of the programmer toward general-purpose code, while moving specific-purpose functionality to non-technical staff, usually part of the design team. So whereas ten years ago gameplay would have been built primarily by programmers, probably using tools they wrote themselves, now the programmers build more robust and user-friendly tools, and rely on designers to do the actual implementation by entering data in some combination of:
- Points and primitives in 3D space
- Parameters applied to game objects
- Scripts driving behaviors of game objects

My initial reaction to data-driven development has been negative. It violates one of my Tenets of Game Development (which I should probably start writing down somewhere), specifically: "Have the person who's best at doing a thing, do that thing." I felt that when it came time to implement interactivity, the best person for the job would be a gameplay programmer. And to an extent I still believe that.

But I quickly realized that this was not a fully intellectually honest approach. In fact I have never worked on a game where I didn't spend at least some time personally manipulating tools, usually quite a lot. And though this was sometimes the result of desperation, usually it is not - rather these have been situations where I was indeed the person who's the best at the thing.

But this is not why I think that ultimately data-driven systems are here to stay. Simply put, great gameplay programmers are exceedingly difficult to find. Especially as programmers are now expected to be proper C++ engineers, not just hackers, the intersection set between people with great technical skills and great game sense is shrinking year by year. Combined with that is the issue of supply and demand, and the fact that designers are relatively easy to find, in contrast with qualified game engineers. In fact a recent estimate by the USC school of engineering puts the demand for programmers versus designers at 65% versus 5%. While this is almost certainly a self-serving estimate by a school of engineering, even if it's halved the demand differential is dramatic, and this is confirmed by my own recent experience in hiring.

When programmers see themselves becoming increasingly the weak link and consequently those mostly likely to suffer crunch time, it's only natural for them to want to retreat into pure engineering, and push the gameplay onto somebody else via data-driven systems. And applying pretty simple rules of economics, this is not going to change anytime soon.

And that's not necessarily all bad. Having an open acknowledgment of the fact that much of the implementation will be done by the design staff causes us to hire a couple more designers than we might, and to build tools that enable them to work more efficiently. Frankly, most of the pickups, collectibles, and even enemies should probably be placed and tweaked by designers anyway, and having a team that's prepared for this can only make things work better.

But data-driven systems do not solve everything. In particular, I feel that scripting systems are a slippery slope that's best left to someone who can write proper code.

I have several reasons for saying this:
1) Writing a Scripting System is Hard. Essentially this entails writing either a compiler or an interpreter, and these are serious pieces of engineering, even for the limited functionality expected of a game scripting system. We should be endeavouring to remove Hard Problems of engineering from game development, not to add them.
2) The Scripting System Must be Supported. Inevitably the system will be flawed and buggy, and keeping it working smoothly must be absolute highest priority of some technical person on the team. This support task can get very large, especially if the underlying technology is unstable (as it so often is), or if the game spec frequently changes (as it almost always does).
3) There's (Usually) No Debugger. Programmers seem to forget just how useful a debugger is, even if it's just the ability to add printf statements to the code for output to a log or terminal. Especially considering that designers are usually not hard-wired left brain types, the lack of a debugger can be a major headache. Of course you could always write a debugger, but now you're right back at #1 again.
4) IMO, most designers do not have a logical sense of frame-to-frame gameplay. While they can intuitively say "I like it when I see it," they're less likely than a technical person to have the analytical brain-tools to figure out how to get from point a to point b.

As with any ruleset, there are exceptions. Some middleware packages may have exceptionally mature scripting capability complete with a debugger, and this is worth consideration (though the 'support' question becomes even more acute when considering middleware scripting systems). And some design teams may be blessed with a highly technical designer or two. But I consider both of these cases exceptional, and even in these cases I'm not convinced that the gain over just writing behaviors in C++ is meaningful.

So What does a Good Data-Driven System Look Like?
When designing data-driven systems, and I believe that you should, there are two considerations that should be considered paramount:

First, the value of the data-driven system is inversely proportional to the sophistication of object behavior. For simple pickups or moveable game objects, the value of solid data-driven systems is extremely high. For creating unique enemy behavior or complex puzzle states, the value drops precipitously. While a strong, well-staffed technical team may be able to implement these things as data-driven systems, the relative cost/benefit should be carefully considered.

Second, the greater a development is pushed toward data-driven, the more the toolset should focus on rapid iteration time. Ironically, when teams make tools more feature-rich, or when the game gets generally more data-driven, the build cycle times can get longer, not shorter, while simultaneously amplifying the detrimental effect of long cycle times. This double-whammy is the single most important thing to consider in data-driven tools development.

My rule of thumb on tools construction is that if the tools team has 100 RPG-style points to allocate to tools development, and the points must be distributed between tools usability and iteration time, they should allocate 30 points to usability, and 70 points to iteration time. Programmers can create all the slick GUI tools they want, and they are all a good idea...but even the most awkward and opaque tools can eventually be learned; the time wasted in iteration can never be recaptured.

This axiom becomes especially true near the end of development of a project, the point where the dreaded 'crunch time' comes into play. At the end of the project users are intimately familiar with the tools, and are no longer pushing them for new functionality; however (for good games anyway) the designers are deeply engaged in those final, fiddly tweaks trying to make the game perfect - tweaks for which a GUI is all but useless, but iteration time becomes the difference between seeing one's family or not.

Data driven game construction is definitely the future, and it's increasingly the present...but like anything, just saying "let's be data driven" without thinking carefully of its real value is asking for trouble.

And I don't know about you, but I like seeing my family.

After writing my earlier treatment on "The Myth of Agile Development", I had a discussion with a colleague, a gameplay programmer who is currently having his first experience with agile methodology. He can't fucking stand it.

But the reason he quoted was different from my more academic criticisms of what I described as the somewhat ironic rigidity of "agile" programming practice. My friend's criticism was instead focused on the 'agility' of the process. Because he is moved on a biweekly basis to a new part of the code, he is frustrated by his inability to "own" a part of the project.

"My job," he says, "is to take some part of the game, and work on it until it is fucking great. That's nearly impossible to do when I keep changing tasks." And he adds: "Making stuff that's fucking great is why I love this job. If I'm just here to make stuff that works to spec, I might as well be making some database somewhere."

Now, that's a different perspective.

Critics would say that this is a typical example of the allure of 'cowboy coding', the hero-based software methodology that dominated the first N years of game development. Probably this guy is just finding it a little difficult to "let go" of the habits of the past, where he got to be the star and he now has to build to the spec of the emerging star of the business, the Game Designer.

Fair enough, but there are two problems with this criticism:

1) This guy is actually very young, practically brand new to the business. Like most young participants, he's in games not because of the opportunity to become a great engineer, to create "a more perfect system"; rather, he's in games because he likes games...because he's been afforded an opportunity to make something fucking great. He feels that he's being robbed of this opportunity almost before it started.

2) As a game designer, I don't find the strict "vendor/customer" relationship of agile development to be particularly useful. This relationship presumes two things of me as the 'customer,':
   a) That I have some reasonably solid idea of the ideal solution to a problem.
   b) That my specification will represent something near the ideal solution.

Particularly in a pre-production setting, neither of these things is generally true. While it is the designer's responsibility to generate a proposed solution to a problem, it should never be assumed that this is the correct solution to any problem with a substantial interactive component. The correct solution can only be derived from iteration. (This goes back to my criticism of the long lead times caused by agile methodology.)

By the same token, the idea of building to a spec is absurd. A robust solution built to a specification which is actually a speculation is a pretty solid definition of a total waste of time. Instead, a hack-ass solution that proves the speculation to be correct (or, more likely, incorrect) is the genuine model of efficiency here. What's more, it's been my experience that the correct solution to an interactive design problem is frequently discovered not by the designer at all, but somewhere in the subconscious of the person who has been banging his head against it for several days - which is often as not a programmer.

That is, after all, how the creative process works.

Uh oh, I said it. Game programming is creative.

Or, put another way, let's not forget that Games Are Entertainment, Not Software.

I was talking to my friend Chris "Wombat" Crowell at E3 and this is the crux of his current rant (Wombat is never at a loss for a rant). He said it's driving him nuts when people forget that what they do has to be entertaining. "The audience can tell," Chris says. "If somebody is just phoning it in, the player can tell in a fraction of a second." While I certainly agree with Wombat, I disagree that there are a lot of game makers out there 'phoning it in.' There are definitely some of them out there...and you know who they are. Just look for the bottom quartile on metacritic.com and there's your roster. But I believe these groups are totally transparent.

What my other friend was complaining about, the one who hates agile development, is that agile development practices are encouraging him to take a phone-it-in attitude, by forcing him to switch constantly between tasks. While I don't think he would argue against the assertion that he has produced better, more usable code, and that his team has on paper been more productive, he feels that the fact that he's miserable much of the time will have a measurable deleterious impact on the quality of the play experience; that the player will sense he spends most of his time programming to a spec instead of programming something Fucking Great.

As a designer... I agree.

Now let me just clarify what I am not suggesting: I do not believe that everyone who touches the code in a game is thereby granted license to start fucking with the design. The design is the purview of the Designer. However the idea that the designer alone will perfect all aspects of the design is patently ludicrous. Rather, when a given element of the interactive design is being refined into the final product, certain skilled, passionate, and preferably experienced programmers can provide absolutely key insights and elements of artisanship.

And to reiterate, an absolutely brief primer on the creative process: creativity does not occur on a schedule; we all know that. However the idea of the 'moment of creative inspiration' is equally a myth. Rather, creativity occurs after hard work and concentration on the topic at hand. The fact that creative insight takes place outside of the conscious mind does not reduce the importance of taking time to focus on the question at hand. I like to think of it as an osmotic process: you have to apply adequate pressure to push the problem across the brain's consciousness membrane.

When a programmer is put in a position to "own" a part of the project, this 'creative osmotic pressure' occurs almost naturally. And the truly talented game programmer just might create something Fucking Great. However if a person bounces between tasks without focus, or more importantly if the task is moved between different people, it's unlikely to be pushed beyond the conscious level. In highly structured engineering problems, I don't imagine this is too great a problem, though the creation of agile process implies that the deeply rigid traditional "waterfall" processes are overly inhibitive to change.

So what's the best solution then? That looks like a topic for another blog post.

I finally reached a critical mass of reading about agile development and its attendant ideas of scrum, extreme programming, etc. and decided to do a little research to find out what the fuss is all about.

I find the core values of Agile Development very compelling. Documentation is shunned, formal code reviews de-emphasized, and most importantly, it's designed around the idea of a constantly changing requirement set. On paper, it sounds a hell of a lot like making games.

Before we get too excited about agile development however it's important to consider the background under which the 'agile manifesto' emerged. Programmers were reacting to ossified, top-down structures which dictated the function of large, immensely complex systems from the start, allowing for only limited and usually painful course corrections as the needs of the customer, or the actual performance of the system, did not match the original specification.

This has never been the case however in games.

The programming history of games has been just the opposite. The 'seat of the pants' has been the historical guidepost rather than a formalized management-driven plan. Programmers have historically made decisions on their own, and at an extremely high frequency.

In other words, the history of games has been what the software engineering cognoscenti would call "cowboy coding".

While I probably cannot condone 'cowboy coding' as an appropriate methodology for the large scale projects we're making these days, nonetheless I think it's important that if we want to consider agile development practices in games, we'd be well-advised to consider the context for the development of agile methods, as contrasted with the historical context of game coding, and consider where agile methods might actually harm the game development process.

As an example, when I read the agile development description on wikipedia, it mentions that usable code can be released usually as frequently as monthly, and sometimes as often as every two weeks (!). Two weeks? Are you kidding me? If a game project, especially early on, adds functionality only every two weeks, it's doomed before it even starts.

Now I suspect every game programmer understands this intuitively, and would also tag this as a point of divergence between agile development for large commercial apps vs. games, but the point remains, just how much is 'agile development' applicable when its net effect would in fact be to make the programmer less agile and responsive to the customer (the game designer)?

Let me answer my own question a couple of ways.

First, for better or for worse, the days of true cowboy coding probably really are over. Teams are too large, and the general move toward data-driven development means that the level of criticality for a given feature has gone way up. So some sort of engineering practice is called for, and I'd heartily agree that top-down management-driven development is not going to provide the answer. Agile development, with its emphasis on communication and small-scale, quality-driven work chunks smells to me like a step in the right direction, not the wrong direction.

Second, and perhaps more saliently, if I believe, and I do, that strict adherence to agile dev practices particularly during pre-production is destructive to the overall progression of a game, that does not mean necessarily tossing out the baby with the bathwater in terms of trying to create a more sane engineering environment. Instead, and this is something that I'm going to explore more thoroughly as time goes on, I believe that agile methodologies will prove particularly useful during the very earliest phases of a game's lifespan, a phase that precedes even pre-production which I'll call "concept development". While this phase does not really exist right now in the development of most games, I will argue that it should, and that this is a perfect time to develop a game's core technology using the two- to four-week iteration cycles typical of agile development.

Programmers love to talk about how they work, so somebody must already have written on this topic of applying agile development to games. Maybe "hyper-agile development"? I'm all ears.