« TDD triumphs again! | Main | I Hate My Coffee Machine »

October 07, 2007

Comments

Pag

I disagree with your point about not spending more than an hour designing/specing any feature.

You're right that specing features in minute details ahead of time is a waste of time, because a multitude a factors affect how to handle those minute details. Trying to decide everything in advance is the major sin of waterfall design.

However, the reason I disagree with your point is because I believe in having a strong design vision ahead of time. It's possible to have strong, well-defined design ahead of time without falling in the trap of defining absolutely everything ahead of time.

When I design a game, I ask myself for each element whether it's easier to iterate on the idea on paper or in the actual game. Higher level concepts are easier to iterate on paper -- flip-flopping on whether your strategy game is real-time or turn-based is easy on paper, but long to prototype in software, for example. Lower level elements are easier to determine once the game is actually running -- it's meaningless to decide the length of a dribble animation in a basketball game while the game's just an idea on paper. If a part of the game is easier to change on paper than in software, then I spend a lot of time thinking about it while I'm writing the design to make sure I make the right decision. If a part of the game is easier to change in software, I don't even put it in the design doc (to avoid a programmer doing exactly what I said, but not what I want).

There's no hard border between those two types of features, and it's often not obvious how much detail should be written about each feature. How much detail should be decided ahead of time for levels? Do you just decide where they take place? What their key moments are? The rough layout of the map? The position of every enemy and collectable? The precise point to stop adding detail can be hard to decide. And of course it's not because something's been decided ahead of time that it can't be changed once the game is running.

I think of it like a movie scripts. Movie scripts don't detail everything that's in a movie: camera positions aren't described, sets aren't described in detail, character outfits aren't detailed much, etc. The high-level stuff is decided in the script, but the multitude of lower-level decisions needed to make a good movie are made during production. The best design docs work the same way: they define the high level concepts very precisely, but leave the lower level decisions to the later stages of production, when there is something concrete to base those decisions on.

Anyway, that's the gist of my answer to the question "how can we have strong design vision, without falling into the trap of waterfall development?" And that's why I think it's worth spending a lot of time designing features, but only at the higher level.

Nathan McKenzie

Pag:

Can you program at all? (don't read that pejoratively - it's an earnest question =))

My experience, as a game designer who is also a pretty quick programmer, is that I almost always have much better success iterating in code than on paper, regardless of what aspect of design I'm looking at.

I guess I would liken it to musicians jamming, rather than movie scripts - sometimes I just have to roll up my sleeves and prod a bunch of stuff until some of it starts jelling and some of it falls by the way side. Then the stuff that works snowballs, and suggests tons of other things, and before long, the design has grown organically around something that turned out to be really promising that I didn't even know about before iterating.

Anyway, from that end, my experience mirrors Jamie's - I find about a hour of paper+pen or conversation is great for mapping out what I (and peers) _think_ is the problem space, and for nailing down tentative solutions to explore. But for more than that, if I'm working in a space where I'm doing anything new or interesting, I find further conversations or designs are often starved of the kind of feedback that can help guide good decisions.

(I incidentally have exactly these same reactions to code methodologies, where many of the exact same issues come up about upfront planning versus iterative design, of course)

I doubt there's a right or wrong - just an assortment of war stories, and these are mine.

It might be, though, too, that this reflects the kinds of designs I find interesting and personally worth doing. If I were making Curse of Monkey Island, where the technologies and gameplay mechanics were fairly known quantities and the pleasure of the game derives heavily from the writing, characters, voice acting, and artwork, mostly iterating on paper would probably make far more sense.

The other thing in favor of Jamie's point, at least from my experience, comes from the nature of teams and discussions. As hard as establishing a vision is maintaining and enforcing a vision. On every team I've ever been on (and perhaps you would argue there weren't strong enough leaders), as long as design was a verbal/textual thing, everyone within talking distance, regardless of their knowledge or experience or discipline, felt that they had co-equal design ideas and input to the central ideas being generated. Selling vision, and keeping it from wandering off to a known title that people have played recently that they all love, can be wildly difficult. This seems especially true higher up management and producer food chains in highly bureaucratic organizations, where power often doesn't rest solidly on the people who are ostensibly experts at game design. At least in my experience, the moment that things are runnable, and playable, and can be interacted with, particularly if you can capture something legitimately fun early, you start having a fighting chance of having your design stick without infinite hours of pointless political infighting and doubt.

Pag

Actually, I was a programmer for a few years and worked on a few games before turning to game design. And I actually had an argument with a programmer who wanted me to make a bigger design doc upfront recently -- I guess you can't please everybody ;)

I think code iteration works very well for things that can be built in a few days by one or two people. Beyond that, it becomes very costly to iterate. Sure you can continue iterating in software at all levels, and it might bring great results, but it's going to be very long and expensive because you're basically building multiple games and picking the parts of each that you like. I think there comes a point where your time is better spent on iterating on paper to get nearly as good result as if you iterated in software -- and all the time you saved by doing that can be used to polish the game or make it more profitable.

That said, different types of games have different amount of high level design that can sensibly be done. Jamie's game, as I understand it, is a smaller game that's very dependant on fund controls and AI behaviour to be fun. The base concept is simple, but the devil is the execution and code iteration makes a lot of sense for this. I wouldn't write much of a design doc for Geometry Wars, for example.

On the other hand, some bigger games could really use more iteration on the high level stuff -- iteration that would be hard to do if you had to build large parts of the game every time. Take Halo 3, for example. I played it single player last week-end and was really surprised about how bland most environments were. Everything was extremely well polished -- they obviously iterated a lot on all of it -- but the levels, weapons and enemies were, for the most part, fundamentally generic. You start in a jungle with nothing really memorable in it (but it's very pretty), you pick up weapons that are similar to those of other FPS (but they're very well balanced) and fight generic alien enemies (with finely tuned AI). It might very well just be me, but while I found the small things impeccable, fundamentally I found things lacking.

My gut feeling is that Bungie jumped right into development, figuring they'd iterate to find what's fun and focus on that. This worked, but they couldn't iterate as much on the higher level aspects of the game (you can't just throw away an environment that a small army of people have been working on for 4 months), so these aspects suffered. Spending more time thinking about the high concepts of levels and about the story before they're in the game and hard to change might have helped there.

Then again, I wasn't on the Halo 3 team, so I don't really know. And the game sold a gazillion copies, so I might just be full of it ;)

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

The Games

  • Energy Hook
    3D grappling-and-swinging-and-running-on-walls-and-doing-tricks ... with a jetpack ... for style!

Jamie's Bragging Rights

  • Spider-Man 2
    The best superhero games of all time Game Informer
    Top five games of all time Yahtzee Croshaw
    Top five superhero games of all time MSNBC
    Top 100 PS2 games of all time Official Playstation 2 Magazine
    1001 Games You Must Play Before You Die Nomination for Excellence in Gameplay Engineering Academy of Interactive Arts & Sciences
  • Schizoid
    Penny Arcade PAX 10 Award
    Nominated for XBLA Best Original Game
    Nominated for XBLA Best Co-Op Game