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.

A few weeks ago I had the opportunity to speak to a class of third graders about game design. I've been invited to do these sort of talks a few times over the years; teachers assume, correctly, that kids will actually pay attention to a professional game designer in a situation where perhaps a local doctor or lawyer might get tuned out. My message is pretty simple - stay in school, study hard in your math and/or art classes, things like that.

It had been a while though, and I've learned a lot over the past few years about what it really means to be a game designer. So I decided before I went in front of the class, it was time to polish my speech a little. And I hope you'll forgive a self-indulgent attitude for a bit as I explain some of these lessons about being a game designer.

Both of my parents were educators (both recently retired), and like Raph Koster describes in his great book A Theory of Fun, I grew up in an environment where this was highly valued. I got a good college education (major: English) and proceeded, much to the consternation of my family, to do very little that could be perceived as 'useful'. And somewhere along the way, I ended up a game designer.

When I first entered the games industry, the idea of being a "game designer" as a full time job was not very common. Most people who called themselves game designers were really programmers, moonlighting as game designers because well, somebody had to do it. Since I had no tangible skills, but seemed to be useful nonetheless, I generally called myself "producer". In fact this was the title on my business card when I worked on my first real game, Insomniac's Disruptor, as what would today be called a level designer.

It must be said also that I never envisioned myself as a game designer either. I loved videogames as a kid, and grew up on the classics both of the home and especially the arcade. (Around the seventh grade I decided I would be what I would later learn is called a 'QA Analyst'.) But as I got older, I always figured that I'd do something more serious with my life. Like, maybe be a teacher, right Mom and Dad? Right Raph?

But somewhere along the way, I've ended up a game designer. And if you're reading this, I don't have to tell you, that's pretty cool. Coming to see just how cool this is, and how frequently meaningful it can be, has been a long process for someone who entered the industry in the early 1990s. It's kind of like when I moved to Los Angeles - I always figured I'd leave eventually...and yet here I still am. And I have a great career. Coming to understand this, has made all the difference.

I suppose I should get back to those third graders. I figured, any jackass can tell these kids to stay in school and do their math homework. Sure maybe I had a little extra street cred with the kids, but it actually felt a little dishonest not to tell them at least a little about how to be a game designer. I mean, isn't that why I'm there?

I thought about this a lot the morning of the talk while in the shower (like lots of people, this is where all the good ideas happen). I thought, I'll talk to them about what really matters if these kids want to become *great* game designers. And I figured, I'll cap it off with a secret weapon - I'll show them that they are already game designers. I had my speech.

The early part of the speech went as expected. The kids' teacher had wisely had them prepare the day before by writing down questions in their journals, so I got some good ones, like:
- "How many people does it take to make a game?"
- "What's your favorite game?"
- "How long does it take to make a game?"
- "What's your favorite color?"

OK, so they're third graders...

As the talk was winding down, I told the kids that if they wanted to be game designers they should play games, that games are fantastic...but that if they wanted to be great game designers, that wasn't enough. I told them the story about Mr. Miyamoto, who remembered the fields and caves of his youth when designing the Mario and Zelda games. I told them that the best ideas I've had have all come from movies, from books, or just from playing around outside (all true, BTW). I had these kids. Now time for the finishing blow.

"How many of you have designed a game?"

I figured, you ask this to a group of high school kids, not a single hand will go up. Why should third graders be any different?

My bad.

Easily half of the hands in the class went up. Kids described playground games they had made up or adapted from traditional games...one kid had made a sort of primitive board game with her sister. One kid went off on an elaborate tangent describing what amounted to a space RPG, all of which took place on his backyard play structure. Eventually it disintegrated into a contest to describe who had invented the best way to torture a pet with a squirt gun, so I cut it off (they were third graders after all...). But the damage was done. I was stunned. These kids invented games as a matter of course; creativity came to them as naturally as getting up in the morning.

Though I was off-balance throughout this time, I realize now that I achieved exactly what I had hoped to. As the kids were leaving the class, and were supposed to head off to their phys ed activity, they were collaring me at the door, describing even more games they had invented. The spark was there...they were making the connection between their own innate and natural creativity and what the "hero" does. They no longer were interested in what I had to say, so much as to have me help them understand what they themselves had been doing.

