Wilderness of the Unwritten
Or, Design Series Part 1.
Overview: This is the second of several articles on the design of a new board game that I am working on in partnership with Brendan McCaskell and OOMM Games. Throughout these posts, I want to give readers a sense of my design process, as well as some of the ruminations that came out of work I was doing at each stage. Check out the introduction to this series here. Today, we’re delving into the early stages of design, and the importance of guiding documentation in game design.
The Sphere and the Cone
It's a common refrain that “restrictions breed creativity,” and in my observation this is true for most people. But why is this the case? What is it about working within a framework that makes it easier to create, and not harder?
My friend David Koh is also a designer by trade, though he specializes in software systems. We did design some Magic cards together back in high school and, sadly, I don’t have them anymore. I think we even explored a day/night mechanic that we dismissed as “too conceptually weird.” Ah well, hindsight.
Reminiscence aside, David likes to describe the process of design as a search through a dense wilderness. You’ll find interesting things if you start traipsing in basically any direction, but they might not be what you actually need. The only way to determine if something you’ve found is useful or merely interesting is to first define what it is that you actually need. This means that it’s vital to set the scope of your search: focusing the area you are looking from a sphere to a cone (or a circle to a wedge, in my crude illustrations). By placing restrictions on where you look, you allocate a more manageable area to explore. Further, you give yourself the ability to assess the potential usefulness of each idea you uncover before spending lots of energy developing it. A vision document is one means of setting your cone.
Left: Too many ideas to explore thoroughly.
Right: A manageable number of ideas to explore.
Lines of Vision
But first, what is a vision document?
For a quick and dirty definition, a vision document is a brief that sets out the key features of a product for all parties involved in its creation. It differs from a pitch document because its intended use isn’t solely to explain the specs and appeal of the product (though it should do these things), but to communicate the core ideas of the project to everyone working on it. Formatting can vary as needed, but it strive to be pithy and easy to read. It should be a living document that evolves with the project. Here’s an example from the document I constructed with Brendan for Codename: Lithotaph (thanks to Kara for reminding me how cool codenaming things is).
Remember how I said not to get attached to the working title last week? Yeah, don’t get attached to any other details, either.
In addition to keeping all contributors on the same page, though, a vision document can be used to define your search cone. It does this in two primary ways:
Setting Practical Restrictions: Practical restrictions are restrictions that revolve around the product’s physical and conceptual scope. Essentially, what do you want the product to be, and what role do you want it to fill in your portfolio? Practical restrictions may be more or less malleable depending on your workflow and distribution method. If you’re making RPGs to sell as PDFs online, you’re not going to care about page counts; if you’re making a printed book, you need to know exactly how many pages it’s going to be, because that will affect your production, profit margins, and the like. If you’re crowdfunding the project, practical restrictions may look very different from a project you’re funding up-front.
Setting Thematic Restrictions: Thematic restrictions are restrictions that revolve around the artistic ideals of the project. What are the ideas you want it to convey? What are its politics? What should this game ask a player, and what should it say to them when they answer? What do you want players to experience? The thematic restrictions you set should revolve around these sorts of questions.
While it might seem like practical restrictions are more concrete and thematic restrictions are more intangible, they’re equally important to define, and thematic restrictions are often the ones that are harder to change as a project progresses. In my experience, finding clever ways to get around a practical restriction is a lot easier than getting around a thematic restriction. If your game’s mechanics or flavor try to double-back around its themes, it’s almost always noticeable and distracting to players.
A vision document should clearly define a game’s practical restrictions as well as its thematic core. If you’re making a new game, you might not know how the mechanics express that thematic core, but identifying it is still vital.
Watching the Periphery
As you make progress in your design, you’ll sometimes spot things in your peripheral vision just beyond the edges of the cone you’ve set. If they’re interesting, they’re almost always worth noting, but you’ll have to decide on a case-by-case basis whether you should expand your cone to include them.
This is another case where your search parameters in the vision document is extremely helpful. Whenever can identify that you’ve strayed outside of them, you know that you’re choosing to do something that is in some way at odds with the way you’ve defined your design so far. So you have three choices: you can walk away from the idea (perhaps noting it down for use in a future design), you can adjust your parameters of search to accommodate the thing you’ve found, or you can accept that it falls somewhat outside of your cone but is still worth including in the design.
The cone isn’t meant to be a hard line, but rather a tool for self-guidance.
Let’s look at one quick example of each:
Stepping Back Inside the Cone: Codename Lithotaph has had the thematic restriction of “Leave Your Mark” from the start – continuity between games is a key part of the concept. However, it has also had “strong visual table presence” as one of its practical restrictions from the start. Early in the design process, I delved deeply into the idea of a drawn map. This clearly fell within the thematic cone, but what about the practical? To find out, I played several drawn-map games such as Once Upon a Castle for comparative research, and while the games were a lot of fun, the maps I made in them never had the table presence we felt Codename Lithotaph needed. So after a quick discussion, we decided to go in a different direction for the map, marking out drawn maps as something for a different project.
Adjusting Parameters: Remember how I said some of the restrictions set out in the original vision document had already been adjusted? Yeah, as the design has developed, basically all of these have changed because Brendan and I have decided to revise what the game should be based on playtests. After our last test, for instance, we felt the mechanical complexity of the game was higher than originally projected but was justified, which necessitates reevaluating the components and cost.
Accepting a Detour: For accepting a design detour, I’ll need to turn back to an older game, since it’s too early in Codename Lithotaph’s design cycle to say much with certainty. Fortunately, I have lots of examples from X-Wing! When Alex, Frank, Brooks, and I were working on X-Wing 2nd Edition, we set our design cone with the parameter that we wanted to create more levers to pull as designers, to give ourselves and future designers as much space to make interesting new cards as possible. However, many fans have noted that X-Wing’s dice are quite simplistic in their outputs, especially compared with Armada and Legion. Nonetheless, we decided to leave the dice as-is, despite them being somewhat at odds with the overall philosophy of “lots of levers for designers.” Players were already used to the existing dice with their various strengths and foibles, many had dice from tournament prizes from past events or lovingly-crafted custom-made dice, and ultimately, we felt we had enough other levers to get by.
Practical Advice
So, what should your vision document look like? Ultimately, as long as it works for your team, the specifics of formatting aren’t that important. However, in my experience it pays to include the following:
Basics. These should include details like player count, game type, comparable products, and a (very) rough estimate of price point based on the components included and comparable products.
Overview. A brief synthesis of the game’s core appeal to players and gameplay flow in 1-3 short paragraphs. If someone reads only this part, they should understand what the game is about.
Core Themes and Features. This section should go into more detail about what the game is trying to express to players.
Mechanics Summary. A high-level explanation of the sorts of mechanics the game will use. This shouldn’t be a System Reference Document, just a quick run-through of the way you envision the game being placed. Will it use cards? Dice? Reference books? Miniatures? How will players interact with these elements and the ideas they represent?
Components List. A rough estimate of the components that need to be in the box for the game to be played (as you currently envision it).
Additionally, remember how I discussed that a vision document is a living document? This means that it should be updated when thinking about the project changes. Hmm, on that topic, how does my vision document look? Is it still in line with where the game is at? Uh…
I’ve got some updating to do!
I hope that this has been helpful! In other news, I’ll be taking questions about Codename Lithotaph, my design process, and anything else folks want to hear about from now until September 27th, so send me an email or hit me up over on Twitter if there’s anything you’ve been burning to ask me and it might show up on here in the coming weeks!