As many designers are wont to do, I've been goofing around with game ideas in my head lately. No doubt being in a period of console platform transition tends to spur this kind of thought, and no console is more inspiring during this particular transition than Nintendo's "Wii".

What the Wii brings to the table is an idea - gestural control input - which is very simple and not at all new. However the fact that it is enabled by default on a device which will be sold by the millions, now that is new, and that gets a person thinking.

What is Gestural Control?
It's hardly coincidence that one of the first demonstrations Nintendo chose to introduce the Wii to the public was a simulation of conducting an orchestra. Orchestral conducting is a completely gestural system. When I was in college I studied music and, among other things, learned the gestures for conducting. Despite how it looks, the conductor actually uses some very specific, pre-defined gestures. So for instance in 4/4 time (by far the most common time signature in music), the gestures are, in sequence: down, left, right, up. For a three-beat time signature (such as 3/4), the gestures are down, right, up.

What makes orchestra conducting interesting is that within these prescribed set of gestures is infinite variability. Western classical music, though written with a "time signature", is rarely designed to be played with a steady "beat" or "groove" (that was an addition of African influence, but that's a whole other story). Rather, the orchestra follows the conductor's interpretation of each division of time, speeding and slowing to match the "feeling" or "meaning" of the piece. To do this, the conductor utilizes analog control. In fact, when you learn conducting, you're taught not to draw straight lines, but rather to make an asymmetrical, curved diamond with the four (or three) beats. All of this is to make the gesture more dramatic and varied, and to provide the infinite variability the conductor needs within each beat.

So, using gestural control is about variability and expressiveness. And once you use it, it's very easy. Conducting is not difficult.

Gestural Control and Computers
Interestingly, computers have had excellent gestural control input devices for more than twenty years, yet have very rarely used them as such. The mouse, with its combination of analog and precision, is a nearly perfect gestural input device. Yet we use it mostly just for "pointing and clicking". When I installed the Firefox plugin "mouse gestures" (highly recommended!), it took some getting used to, but opened up a whole new world: I no longer needed to either point or click in order to do common tasks like closing windows, going forward or backward in a browse sequence, etc. This freeing from the spatiality of the GUI of Firefox is really eye-opening.

A different type of gestural control was popularized by the movie Minority Report, in which the lead character, needing to browse large volumes of information quickly, dons some weird gloves (it's a sci-fi movie - there have to be weird gloves), and moves stuff around a large virtual screen. In fact this kind of interface has been demonstrated (without the goofy gloves) in several different touchscreen-driven forms here in the real world. It looks really cool. One has to imagine that in the future, driven by technologies such as those behind the Tablet PC, nearly all computers will incorporate some sort of touchscreen-driven gestural input systems.

The Limits of Gestures
This is a good time to discuss the limits of gestural controls. If you watch some of the demonstrations of the existing touchscreen systems, they're wonderful for organizing a desktop, for viewing photos and the like. But when it's time to enter data, they always pop up a "virtual" QWERTY keyboard. When I saw this, it reminded me of some other computers that relied on gestural input: the Newton and Palm Pilot.

Apple made the Newton back in the early '90s, and it was revolutionary, a handheld computerized organizer designed to be used by anybody. And a big part of the "fun and easy to use" ethos of the Newton was handwriting recognition. Because of its special software, you could just write on the Newton, and it would accept this input. The problem was, the handwriting recognition software sucked. Turns out, handwriting recognition is one of the Hard Problems of computer science. And the little battery-powered handheld wasn't even remotely up to it. Cataloging "Newton Translations", unintentional jokes created by Newton handwriting recognition errors, was one of the earlier hobbies of the World Wide Web.

Poor Newton. Great idea, bad software.

Right?

Well that's what the guys at PalmPilot thought. They realized that the Newton had just been too ambitious, attempting to recognize "natural" handwriting. If the user could be trained to use a simplified type of handwriting, still gestural but not idiosyncratic, the device could easily recognize the gestures as text.

They were right. And the Palm Pilot made a very crucial good design decision, which was to require letters to be entered in sequence in the same space - this enforced that the user would use independent gestures for each letter, with a start and end. I had a couple different Palm Pilots, and they really did work.

But they were a pain in the ass. Was an "I" a stroke up, or a stroke down? Which stroke first for a "T"? How do I enter capital letters? You eventually learned it, but it took time. Then Palm created a "better" input system, which changed about 20% of the gestures. I had to learn the whole damn thing over again.

The problem was, they were missing the point. Entering text is a shitty use of gestural input. Look at the devices that replaced the Palm - the Blackberry, the Sidekick, even Palm's own Treo - pretty much all of them use keyboards for input. As great as gestural input is for analog or expressive actions, it's just crap for anything that requires speed and/or accuracy. Such as, for instance, entering data.

Gestural Input and Games
Oh yes, games. Gestural input is far from new in games - we've been playing with this for ages. Ironically, Sony was the first to bring real gestural input to consoles with EyeToy, which they first demonstrated at Siggraph in 1998. The EyeToy story is a classic example of why the games business should never be driven by technology. EyeToy was a technology R&D project to test the capabilities of software to recognize and use video input. It was a dramatic success. But what came of it (the brilliantly fun EyeToy: Play) was not great because of its video recognition. It was great because it was an example of gestural input. If you had seen my daughter, only two at the time, play the 'Soapy Window' game endlessly, you'd have clearly seen the potential of gestural input. Or at least, you should have.

EyeToy however is limited by its technology: video input is fussy, and imprecise. So Sony has relegated it to a niche device - a classic case of viewing a product as technology instead of entertainment. Had Sony viewed the success of EyeToy: Play on its merits as an interactive system, rather than a technology demonstration, I have a suspicion that Nintendo would not be the sole console manufacturer offering gestural input this fall.

Gestural input hit the bigtime though with the Nintendo DS. When the DS was launched, it seemed like its key feature was the dual screens (hell, the thing was even called "DS"). Wrong. Two screens actually pretty much sucks. But one of those screens has a touchscreen input, and a stylus is stuck in the back of the device. Aha. With stylus in hand, great new products like Brain Age, the fascinating Electroplankton, and the before-its-time Kirby's Canvas Curse suddenly become possible. And there are many more to come.

Meanwhile Okami has convinced me that gestural control on a traditional analog controller is mostly a lost cause. And though I admire Sony for putting the six-axis momentum sensor in the PS3 controller, it's really just a giant and wonky third analog stick. Its lack of spatiality makes it useless as a gestural device.

That Wii Thing
Honestly, I'm concerned about the Wii's controller as a gestural system. The video I've seen shows the input to be pretty jumpy and imprecise. I really don't think you could do Brain Age on the Wii-mote. It will be wonderful for many things. For others, it will be highly imperfect. Remember: great for expressive and analog; poor for quick and precise. Nintendo were wise to include the "nun-chuck" traditional controller adapter in the box.

Still, it does get the mind turning. I remember how fun EyeToy: Play was, and though it was too primitive to maintain interest, there was something there. And as I turn over these little game ideas in my head, the quick, accurate gestures possible on the DS are really attractive (indeed for me, the DS remains the more attractive of the two, at least for now). I'm not going to tell you my ideas just now, but suffice to say, the potential in gestural control for games is fantastic.

Most games have stories. There are very good reasons for this, involving how we as a species like to learn and remember things, and how we generally rationalize and understand the world around us. But the bottom line is that games do have stories.

Despite this, alarmingly few games have proper writers.

I think this trend is changing. I see more and more game writers getting work, and the better (or better-known) of them are finding themselves in great demand. This is a Good Thing. But progress is slow, and we should change that. I've been both part of the problem and part of the solution in this regard over the past few months, so I have some perspective on this issue.

The Hypocrisy of the Game Designer
Most game stories that are not written by proper writers are written by game designers. This makes sense of course...the designer is the one who probably devised the game's setting and action in the first place, and good designers (especially lead designers) tend to have very strong verbal skills. It only makes sense that the designer should write the story.

This is of course total crap. And the irony is, designers of all people ought to know better.

It wasn't that long ago that a person carrying the sole title of "designer" was a relative rarity in the game world. If you were going to do design you were expected to bring something else to the table, like the ability to write code or do art. In fact most designers were converted artists or programmers until quite recently. If you didn't have these skills, well then you'd better be good at production, organizing schedules, localization and such. In short, pure 'designers' have had to struggle for acceptance within teams.

What's more, every designer has had the experience, usually a multitude of times, when "everybody's a designer". Or "how hard can it be?" Often, trying to explain the reason for a design idea is frustratingly difficult and time-consuming.

And yet here we are, designers trying to write stories. Tsk tsk tsk.

A Story is More Than Words
The first step that we seem to have taken in the right direction is to stop writing actual dialogue. Those of us that have written dialogue, then heard it read by perfectly good actors and sound like total ass, have been humbled by this experience. So I think it's relatively easy for us to decide early on that a "real writer" will be brought in to write the actual dialogue.

But the thing is, a story is much more than just the dialogue. It's like looking at a game as just its moment-to-moment level design rather than its overall structure. Creating a story that actually resonates, that gives the viewer what they want emotionally and logically, requires great and long effort, and more importantly requires a very specific skillset that isn't obtainable just by reading a couple of books. It takes understanding, study and most importantly, practice.

I was making this exact mistake on my current project, feeling that, along with a couple other game developers at the studio, we could get the story all worked out along with the game's macro design, then bring in the writer to make it all sound nice. Then I saw Flint Dille, an accomplished game writer, talk at the Games and Hollywood Summit back in June. He had this great quote, which was "I am so sick and tired of hearing 'Man, I sure wish you were here last December!'" What he meant was, he's frequently brought in just to write the dialogue, but finds a story that's structurally a train wreck. And usually the game is so far along that it's too late to do anything more than a patch job on the story itself.

I felt immediately like an ass. We were struggling with what parts of the story to keep, what to discard, how to pace and structure it. I could just see myself saying "Man, I wish we'd brought in the writer a few months ago." The 'real' writer was brought into the project right away, and the project suddenly took great leaps forward. Hunh, go figure.

Writing is a Skill
What I've learned is, while I and many other designers/artists/etc in the games creating business may very well have the talent to create a great story, we don't have the skill. I think most people have at least some understanding of the difference between ability and skill, but for purposes of this discussion, I'll make a very simple definition:

Skill is ability gained through understanding and practice.

When looked at in this light, I think the typical designer fails in both areas. While I have a bit of an advantage in the first area, having supposedly studied literature (some 20 years ago now, I might add), I don't think that my understanding ever got past the typical academic areas of theme, image and metaphor. I didn't learn much about structure, character, technique... those practical things that make a writer a good, skilled writer. And, just like with game design or art or programming, good writing absolutely requires practice, a dedication specifically to the art of story, words and dialogue.

I'm sure there are a few designers out there, with not only broad skillsets but also tremendous time and dedication, who can study and practice writing enough to perform the writer's role... but why? Most of the time, in my observation, developers who try to wear too many hats end up frustrated, compromised, and holding up the overall progress of a game's development. Though good game writers might be a little hard to locate right now, I know there are a fair number of very good ones available, and that's only going to improve as time goes by.

Because, think about it... we need game writers.

As many of my colleagues are pleased to point out, I'm approaching 40 years old, meaning I can trace my roots somewhere between the jurassic and triassic in terms of games development. While this is all very amusing, it also means that I find myself in a constant internal debate over whether some of my methods are the result of long experience, or just the luddite tendencies of age.

The use of computers in level design is just such a case.

I insist that designers I work with begin every level design on paper. All the basic thoughts behind the gameplay of the level should be expressed in a paper design before it is ever realized on the computer. While I've met resistance to this idea from time to time, usually designers do just fine on paper...though I do have to bust them from time to time for using the computer inappropriately.

This paper bias is emphatically *not* due to some great drawing skills on my part. I can't draw worth a shit. But I do find that paper (graph paper and a ruler, mind you) is far and away the most liberated way to create the shapes, angles and spatial divisions required for a level design.

You see the trouble is, with a computer, there will always be an easier way to do soemthing, and a harder way to do something. And a designer through no particular fault of his or her own will inevitably end toward the easier. In particular, the computer design tools will tend toward geometric shapes rather than organic shapes. It takes a highly skilled user of the tool to create shapes that don't end up looking like collections of primitives rather than actual places. This is particularly true at the junctions of spaces, which tend not to 'flow' for designers that over-use tools.

At which point I ask, what is the point of using the CAD tool at all? No doubt you've heard the complaint that "all Unreal Engine games look alike". My response is "duh", because I've seen how the UnrealEd tool works. Don't blame the engine folks. Blame the tool. Or rather, blame the designer who uses the tool.

Designing within the game implementation tool is a great example of designing backwards, and brings me to my second reason for insisting on paper rough designs. Computer-aided tools are fantastic for detail. This is why by no means do I denigrate the importance of actual game implementation software, where fine detail and iteration can take a given level from good to great. This emphasis on detail however does not help the initial design process at all.

Initial design, the creative part, should be done in a fractal manner, beginning at the lowest level of detail and working up to the higher detail levels. Indeed the first couple of drafts should probably not even be to scale, as the designer works out the flow and general shape and structure of the space. Next would come relative sizes of the spaces, while preserving the flow, and finally the details of the gameplay and visibility. This top-down approach would be terribly difficult to do even in a flexible 2D CAD program like Adobe Illustrator.

CAD tools by their nature lead toward linear, point-to-point thinking, rather than fractal, outside-in thinking. It's not dissimilar actually from the difference between object-oriented and procedural programming.

Bearing all this in mind it's not difficult to see how designing your game inside your construction tool will lead to designing backwards. Pretty soon you're focused on the details, to the exclusion of the big picture, and the results are predictable, with decent moment-to-moment gameplay but a noticable lack of cohesion and coherence as the player plays for more than five or ten minutes.

Maybe I'm just old, but I don't think so. Get yourself a pad of Staedtler engineer's computation graph paper and see if I'm not right.

Today I was working with my design partner-in-crime GMoney, and the phrase "sun seeds" came tripping out of my mouth. I knew it was familiar when I said it, but he immediately busted me.

"Talk about repeating yourself MJ," he said. "Spyro 3 baby."

I was thinking he was probably right, but I couldn't exactly remember. G and I didn't work together back then (we didn't even know each other) so he could have been wrong. So I went to the ever reliable GameFAQs.com to check. Sure enough, there was Sun Seeds, a puzzle from one of the early levels. If memory serves, I think that Brian Allgeier did that one, but memory has a habit of not serving terribly well these days so I can't really say. Regardless, Gmoney had me cold.

Since I had the file open I decided to glance through the FAQ. I hadn't thought about that game in so long, it was a fun trip through the way-back machine. Then I started to get perturbed. There was so much stuff in Spyro 3. And really, though Spyro was a little exceptional, there was a hell of a lot of stuff in a lot of games of that era. I looked through the FAQ and here are some stats for you:

- Five fully playable characters, all with different play mechanics, including one that flies using a helicopter mechanic
- 26 levels, each with its own art design, and built polygon by polygon (no instancing back then)
- 18 main levels, each containing one mini-game.
- 6 mini bosses
- 4 full bosses
- 4 "speed" levels using a fully-3D flying mechanic
- 1 extra level filled with mini-games, accessible only after completing the game 100%
- A skateboarding mini-game sufficiently complex that someone wrote a wholly separate FAQ for it.
- A couple dozen NPCs, all unique models with unique names and personalities; many of them were active participants in the gameplay.
- Secrets, including the now-famous Insomniac 'skill points'.

And this is a game that was done by less than 20 people, in well under a year.

Now imagine pitching this schedule to a publisher today - even as a sequel. You'd be flat laughed out of the room.

Most of the comparison is unfair. The polygon count on the environments is trivially small by comparison to modern games, and on PS1 you got one texture layer - if you were lucky. We didn't have advanced animation blending, because we had neither the processing power nor the animations.

And yet, we were somehow able to produce a great deal more interactive content, in a great deal less time and with a fraction of the staff. Has something gone awry? Or is this the typical "aging game designer comment"? I don't have a good answer for that.

I do know that the kids who played Spyro back in the day were fully engrossed in the world. They believed in the "Dragon Kingdom" (later named 'Avalar') and the crazy characters in it. But maybe with what they see on TV and in other games, that just wouldn't work anymore. The graphics would look too crude and abstract.

Also we've certainly increased our ability to tell story, which has helped somewhat to broaden the audience (particularly in the older age groups). And the level of realism in Call of Duty has to be seen as a positive in the ability to sell a genuine World War 2 experience to the player.

In thinking of the general trend though, where the ratio of player experience to development effort is in a constant decline, in terms of comments that Louis Castle recently made at GDC panel discussion. Castle commented that we need to get more disciplined away from the tendency to put so much content in games, lest we destroy our business proposition. Louis should know - his company, Electronic Arts, thrives on sports simulations, the one type of game I can think of that's immune to this problem.

Though many of us might be loath to admit it, sports games are unique in that, barring a screw-up, they genuinely get better with each iteration and improvement in technology. Because of the inherent constraint of the game's definition, the development staff can focus in on better feel, better UI, better replay. If the producer of NBA Live was told to make it "more epic", the absurdity would be obvious. But practically every day, somewhere in the game development world, word is coming down from on high for an increase in "epicity," to coin an annoying future buzzword. And don't think for a minute that this trend does not come at the cost of actual play.

Good or bad though...like I say, I almost don't feel qualified to say. There's value to an epic adventure, and in the hands of the right player it might be just what the doctor ordered. If I had to answer honestly, I'd probably suggest that this is a bridge that's been crossed and burned, and that we can't ever go back. Most days, I'm fine with this. I know for a fact that Heavenly Sword or 99 Nights couldn't even be contemplated on the old hardwares, and these are games that interest me a great deal. They look like fun.

But every once in a while, in a moment of indulgence, I do miss making all that gameplay, such as silly puzzles involving "sun seeds" that chase away anthropomorphic clouds. That was good stuff.