Frayed Knights Dev Diary: Design Doc Fun!
I used to think I was pretty good at game design. I had a good head for games and what made games fun. I had lots of great ideas. I even got paid real money to do game design work and to be "consulted" on gameplay. Cool, huh? Professional game designer - that was me. I attended several game design lectures at GDC. I read some books on the subject. I had long discussions with other real, professional game designers.

And I gradually came to realize how much I sucked at it.

Perhaps traumatized by my experience as designer / advisor / student at GDC, I decided that I really don't like design documents very much, and I've taken a very "light" approach towards documentation for my other indie game projects.

But for a game the scope of an RPG, a "real" design document was needed. Kinda. There's a staggering amount of dialog, clues, items, quests, mechanics, and other elements that need to be kept track of and communicated to others. So I'm going to be talking today on what kind of things I'm doing with my design, not because I know what I'm talking about, but mainly because these are things I'm trying to do to "suck less." This is one man's evolving approach to game design. I've erred on the side of too much and too little and just too poorly done in the past.

As I've mentioned before, I consider a design document a "paper prototype" of the game. A foundation, not a blueprint. Nearly everything in the design doc can change in development, and plenty of it should. But its also important to have a clear idea of what your goal is before you set out on any journey, and with something as complex as an RPG that's hard to keep all in your head.

The Notebook
One thing I've frequently felt - as a programmer - is that what I really needed out of a design document wasn't prose, but bullet-lists and tables and formulas. Not only are they more concise and easier to create a task-list out of, but they are easier to maintain as changes to the game design inevitably happen. Interestingly enough, that sounds a little like how the first (and best) Ultima design documents were formatted.

One of my favorite books in my gaming library is Shay Addam's "The Book of Ultima." I picked it up in college, and was always fascinated by the behind-the-scenes look at the development of the Ultima series (up through the sixth installment).

One thing that fascinated me was Richard Garriott's approach to a design document. It was a notebook, often stained from Chinese food, packed with everything he and contributing designers could come up with about the next game world - all the interactions, characters, clues, and so forth. It was their bible. It was developed to be used, not to be distributed to management.

I'd really love to see some photocopies of some pages from a couple of those notebooks. Somehow I expect that they are closer to the "ideal" design document than some of the big, bloated monstrosities I've seen in my career (including a couple that I have even been partially responsible for).

The Frayed Knights Document
For Frayed Knights, I used a notebook, plus lots of text files. I'd jot down things as they occured to me. I'd occasionally try to create a cohesive explanation of a game system. My notebook had a bunch of scrawled mathematical functions, often scratched out and replaced with new ones. They were hardly cohesive notes. They were filled with discrepancies and contradictions, and holes a mile wide. And they weren't exactly well-organized or easy to edit.

So as much as I admire Garriott's approach, after several months of making these notes, it came time to compile them into a semi-formal (though still hopefully lightweight) design document. I don't have the gift of Richard Garriott's experience and eye for design completeness, so I'm falling back a little on more formal tools to help me through this process.

Using a Template
In case you really have no clue about a design document, Christ Taylor (of Gas-Powered Games) has a template available on the web for use by anyone. There's another one here. I think in both cases they are a little bit of an overkill and shouldn't be used without major editing. But the real value in the templates is helping you account for everything, and helping you avoid too many gaping holes in your design. Keep what is useful, chuck what you don't need, and expand on the idea.

By going through this process I'm forcing myself to answer some hard or not-to-exciting questions. The most difficult and annoying questions are often the ones that really need to be addressed the most. Questions like:

* What does the save game menu look like?

* When the player encounters a narrative, does it refer to the avatars (the Frayed Knights) in the third person, or in the second person (as if the player was part of the group). Does it ask the player, on one menu option, "What do you do?" or "What do they do?"

* How are the tutorial messages going to be presented?

* What sort of interactions does the player have with objects in the inventory

The answers to all of these questions can (and should) change during development, but I think it is a good practice to take a preliminary stab at them early when you can still see the forest for the trees.

Drawing Pictures
One lecture on game design I once attended at GDC recommended making lots and lots of pictures (simple hand-drawn line drawings would do) of what the screen would look like at various stages of the game. A little square to show the screen, and then whatever characters and UI elements are needed. It works really well - after all, a picture is worth a thousand words. And as far as I'm concerned, sparing a thousand boring words for one clear picture is a complete win.

