Thursday, June 2, 2005

Using a blog as a game design document

I've written lots of design documents...Hundreds and hundreds of pages of design documentation that occasionally gets turned into a nifty product. It goes without saying that the vast majority don't get read unless they are essential to the final implementation. That is a start, but I'm always looking for better ways to convey ideas and get people on board.

What is the goal of a design document?
Not all design documents are created for the same purpose. The two most common ones I run into are as follows:
  • Convey implementation requirements: "Put this feature C at (X3, Y4) and hook it up to widget B!"
  • Convince: "Let me tell you a tale about widget B and how cool it would be to implement!"
The first is the traditional use of a design document and tends to focus on lists of implementational details. If it isn't specified in the design document, it isn't going to get done. So people tend to overdo the exhaustive detail. Honestly, it is no wonder that people avoid reading such literary monstrosities unless forced to by whip cracking managers.

The second is quite common, but rarely acknowledged as part of the development process. Teams don't always get to meet communally on every feature and usually one or two people have a strong understanding of a particular feature's benefits. These feature champions often write the design documents, the one touch point that is available to all team members.

Problem: No one reads it.
Here's the problem. If you write the first draft of a feature design in the highly specified fashion promoted as a 'good design doc', no one will read it and it becomes hard to build any sort of excitement around the idea. I've seen hundreds of great design ideas wither on the vine because highly technical design docs are tossed over the fence and no one ever really grasps the full picture about why the feature matters.

Problem: Too expensive to create
Documents intended to convince are usually created in the early stages of development. Ideas are rough and speed is essential. Often you'll need to bang out a feature concept in a spare 30 minutes and then submit it to the team. If the authoring medium is too difficult to use (raw HTML comes to mind) no one will take the time to put their design thoughts down.

