gameslol

The first rule of game design is that it’s not all about writing design documents. The second rule of game design is that it’s not all about writing design documents! ROARRRR! (The third rule is: no smoking.)

If you already knew that game design isn’t all about writing design docs, then that’s great. I like you. We should do the secret handshake. As for everyone else, I’m sorry that you have been misled, and hopefully I can help make some amends. 

There’s a couple of things in the game industry that are not said often enough, and the truth about game design is one of them. Yes, developing a game almost always involves documentation writing. And being good at that is one of the most important skills a designer can have. But sadly there’s a myth that writing giant Game Design Documents (GDDs) is what designing a game ultimately boils down to. This myth needs a thorough pummeling. 

I was led to believe the myth many times. When I was younger I got interested in how game designers worked by reading interviews with them and sometimes they gave me the impression that the majority of design work was done up front in a word processor. I was also really into adventure games and some really extensive GDDs of adventure games were being made publicly available (such as those of Leisure Suit Larry). Seeing and hearing mostly about that one specific part of game design often warped my perception of it.

When I was in high school, a few times I wrote GDDs for games that I’d dreamed up. But usually I quickly got discouraged and abandoned my attempts. It all seemed pretty daunting. These GDDs are so comprehensive… when you have just a basic idea to start with, how are you going to flesh it out and specify every detail? While I was writing I also felt that with each following page I was gradually sucking the life out of the original idea. For a long time I struggled with this.

Later in college I read game design books that mostly reinforced the notion that I should be writing these ‘project bibles’. When I searched for game design help or tutorials on the internet, something that came up a lot was Chris Taylor’s GDD template from 1999. Just the template is 30 pages long and has sections for every conceivable aspect of a game. As useful of a tool as that could be, it tricked me into thinking that this was 95% of what game design was about, when in reality (at least in my experience) it is maybe 30% at most.  

Mind you, it’s a widespread misconception. Last week I saw a question on LinkedIn from a freelancer new to the industry, who asked how much to charge per design document. He probably assumed that GDD writing is the same as screenwriting when really it isn’t. The other day someone told me about interviewing candidates for a game design role and some of them showing up with 100+ page example GDDs, which was not necessarily seen as a positive.

I often get asked the same questions by aspiring designers: How do you write a GDD? How many pages should it be? I really don’t know how to answer those questions without also telling them a lot of other things.

The main point to understand is that you can’t design something just by writing 100+ pages about it. Game design isn’t about precisely predefining everything in a set of blueprints like an architect and then building it to spec.

Instead, it’s a highly dynamic process. After all, gameplay is emergent and hard to predict. When you’re writing about this cool new feature for a game, can you really foresee the myriad of ways it would work in the countless possible gamestates (not to mention with different kinds of players)? Even the smallest changes can have effects that trickle down through every part of the game. And when you let players loose on a game, they tend to explore and exploit every nook and cranny of the possibility space. Eventually, you can make pretty good educated guesses about the impact that certain changes will have on a game, but you must always be prepared to be surprised by how things actually turn out. 

The key to exploring a game’s true potential is to prototype early and to test it all the time. In any stage of the game’s development, tangible results should have priority over documentation just for the sake of it. 

Testing can actually be a bit scary. It puts your ass on the line. As much as you might want designs to stay within the safe confines of your mind where they exist in the most ideal hypothetical conditions, you must let them loose into the cold hard reality. Doing so is essential because testing always gives you useful information. Even if you test something that you know isn’t very good yet, it can lead to new discoveries. And eventually, you can figure out which elements really work well, so that you can build on those elements with confidence. 

In my last project, it took almost three months to find the soul of our core gameplay system. Before that we were stuck with a prototype that was showing some potential but wasn’t really fun. Eventually we looked at all our past iterations, tweaked many elements and redid some others entirely from scratch. We didn’t know if the new approach would work, but we based a lot of our assumptions on our playtests of previous iterations.