There are many lessons in this. Not least is, as game designers, or indeed as people doing anything creative, it frequently behooves us to think like third graders. Third graders do not pre-judge their own ideas; they begin playing and keep playing and modifying the rules until the game gets fun. How many variants on 'tag' did you play as a child? How many variants of a simple race? See what I mean?

Another lesson, and maybe this is just for old, insecure fools like me, is that making games is not just good because it encourages rigorous study of 'real' academic subjects. Making games is inherently a Good Thing. Games are part of how we integrate and come to understand the complex, formative experiences of our youths. And gee, how much of psychology, of literature, is about this?

It also begs a question for me, a question that's been bouncing through my mind a great deal over the past year, which is whether the center of games is indeed play, if it is "simply, fun" as Iwata-san of Nintendo says...or is the experience of a game as an adult fundamentally different from that of a third grader? Much as campfire stories evolve into great tales, do (or should) games become something where adults can explore the larger issues of self and society? I don't know.

But the final lesson, the one that I'll take to the bank, is that the one thing that game design gives me maybe more than anything else is the skill of a teacher: empathy, the ability to see from an outsider's perspective, and the ability to stick with a pedantic goal and roll with the punches. And not least, the ability to inspire. Raph Koster was right. See Mom, See Dad? I became a teacher after all.

About a year ago, faced with a huge excess of driving, I traded in my Audi S4 on a Toyota Prius.

I was pretty bummed about this. The S4 was a very fast car; being able to touch 100MPH in one's daily commute is just plain fun. But it ate a lot of gas, and the green in me could no longer brook the amount of hydrocarbons that came out of the tailpipe. So I got on the waitlist, and picked up a Prius.

Now that I'm in the club of Prius drivers, I know that there is a secret handshake, which is to discuss what mode you like to use the touchscreen display in (or, whether you've rear-ended anyone yet because you were watching the display). This display is a central part of the Prius experience.

For the uninitiated, I'll describe what this is all about. The Prius is a "full hybrid", which means that it can run completely off the gas motor, completely off the electric motor, or any combination of the two. This balance is controlled by a computer running a sophisticated set of algorithms that take into account the current battery charge, the electrical load (from the air conditioner, for instance), current speed, position of the pedals, etc. When Toyota built the Prius, they decided to expose this computer process to the user, using a video display in the center of the dashboard. Along with showing the process, the display shows the current charge of the batteries, and constant real-time updates of fuel economy.

I'd be curious to know why Toyota decided to do this. It's arguably fairly dangerous; I know of at least one person who has had a collision at least in part because of this display. My best guess is that they did it because of the "because we can" factor, and also because they knew it would help push the nerd appeal for the early-adopter set (guilty as charged).

What we have though, is in essence a game. Or what we would call in the current parlance a "serious game".

I've actually been driving cars that had a fuel economy readout for years, starting with a Volkswagen Passat I bought in 1997. But that simple numerical display while amusing for a while didn't have anywhere near the appeal of The Prius Game. The Prius Game is waaay more fun.

First, Prius has a built-in advantage, which is the 'fuzzy' break between the gas and electric modes of transit, and the all-important feature called regenerative braking (how the battery is recharged when you decelerate). A straight gas or electric car would have only part of this functionality.

Second though, Prius has an excellent interface. When you first start driving a Prius, you'll probably find yourself staring at this display a lot:


With its colorful animating arrows and rotating wheels, this display is eye-catching, and also reveals the moment-to-moment decisions the computer is making regarding where to budget the various energy flowing around underneath the hood.

I call this "training mode".

After a few months though, you'll start to learn the computer's tricks, and begin the process of optimization. For optimization, you switch over to this screen:


This mode, which shows history as well as current status, I call "advanced mode."

Now I'd say this driver has a nice high score going. The fact that there's a limited number of little leaf cars present proves that this is not a simple downhill glide. And 88 degrees is pretty hot, meaning that most likely the AC was robbing a few horsepower off the top as well. We're looking at a driver with some skills here folks.