How do we write a design document that convinces? (And isn't horrendously boring to read or expensive to create)

A blog as a narrative design document
One of the things I like about blogs is that they have an inherently linear narrative built into the structure. "Monday, 8:42am: Today, I ate bacon." followed by "Tuesday, 8:15am: This sounds like a bacon day too" Each post gives a sequential snapshot of a person's life.

What if a blog could tell a reader friendly narrative story about a product design? Blogs are easy to write and generally reader friendly. The text doesn't have to be structured like a novel (few blogs are). But like a story, you can mention relationships between items coming up in the future. You can use more casual engaging language. You can lead the reader through the beginning of the project all the way to the end.

How iterative development maps onto a blog
Iterative software development lends itself quite well to a story where each iteration is a chapter. In iterative development, you typically follow a standard pattern
  • Identify the big story
  • Identify the most important things that need to be done first from the customer's perspective.
  • Build it.
  • Ask what needs to be done next based off your current project status and customer needs.
  • Repeat with a new iteration.
What you end up with is a rich explanation of the rational behind each feature. As you add features, your are building a narrative leading towards a final goal or product state.

The role of comments
A post in a blog is an authoritative statement of reality. A page of a design must also be authoritative. However, a design intended to convince others must also have a feedback mechanism to address concerns, worries and other ideas. The comment section of a blog is perfect for this. Each 'chapter' of the design is up for public discussion. When changes must be made, the author of the post can go back in and make the revisions.

Specifying the Blog-based Game Design
What are the elements of a blog-based game design?
  • Introduction: The big picture on why this product matters. Who does it serve? Why should they care? Why should the developers care?
  • Walkthrough: A simple story illustrating how the game plays. This is an example illustrating the big story.
  • Core Systems: What are the core game mechanics that the player will be engaging in. What systems are required to build this core game mechanics?
  • Release: This post describes a minimum bundle of features necessary to create a truly playable game. The game can be broken, but everyone on the team needs to feel the vision and understand what happens next.
  • Feature: What is the first feature that will make this game come alive? Include descriptive example text. No lists please.
  • Next Release: Celebrate the previous Release and do a virtual post mortem. Discuss what needs to happen in the next release and the features necessary. Tie it all back into the big vision. Repeat!
  • Conclusion: What happens at the end of the project? What is the result? Sell the reader on the fact that all this effort was well worthwhile.

All these posts are kept to a manageable size and have a narrative writing style. If the post is too long, chances are slim someone will implement it without losing sight of the big vision of the product.

Benefits of Blogs as Design documents
  • Easy to author: No fancy formating, just bang out the text. Sweet.
  • Searchable: Looking for something? Just search the blog and you'll find it.
  • Linkable: Want to send someone just a single feature. Forward the link.
  • Comment Friendly: Nuff said.
  • Speaks with one voice: The posts are the authority. Everything else is just noise.
Problems with Blogs as Design documents
  • No Autolinking: Typically a designer will build up a unique vocabulary as the design develops. It can be useful for the reader to be able to access these words. Wiki-style autolinking would alleviate this issue.
  • Linear structure limits non sequiteurs: Traditional narrative plays with this issue constantly. Thankfully most readers can deal with a brief side jaunt over to a different story thread before coming back to the main story line of the design.
  • Lack of index: As documents get super long, a blog can become hard to navigate without an index or tagging system of some sort. Some blogs solve this, but Blogger doesn't. :-)

A Test Case: Putting theory into action.
I have a short (13 page) design document for a casual strategy game called SpaceCrack that I'll be posting on over the next couple of months. I'm going to 'blog the design' and see how some of my theoretical structures work in practice. My hope is to hone in on a 'readable' game design document that can be easily shared with a wide group of people.

As part of the bigger picture, I've noticed that professional complete game design documents are a rare thing on the web. This whole exercise is a stab at shedding some light on a traditionally black art of game development.

take care

PS: A side note on Wikis
I've used Wikis for design documentation recently and like them a lot. The change tracking, communal commentary, and auto-linking are wonderful. Right now we are using them as our design document method at the office. They are the best thing I've seen so far for writing design documents. The two topics that are painful
  • Poor at convincing: Wiki's lack narrative structure that makes them difficult navigate and read. Instead of one argument the flows from beginning to end, there are multiple ways of reading the same document. Nothing 'builds'. Instead the reader is left with a spattering of discrete information.
  • Lack of a single voice: Wiki's nature is that they are quite chaotic at times with people jumping in at random points and offering a wide variety of comments, ideas, etc. This is mentally invigorating but can be difficult to parse. Often developers are left scratching their heads and thinking "So, what are we supposed to do?" A good gardener can help, but this generally results in the loss of the original comments (even when you have versioning, no one reads the old versions)


  1. Hey Danc,

    Been off the internet for quite a while. Lots of entries here.

    I admit I'm skeptical about this idea. I just don't think a blog works, because of the reasons you mentioned (most importantly the sequential nature of it...) It's difficult enough to carry on and manage discussions in past entries of a blog...

    I think as a design cycle log and status reporting type feature, where things are constantly being updated, that'd work fine...

    But blogs are not organized in a convenient manner for searching and either you end up duplicating entries to have them float to the top, which leads to confusing search, or you end up burying important features way back in old entries...


  2. Aye

    I'm sceptical as well. That's why I'm giving it a shot. Can I make it work? Mostly I'm looking at a way to quickly post information in a friendly fashion. A wiki may be the ultimate answer.

    BTW, you are the basis of the persona used as the core of the SpaceCrack design. I couldn't resist. Naturally, some of the details are changed to protect the semi-innocent.

  3. A blog is no more or less of a good idea than anything else, frankly.

    I thought that using a wiki was going to end my troubles: easy to navigate around the design of a highly coupled system, lends itself very well to code documentation.

    But it still ends up huge, and people still refuse to read it.

    As it turns out, different kinds of document end up being good for different kinds of people. PR just wants a cut down version, with the wow and pizazz and possibilities thrown up, and they want it like a goddamn hit of heroin - give them a normal word document. It's something they're familiar with.

    Coders needs something closer to a dry functional description - they want detail, instantly, explaining all the considerations they must make about a certain function. The wiki is great for this.

    Production just wants a flat list of assets. The Wiki's catagory system can be good for helping you to compile this, but you're still doing lots of extra work, because no-one can be bothered to find the assets for themselves. Boy oh boy.

    I'm doing triple the work, here. Anyone got any solutions?

  4. The thing I like about wiki's is that you can create pages that reference the same information pretty easily.

    - Each asset or system gets a page
    - There is a directory that lets you see the pages and dig into them. This is good for the programmers. You can even have iteration pages that list the systems to work on for each iteration.
    - An asset list for coders.

    Marketing is the difficult one. As you say, they are looking for 'flash' and this pretty much has to be written from scratch. I've tried to have 'mother pages' that describe the big concept behind a set of features. This 'big concept' is often reusable for the marketing people and also serves the purpose of convincing other team members about how everything fits together.

    Having an agreed upon site structure and a 'wiki gardener' that prunes the document before it gets too unruly can also help.

    No great solutions...most processes that make life a little easier. I think it would be fun to build a 'design document tool' that is a wiki/agile development/forum system that combines a bunch of these features together into one system. Of course then you would have to get the team to agree to use it (and that is typically the hard part. :-)