I hate design docs.
I’ve been co-hosting a radio show recently on GameDevRadio.net, where we talk about game develoment topics on a weekly basis. A few weeks back we discussed design docs, and I think I did a good job of denoting when a design doc is good or useful, and when it is bad and just a detriment to your team. Go take a listen! I’ll sit here and wait patiently, but you don’t have to listen if you don’t want to. After all, I have it
My biggest problem with design docs is that you can end up spending more time editing the design doc than anything else.
In my little world of game development, a core mechanic should be built in a day. A polished prototype should take you a weekend. If you spent all weekend working on a design doc, and I spent all weekend actually making mechanics, who’s in a better spot? You have a bunch of papers with theories on what is fun, and I have hard evidence.
That said, I have a small team (of one, usually!), and I hold a lot of things in my head. I use a few tools to hold data externally, like white boards and to-do lists, and one could argue that the collection of those things is a strange type of “design doc” I am referring to as I work. Fair enough! You might be right there.
Sometimes you have to make a design doc, because some suit somewhere (publisher maybe? investors?) demand it. Sometimes you need one for government grants. If that is the path game dev is taking you, I am sorry for your lots. But sometimes you just have a large team, and you have to make sure everyone is on the same page. Cool! I get it, and I also think that right there (the inability to effectively communicate across your large team) is one of the reasons why bigger studios take so long to make games in the first place. But I digress.
I mentioned I sometimes use a whiteboard. It’s the closest I come to “design doc” in my mind, and I wanted to share it with you!
Again, with pictures!
So let’s take a look at my word game as an example; it’s fresh and still sitting on my whiteboard. :) Back on the Sunday that was January 22nd, I started working on the game. I got up relatively early that morning, and while my head was still mostly in the clouds, I went to my desk.
Just to the left of my desk, facing me, is a whiteboard. Before I opened the code IDE, I picked up a marker and started sketching. In about ten minutes, with only minor amounts of erasing, this is what I came up with:
I might have tweaked some of the written details in the bottom left corner throughout the day, but this whiteboard has not changed since day one of my game design journey.
Here’s my notes on the image as I am seeing it now:
- This is mostly a mind-map of ideas, trying to get the key elements of the game out of my head and down on a hardcopy somewhere. I find it really helps to do this, as often some keystone element I once thought of is lost to the mists of my memory. This is also why I always carry around a moleskine everywhere I go. :)
- The left half of the board is a simple flow chart of the game screens. One of the goals of this game was to be very, very simple and uncomplex; you can see me questioning things like the pause screen (“need this?”) right on the document. I find doodling the UI really quickly definitely helps me form data structures in my head, and helps me properly organize my thoughts. If I can compartmentalize “gameplay” to a single function on the whiteboard, I know I have a system that’s easy to build.
- I sketched out what I thought the basic gameplay mechanic was going to be, in text on the bottom right. When I thought of the gameplay in my head, it was more of an image; breaking it down into these component pieces was an exercise in trying to boil the mechanic down to its bare elements.
- The top right I sketched – in red – the key questions I’d have to answer before I could have a working prototype. Questions like “how big should the grid be?” and “what if your leftover letters suck?” Identifying where your problem areas might be early keeps your mind constantly checking for these cropping up (and searching for solutions). Sometimes it’s good to put a problem on a slow boil in the back of your mind.
- I spent a maximum of 30 minutes creating this.
- I always kept it next to my desk, staring me in the face, every time I worked on the game.
- I never altered it, even when gameplay significantly shifted.
Alteration of the Core Mechanic
The entire premise of the gameplay was that you were playing Boggle, but sort of in a first-person fashion. Your character would move around on the tiles, and you could only start spelling from where you were currently standing.
If you take a look at my last two gameplay elements – in green in the bottom right of the above image – you’ll notice two entries that describe the danger element of this gameplay:
- No valid move -1 life
- Certain tiles give +1 life
That is to say, if you walk into a corner and can’t spell your way out, you lose a life – and the game would use a standard “three lives, how long can you last” model. Sounds good on paper, right?
Well, it turns out that – even with tiny board sizes – the player almost never got stuck. There was always some obscure word to spell. With the occasional 1up laying around, everyone could eventual get 99 lives an the game would never end.
It turns out that English is entirely too flexible and my game mechanic broke. Very early on I had to switch to a timer based system – remove the lives, add a countdown clock, have it work that way. This in turn shifted many of the mechanics and balance mechanisms I had in the game.
And this is why prototyping is so important: you can’t know from a document what will work, and what won’t. You have to make it. And you have to make it as soon as possible.
I could have spent another week detailing all the different ways you could get 1ups, and sketching out death animations, and ordering death-music-samples from musicians – and wasted all of that effort on something that could never work.
I left the original idea on the board though – to remind me of the core simplicity of the game. To remind me what it was at first, to remind me how straightforward the game could be. If I start altering my whiteboard, I quickly get into feature-creep territory. Besides, keeping my errors up there, constantly glaring at me – keeps my game design skills humbled. :) If I just erase it, will I learn the lesson for next time?
Visual style remained solid
When I doodled out the interfaces, it wasn’t just drawing some placeholder logic boxes. I drew little penguin doodles in there, placed some UI elements in positions I thought would be good, and had a distinctive “style map” in place. Here’s how the game ended up looking:
Check it out. Same tile layout, same penguin theme, even the pause button and timers still in their original positions. About the only thing that changed here is the level of talent doing the doodling (Thanks, Sven!)
Having a consistent driving style is important to the games I make. It helps focus development down the same path, and sometimes things just “make sense” in the context given.
I didn’t have to beg Sven to keep penguins as part of the game. He looked at my initial sketches and just ran with it.
I think design docs suck for my purposes. This is how I do it instead. How do you keep yourself organized?