In fact, a quick google search comes up with some great quotes:

"I just ordered a fuel-economy computer that I can plug into my car's ECU. Soon I too will be able to turn driving into a real-life video game." (www.metrompg.com)

"The digital fuel consumption gauge is so prominent, you can't help but try to beat your previous trip's fuel consumption average. Somehow, we don't think Toyota did that by accident." (www.drive.com.au)

"Perhaps even better would be the ability to pull up the "high scores" right on the Prius' in-car display. Perhaps this would be the first actual reality-based driving game." (www.gearbits.com)

There can be little doubt: with its combination of robust gameplay and excellent interface, the Toyota Prius is one of the best designed games on the road today!


This is really important
So, why is this important?

It hit home for me the other day when I had the misfortune of having to drive my family's other car (a very nice Audi A6 wagon) on my normal commute. In my usual "coast spots", I started to decelerate, and realized that I wasn't going to have any chance at all at a high score. And with the Audi's poor gameplay and interface, I couldn't really be bothered to try even for a local high score. So I just said screw it, and drove home with no particular regard for economy.

As soon as I got back in the Prius, I was back on my game though, looking to bust my average above 47.5 (my current norm for an whole tank). And here's the crux of it. Games, with their powerful motivator of FUN, can directly influence behavior. As soon as the Prius made getting fuel economy FUN, I was all over it, and so are the majority of my fellow Prius jockeys.