Having a picture on the page - and asking yourself questions about it - is a much better tool for identifying problems than text. I can ask myself the same questions the player might ask themselves by looking at the main in-game UI and saying, "Now how do I know which way I should go? How do I use that door? What happens if I click here?" It's amazing how often something that seemed completely clear in my brain turns out to have some real problems once it is on the screen (or on the page). It's better to come to grips with the problem after a twenty-minute design session than after two days spent coding it and budget already spent on art resources.

In addition, the pictures placed all together, tell the story of the player's perspective on the game. This can help identify missing elements. As I lay them all out, I try and make sure there's a clear transition, that everything needed to go from screen A (say, an inventory screen) to screen B (a combat encounter) is present and accounted for.

The Story of The First Five Minutes
I've harped on how critical the first five minutes of the game is to a potential customer. One trick I picked up at some point was to actually document the first five minutes of the player's experience. Alternately, a sample of five minutes of gameplay from anywhere in the game will do nicely, especially if it includes most gameplay elements.

Like laying out the pictures, this story is really useful for exposing flaws in the design, or holes in the sort of mechanics you are supposed to be designing.

This helped me this week as I finally took some nebulous concepts concerning a combat encounter and had to break them down into both presentation to the player, and the specific details of what was going on at the game mechanics level. Fretting over these details for the purpose of creating a "First Five Minutes of Gameplay" description really helped crystalize some formerly fuzzy ideas.

Lists and Charts
A lot of what I'm working on can best be described as "reference sections," which don't differ a lot from my notes from my notebook. These are just lists and brief descriptions of characters, places, and things to interact with in the game - where they are found, and what their purpose is. Charts, tables, and lists.

I don't expect the design document to be detailed instructions to a perfect stranger on how to make Frayed Knights. Its purpose is to keep the details straight and help communicate them to anyone else that may be involved in the project.

For designing locations, I am not creating maps, except in a very abstract fashion. For things like the first dungeon, I am instead just creating a list of important locations. I describe them briefly, and explain what cool things should happen there, and what sort of challenges they'll provide to the party. This is a lot like how I plan out adventures in my pen & paper games... I figure out the highlights as cool imagined vignettes, and let the transitions take care of themselves.

Instructions To The Player
One trick where using prosaic, detailed instructions CAN be useful is mocking up the final instructions to the player. You can create a section of the design document that can be lifted out, dropped into another file, edited and cleaned up a bit, and then packaged with the rest of the game as player documentation.

I'm not doing that. Yet. But it sounds like a cool idea.

What's Not Going In
Some parts of the "design doc" are not getting compiled into main document. For example, I have several pages (not nearly enough yet, IMO) of dialog that I keep in a separate document. I also keep task lists in a separate file, as that one changes on a daily basis.

Is It Useful?
The design document - which is still evolving - has already come in pretty handy:

* First of all, it's helped me move my design concepts from the vague, fuzzy mental concept stage where everything just magically works to a more concrete level where I can spot and fix flaws, see missing elements, and start coming up with some high-level task lists.

* Where I have been doing some actual programming (prototyping, mainly), it's been really nice to just lift some text content (like dialog) directly out of an existing file and drop it into the game.

* When it came time to have an artist do some quick concept sketches of the four primary characters, he needed to know what the game was about, and some background information on the characters. Cut & paste! Plus some reference art I'd already gathered. We still had to get together and chat about the characters in person, but I was able to provide him with pieces of the design doc to give us a common foundation to discuss ideas.

What Am I Working On This Week?
This week, I intend to finish the design document (well, version 1.0). It's a tall order, especially with so much work still pending on Apocalypse Cow. But I'm excited to get moving on with actual development.

So next week, I should probably go into more details of the game's design. If anybody's actually reading this, is there anything in particular you'd like to know about the game?


(Vaguely) related serial stupidity:
* You Can't Design Fun On Paper
* Frayed Knights Dev Diary: Prolog
* Frayed Knights Website


Read Or Post Comments On The Forum

Labels: Frayed Knights, Game Design

- posted by The Rampant Coyote @ 6:00 AM (Permalink)