We did a team-wide test (as we’d usually do about every two weeks), and as I watched over the shoulders of my coworkers who were playing I was delighted by what I saw. People were focused on their screens and trashtalking each other. I saw the producer facepalming himself and then laughing out loud because of a decision he’d made. I could tell that we’d gotten to that weird breakthrough moment at which the game suddenly becomes more than the sum of its parts. It’s an exciting moment when a game truly comes alive for the first time.

The point is that it would have been impossible to design that version of the game all the way at the start. That’s because you can’t just hit that kind of sweet spot in the game mechanics when you’re shooting blind. The information from every one of our experiments (using real players engaging with real interactive system) contributed to our eventual success. 

I wish back when I was in college I’d already been taught about the merits of prototyping, testing and iterative development. A wonderful article that sheds some light on gameplay testing and fine-tuning is Halo 3: How Microsoft Labs Invented a New Science of Play at Wired.com. Some fantastic anecdotes are also to be found in Valve’s in-game commentaries. We need more of this. It will help create a more complete picture of game design in people’s minds.

Documentation is still important, of course. However, a lot of studios no longer work with text documents, but put all the documentation on separate pages in a wiki. This gives you much more flexibility, allows you to work collaboratively on a shared central location, and since it’s all broken up into smaller pieces team members are more likely to read them. Quite a lot of documentation can be generated over time, but it’s done in a much more tactical way.

The effectiveness of documentation also largely depends on the skill of the writer. I think that traditional GDD templates can easily turn people into bad writers who produce bloated text. By far the best practical guide for writing crispy and effective documentation that I’ve come across is Damion Schubert’s GDC talk, “How To Write Great Design Documents“.

There also happens to be a great quote in one of his slides: “No game design survives contact with reality unscathed”. I really like that quote. It is truly sage advice. What it means is that you always have to be prepared to let go of the ideas you’ve put on paper and iterate on them until they truly work. 

I would also say that it really helps a lot to think of documentation not as a static artifact, but as something you take along with you on the journey through development. 

For instance, GDD is good for keeping track of the reasoning behind decisions, particularly on longer projects. Sometimes you forget why decisions early on were made, and you waste time re-argueing points you’ve already argued before. Documentation can also be great for storing feedback and assessments from playtests, keeping a graveyard of rejected ideas, or keeping track of changes in each build. This makes backtracking much easier, and it can also be great for employees who are starting later in the project cycle.

Similarly, documentation can include forward-looking information. Building some prioritization into design specification is very helpful at times. Which features are essential? Which ones are nice to have? Which ones are probably going to be for the expansion pack? It’s always tempting to ‘over design’ when writing documents and include far too many features and details. But that’s not as much of a problem if you present a design as having various possible layers of sophistication. That way you are prepared for different production and budget scenarios, and have more flexibility. 

I think traditional GDDs tend to deal a lot with the “what”. What weapons? What locations? And so on. But they reveal little about the “how” or “why” of design. In other words, there’s a lot of talk about the ingredients, but little about the recipe or the cooking process. A list of ingredients doesn’t guarantee a good meal. To become a good cook, you have to see the ingredients as only the starting point. 

Writing a description of a shotgun and all of its features and stats in MS Word is the relatively easy part. What matters is how that shotgun feels and plays and how it interacts with other elements of the game in all sorts of different circumstances, not to mention how the shotgun fits into the overall vision of the game. This is something that takes figuring out. To understand game design is to understand the process of game design.

Maybe all of this is beating a dead horse. Maybe everyone knows that the old model of game design doesn’t actually match reality. Sadly there’s plenty of evidence that the horse is still very much alive, running loose and whinnying its horrible lies to anyone willing to hear them. It needs to be stopped, and possibly murdered. 

(Oh come on, don’t give me that look… it’s a metaphorical horse.)

This entry was posted on Saturday, December 13th, 2008 at 8:58 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.