Most of what I read about "serious games" is games whose ultimate goal is to educate, or provide insight. While this is laudable and probably effective, it's also perfectly achievable through other, non-interactive means. Games however, if designed correctly, can actually directly impact behavior in a manner that we can call a social good. Prius's "game", which has a powerful impact on user behavior in a positive direction (less fuel consumption, less pollution), skips right over the education element, straight to the social good. (This by the way is a lot of why I found Harvey Smith's "Peace Bomb" idea so appealing...it drew people directly to action rather than just trying to be pedantic.)

And I haven't even mentioned the fact that with this nifty entertainment literally right at my fingertips, the stress of commuting has dropped dramatically.

As computers and interactive interfaces are woven deeper and deeper into our surroundings, I think it behooves us to look at these devices frequently in terms of games. Can that electronically managed refrigerator use fun to motivate the diabetic toward a better diet? Can a house's electrical system use fun to encourage its residents to maximize efficiency? Can the phone give you skill points for calling mom a little more often? Sure some of these things are goofy, but I think it all bears consideration. And let's not forget the potential of linking online for an additional motivator, competition.

So yeah, my nomination for Serious Game of the Year: Prius.

In thinking more over the weekend, I feel compelled to comment a bit further on my rather harsh indictment of the PS3. None of this softens my views, but might provide a bit more justification.

To my mind, there are two absolutely crucial blunders in the PS3 which have led them to bring to market utterly the wrong box. The first, over-speccing of the hardware, is shared somewhat with the Xbox360; the second, inclusion of blu-ray movie playback, is Sony's burden alone.

Over-Specced Hardware
Somewhere at the crossroads, Sony forgot what a game console is. Historically, a game console has been the best hardware that could be made to meet a certain price point. Consoles have been riddled with compromises, particularly in whatever happened to be the most expensive components of the day (usually memory), in order to hit a crucial price point that makes the console an easy holiday purchase for a family.

This is really a story about consoles versus personal computers.

Now computers being what they are, consoles also historically had certain advantages. Mostly, because they are such specific-use devices, they were frequently able to do things, particularly graphically, that general purpose PCs were unable to do, sometimes at any price. This was particularly true during the 2D era.

Even as PCs reached the raw compute capability to emulate the custom hardware in the consoles, the price differential between the console and the PC made the prospect of purchasing the latest Sonic game on PC seem ludicrous.

At this point however, PCs are so powerful, and so filled with custom hardware themselves as concerns graphics, that consoles must really stretch in order to maintain this historical window of dominance.

But you see, that's where Sony (and their lapdog Microsoft, too) get it all wrong with the current generation. As they continue to try desperately to stay out front of the PC, the consoles get bigger, noisier, heavier, kludgier, and most importantly, they get expensive.

In other words, the console manufacturers are making these boxes completely backwards: they forgot to build the best box for the dollar target. Ironically, Microsoft may be in the better position purely by way of having come out earlier. Their box is made of older, cheaper components and thus is really more akin to what the consumer really needs or is willing to pay for. And not meaning to quote Jason Rubin too many times, but the consumer really doesn't care about the supposedly-huge benefits of the "HD era".

And here's the real irony, and tragedy - none of this makes the even-more-expensive PC any more attractive as a game system. What we're really risking is a contraction in the overall market, and that's a shame.


That Stupid Blu-Ray Drive
Perhaps Sony Computer Entertainment was forced into this folly by its corporate parent, but that makes it no more forgivable. But blu-ray, and HD-DVD for that matter...those formats are straight up DOA. For me this is really similar to the problem the music industry manufactured when it tried to recreate the economic magic trick it pulled with the Compact Disc. The CD was so superior in so many ways to the analog media it replaced, it was a rare opportunity for the medium to actually be the message in music. Same thing with DVD over that clunky piece of crap called VHS. The first time I saw a live demo of DVD, I said to myself "I gotta get me some of that DVD!". It was compact, re-usable, had groovy menus and extras, and the picture quality was a quantum step above VHS.

I suspect that in time, a physical video format will supersede DVD. But it will happen slowly and may take years. Maybe not quite as slowly as the (probably never) adoption of SACD/DVD-audio, but it's sure not a must-have for your average movie fan. No, on both the video and audio fronts, iTunes represents the future. iTunes, for all its popularity, represents a step down in aural quality from CD, but it's still plenty good enough, and the convenience just can't be beat. Same thing for movies. I've got no interest at all in HD-DVD, but I do love those video podcasts.

So here's Sony, crippling their Playstation future with an optical drive that nobody wants.

This is just as dumb as it gets, in my opinion. Remember the PS2's limited memory? Well that's because memory was the most expensive component in the box, and Sony was smart enough to know they had to keep the overall cost down. Now we have the manufacturer pulling out all the stops on the most expensive component in the box, the optical drive. This would be dumb enough if it wasn't also a component that has no meaningful use. That's a serious double-whammy.

Microsoft gets a passing grade here. Somebody realized that the HD-DVD idea was a loser, and made it an optional add-on. Watch how many they sell. It won't be many. (I can't excuse MS though for the exclusion of a cheap part like the hard drive. That's just stupid IMO.)

Sorry Sony, but the more I think about it, the more I can't stand the PS3.

A few weeks removed from E3, what still sticks in my mind is a single number, and that number is six hundred.

Specifically, six hundred dollars - the price of the Playstation 3. Don't even start with me about the "cheaper" PS3 SKU. Just like with the bogus Xbox 360 'core' system, this is a cynical, terminally crippled offering whose only real use is as a PR tool. The PS3 launches at six hundred bucks. Take it or leave it.

Here's my gut reaction as a consumer to the $600 PS3: How come when every other tech thing I buy is getting cheaper and doing more and more, game consoles are getting incredibly more expensive to do basically the same thing? Fuck that.

I have to think, this has to be the reaction of the mainstream consumer base to the $600 PS3: Fuck That.

Not to sell Sony too far short, they seem to have sensed this. So we have Kutaragi-san now giving interviews trying to convince consumers that they should be comparing the PS3 not to their existing game console, but to their PC. Yeah, right Ken. After successfully selling tens of millions of Playstations and PS2s to consumers for the exact reason that the last thing they wanted to do for entertainment was to put another PC in their homes, you're trying to convince them that you were actually wrong all along.

Nintendo, meanwhile, is smelling blood in the water. Iwata-san said recently that the Wii "is not a next generation console." What sounds initially like some kind of admission of defeat is in fact a stroke of genius - Nintendo understands that in terms of raw technology, the consumer is basically done. The "HD Era" as Microsoft likes to call it is pretty much a crock of shit, and graphics look pretty damn good already. If God of War can look as good as it does and run at 60fps, we're pretty much done, and for those paying attention, Jason Rubin told us as much almost five years ago at GDC. But Nintendo is offering something new where it actually has resonance: in the input device. The Wii's gestural controller may succeed or it may fail, but either way, that's something I'm actually willing to spend money to find out...especially if as Iwata-san suggests, I will only have to pay a current-gen price for the opportunity.

But $600 for the same old shit with more polygons and pixels? Fuck that.

I'm trying to think of the right historical analogy for how I feel about PS3, and though it's highly imperfect, the best I can come up with is the Sega Saturn. I remember the first E3, when Sega announced the machine, showed amazing games like Virtua Fighter 2 and Sega Rally and dropped the bomb that it was "available in stores today!" After the incredible success of the Genesis/Megadrive, It seemed like all Sega had to do really was show up for the next generation. And here they had seemingly dealt the death blow by beating Sony and Nintendo to market.

But none of that mattered. Sega's Saturn was an overpriced and underwhelming hardware, difficult to program for and with bits of it (the second CPU) kludged in when initial performance failed to live up to expectations. Developers struggled with it, consumers lost faith, and though the Saturn didn't knock Sega out of the hardware business, it knocked them out of the business cycle, and despite the fact that the Dreamcast actually addressed a great many of the Saturn's technical shortcomings, it was too little, too late.

Obviously the parallel doesn't really work at the detail level; Sony did not try to 'time the market' with the PS3, and the hardware does look at least equivalent to its competition. But the disconnect with the consumer looks very real to me. And though I have no doubt whatever that there will be a PS4 at some point, I wonder what kind of market share it will be attempting to inherit.

As anyone can tell you, my bona fides as a Microsoft hater are about as strong as anybody's. This blog after all is composed on my Mac - the tenth Macintosh I have owned. And though I admire the hell out of Nintendo's games, I have never been accused of being a fanboy. All the while, my relationship with Sony has been responsible for the entirety of my good fortunes in this business. So watching Sony stumble is not something I relish. I greet this feeling with a combination of sadness and disappointment, and having to re-assess what has been a wonderfully successful partnership.

But...six hundred bucks?

Fuck that.

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.

A few weeks ago, I got the strangest phone call from my father.

"Do you know what kind of charger this damn Nintendo DS thing takes?"

This was strange for a number of reasons:

1. I had no idea my father knew what a Nintendo DS is.
2. My parents were traveling, on the road between Colorado and their home in Oregon.
3. My parents had none of their many grandchildren with them.

My parents, it turns out, are desperately hooked on Brain Age.

Over the Easter holiday, I had taken my DS and my copy of Brain Age with me when I visited my family in Oregon. I thought they might find it amusing, and indeed they did. So amusing in fact, that without my knowledge they went out and picked up an electric blue DS (they're still yet to boot the Animal Crossing pack-in), and a copy of the software.

Now they are so hooked, that when they found themselves on this trip without the charger, and the DS was going dead, they were in a near panic. I had to break the news to my dad that the DS takes a very proprietary adapter, that none of their cel phone or laptop chargers were of any use, and they'd just have to drive fast to get home and get their fix.

Last week I was in Oregon again, and got to see their game saves. Outside of the couple days in transit with no charger, they've got almost perfect red splotches all over their calendars. My dad can name exactly what happened on the days he's missed. They talk all the time about the differences between their performances (my dad does great at arithmetic, but my mom is the queen of low-to-high). They've opened up pretty much all the minigames that Brain Age has to offer.

They don't do the actual age tests very often. They find them annoyingly competitive and distracting from their "training".

I think it says a lot that my father has stopped doing Sudoku, and my mother has stopped crosswords. They've replaced these pastimes with Brain Age.

Here's a kicker - my 9 year-old niece is now into Brain Age too. She does terribly at it, but sticks with it, especially the puzzle type minigames. They're trying to get her into the arithmetic because she's behind in arithmetic in school. It just might work.

Mr. Iwata, my hat is off to you.

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.