Getting to tangible, high quality conversations and iteration with your game engineers is a critical skill for game designers. Writing docs with a game engineer “client” in mind will boost your effectiveness and the ultimate quality of your games.
Communication is Everything
The key to design documents your game engineers won’t hate is doing the right work to start a conversation about building flexible tool sets.
Thinking in tool sets, and not just player experiences, has the added benefit of setting your game up for experimentation, rapid iteration, and live operations. The best game design tool sets will come from designers with a firm handle and appreciation for how games are built, who understand the experiences they want to deliver to players, and are eager to work hand-in-hand with their game engineers. Close collaboration between engineering and design is critical to efficiently building great game experiences for your players.
The Problem With Words
Early in my career, I wrote design documents that looked like this sample “novice” design doc. I developed several bad habits from working in environments where design documents were written in full, then thrown over the fence. Sometimes the receiver was on the other side of the office. Sometimes they were on the other side of the world.
My early design docs were very detailed. Excruciatingly so. But they were not conversations. They were filled to the brim with words an engineer had to sift through to understand the intent and system design they were trying to communicate. As you’ll see in the design document, this format puts a lot of work onto the shoulders of the game engineer. It requires them to decode what’s written and decide what needs to be built.
An Engineer’s Response
I sent the example novice design document to Damon Rocco, Director of Engineering for 100 Thieves new Project X, and someone who was on the receiving end of my novice design documents earlier in his career. Here was his response:
“There is a critical conversation point between design & engineering that should happen while creating requirements for the MVP. They need to negotiate what takes a lot of engineering time vs what is actually valuable for design to get their hands on. This document does not contain a requirements summary, or prioritization order, which makes me think the designer is not planning on having that conversation:
- This document is over-specified for an MVP. The 12th weapon isn’t going to make a difference in whether the game fundamentally ‘works’ or not. We can start iterating and ideating before that.
- The weapon/bullet data (re)uses vague terms (Light/Low, Medium, Heavy/High) for weapon properties, presumably all ‘Lights’ are not the same.
- I would prefer to see some example weapon data in a machine digestible format that the designer is comfortable authoring. Just send me the csv/xlsx!
- Rapid iteration works best with data-driven systems, and providing data in a narrative format raises red flags that the designer might not be comfortable/familiar with working in this way.
- ‘[paraphrased] I don’t know what modes there are because I haven’t unlocked them’ is… hilarious(ly bad) to see in an official design document.”
As you can see from Damon’s response, this document needs a lot of work in order to set the stage for a collaborative and efficient discussion with game engineers.
Getting To Conversation
Nowadays, I focus my energy less on lengthy documents and more on setting context and getting to conversation quickly. I start with a simple napkin sketch and single page explanation to set context. Then I move on to game data design. This spreadsheet is where I force myself to think through my design not using words, but using the data formats that will drive the game experience. This technical design exercise forces me to think about tool sets not experiences. I’m designing flexible lego blocks and making sure they fit together to deliver the player experiences I want.
The goal of good design documentation is not to make all the perfect decisions ahead of time. There are plenty of questionable choices and areas for improvement in the sample configuration design. But the materials provided – the configuration, sample data and user stories – all allow a designer to quickly get to a high quality conversation with a game engineer. It communicates with the game engineer in a format much closer to how they think about building game components. This is the start of a good conversation.
An Engineer’s Response
After reviewing the new, more mature game design materials, here’s what Damon had to say:
“Overall, these materials make me feel like a partner who’s time is respected. I anticipate that the initial kick-off/planning meeting will be productive because the design team has already put a lot of thought into what they would like to build and how they would like to work:
- The one pager is clear, concise, and professional.
- Most stories start with “A developer can…” which makes it clear that design will be leading the iteration process using data, and it will be engineering’s responsibility to provide them the tools and underlying functionality they need.
- The example configuration data shows me how the designer(s) are planning to interact with the systems, and be helpful for guiding discussions about how things should work.
- This data also looks like it is intended to be plugged into the system directly, I don’t see any vague/non-numeric values for internal systems.
- ‘To kick off our design discussion’ is the phrase used to introduce the configuration data and tasks; This makes it clear that a conversation about functionality and prioritization is expected/welcome.”
In short, this set of materials better sets the stage for discussion, collaboration and iteration between design and engineering. It is a set of design materials focused on teamwork, not task assignment.
Why It Works
This design method – set context, create sample data, explain it with user stories – is much faster to produce than a thoroughly detailed word document. It forces me to design tool sets in a flexible way, and think through my sample data to make sure what I’m asking for will produce the desired result. It also reveals interesting ways that these lego blocks can be used, if properly implemented, to create player experiences that were never designed up front.
As a designer, the key to success is thinking about how to communicate with your game engineer, not how to give them a list of tasks to mindlessly implement.
The design materials provided here are not complete. They are a first draft. They are an attempt to communicate a design with a game engineer concisely, in a method that is familiar to them. By focusing on the needs of the “client”, this method allows a designer to set the stage for fruitful collaboration with their game engineers.
Ethan Levy is a 20 year veteran game designer, producer and monetization expert, having worked on over 80+ shipped games across every platform and business model. He is Deconstructor of Fun’s resident Crypto Kid, and is on the hunt for a Technical Director to help him build the next, great Web3 games studio. If this sounds like the right next adventure for you, reach out on LinkedIn.
