You Can't Design Fun On Paper
Aside from violence and the role of storytelling in videogames, one of the most hotly debated subjects about game design is the role and format of the design document. I've written them, I've read them, I've had to program from them, I've attended lectures on them, and I've asked people about them. I still don't have any good answers.

Massively Detailed Design = Bad Game?
At one point, when I was attending GDC annually, I noticed with amusement that there was often an inverse relationship between the size of the design document and the success of the final game. That breaks down when you start hopping betweem genres, as naturally something like an RPG will require a much more extensive design that has to help communicate needs to a larger team than, say, a casual match-three game.

I tend to view the monolithic, early-delivery design document as an artifact of the "waterfall "software development era. Which unfortunately is alive and well at too many game studios. The way waterfall works (or, in my experience, doesn't), for those of you unfamiliar with it, is by assuming that software development follows very distinct, orderly phases. First in the requirements gathering, then design, then coding, then testing, then delivery. If something goes wrong, you back up a step (or two or three or...) Great in theory, but unless you are creating software to run the guidance system for a satellite or the core code behind a life-support system, it really doesn't happen that way. Like ever. What really happens is that it starts that way, and then changes happen, and then everything short of (and sometimes including) delivery gets jumbled together. More modern development methodologies take advantage of this naturally occuring phenomenon, and try to parallelize them as much as possible to maximize speed of development.

But I think that's why I've never seen a design document stay up-to-date and get used more than halfway into any game project.

Well, It Sounded Like a Good Idea At the Time
At one point, I took the mantra, "You can't design fun on paper!" I still hold to it. I've seen a lot of elements that sounded great on paper, but once implemented in the game, they sucked. For example, during the development of Jet Moto, the design doc had the idea that riding off a cliff would end the game. We thought it would make players more careful in their driving when near a cliff. In reality, it only made players (*US* at the time) more frustrated. When you are in a race, you don't WANT to be careful - you want to be riding the bleeding edge, not being safe. Maybe more experienced designers would have recognized the problem on paper. But a lot of times, things just have to be tried. And a lot of times, things become apparent during development that should become a major part of the game, even though they were not part of the initial design.

The Design Document as a Spare Brain
I'm not saying that you shouldn't create a design document. Quite the opposite. You need to start somewhere. Even if you can't design fun on paper, you can certainly keep track of a bunch of ideas that might lead to something fun.

Even if you are a lone-wolf developer, having a concrete list of things to do, features to implement, and some vision to hold to right next to you can be invaluable. When I'm sitting in front of the computer to do development, I tend to shift into a frame of mind that's very goal-directed and not super creative. The creative part of my brain tends to shut down. I get tunnel vision. I can't just spontaneously come up with dialog while working on a level. At least not very good stuff. The creative stuff comes when I step away, possibly out taking a walk or mowing the lawn or some other endeavor where my brain is free to roam. SO I try and record that stuff in something that vaguely resembles a design document (mainly a collection of notes that occasionally get organized, plus a running task list).

My wife can usually tell when I'm working on design, as I'm usually up and pacing around the house as much as I'm in front of the computer.

That seems to work for me as a partly lone-wolf developer (lone-wolf plus contractors and some helping hands). As teams grow, so does the overhead required for team communication. A more formal design document may be required at that point. But excessive wordage is still to be avoided. I think a good design document should consist mostly of pictures, maps, tables, formulas, lists, and cross-reference links. Those are far easier to use than massive paragraphs of text - and the document's only purpose is to be used. The K.I.S.S. (Keep It Simple, Stupid!) principle always applies!

The Design Document Is Just Your First Prototype
Incidentally, "Design Document" is kind of a misnomer - it usually consists of lots of documents. If you have dialog in your game, then that may be in its own document. For indie development, my "design document" is often a collection of to-do lists and notes. Maybe with a kick-butt pitch statement. (Well, at least I thought it kicked butt when I wrote it)

I still believe that it is important to consider the design document a "paper prototype" that will become obsolete in stages. As elements of the game get implemented, those parts of the design document should be considered obsolete and that part of the game becomes the design. An actual, playable prototype is infinitely superior to a stack of paper (or a big ol' electronic file, as the case often is today).

So in a nutshell: Planning is your friend. Having a written plan and design before you begin hardcore development is a Good Thing. But don't overdo it, and don't fall into the trap of thinking it is a blueprint or complete recipe. It's just a foundation for you to start from, and your first prototype. Eventually, you should (and will) outgrow it.

And if you don't want to just take my advice on it:
* Amanda Fitch mentions in her audio interview that she created Ahriman's Prophecy by designing as she went. For Aveyond, she went ahead and designed it before ever getting into development - including writing over 250 pages of dialog. It's interesting how she's tried both ways... and it sounds like she's sticking with the more detailed design in the future. RPGs can be complex beasts. I have a tough time imagining how you'd tackle a real, commercial-quality RPG without having at least a moderately detailed plan first. Even if the plan changes a lot. I'd be really interested in hearing how much her design changed during the development of Aveyond. (So if you happen to catch this post, Amanda, please feel free to weigh in!)

* Quote from Phil Steinmeyer: "I do not do detailed design docs for my casual games. I just start coding and have a rolling to-do list." This makes sense to me. I think a design document for a casual game - one you aren't trying to pitch to a publisher before starting full development - would probably consist of a picture or two, and a list of potential features and game elements. Three pages, max.

* Quote from Joe Maruschak: "It pains me to see both large projects with no plan and to also see inexperienced developers making design docs that are not 'right' for the project. In the worse cases, too much planning can lead to a false sense of security that things are 'on track'. I don't see this as specific to indie projects or developers. I have seen first hand cases of where the design doc was being followed, milestones being hit, and everything looking great.. until it the game was nearing completion and was not particularly compelling. " So going forward with a big project and no plan is bad - but it's possibly even worse to be dogmatically adhering to a plan without paying attention to the evolving game itself.

* Quote from Chris Canfield: "Ironically, one of the worst things you can do to a design is to get too detailed too quickly. There is a flexibility of design that you really need to create an experience as parts of it come online... A lot of what goes into the game does so based on good ideas from across the length of the project."

Labels: Game Design

- posted by The Rampant Coyote @ 11:19 AM (Permalink)