Play to the Crowd

Game Design

Adapting your design doc for different readers

One major challenge that Game Designers face when working on design documents for new games, or for new features, is writing them with a particular audience in mind. I’m not talking about the target audience for the game itself, but about other stakeholders who will be reading the document: Artists, Engineers, Producers and publishers — not always in that order of priority.

In fact, it’s not unthinkable that you’ll find yourself writing the same design document over and over again multiple times: first, you might write something high-level aimed at informing or getting feedback or approval from a publisher, then elaborate on the details for the benefit of your Producer, and finally flesh out the design to make it implementation-ready for Engineers, Artists, and Designers.

Being able to write for each of these kinds of audience is a skill that can be learned over time, from document to document, based on the feedback and questions asked about the designs, guidance from more experienced Designers, and… well… a lot of practice.

That doesn’t mean you can’t get a head start, though. Read on for some tips and general best practices for writing with these different audiences in mind! Does this align with your own experience? Let me know in the comments!

Writing for Publishers

When the primary audience for your design document is a publisher, or the equivalent of a publisher — like a third party with a lot of influence on how your game is made/shared with the world — you need to approach the task a bit differently to writing for other members of your development team.

Generally speaking, you should be writing high-level designs that highlight the important points of the game as a whole. The writing should be to the point and concise, laid out in bullet-point form and with few (or no!) distractions, side-notes, or anything else that might hamper you in getting your concept across.

While your Designer brain (or heart) might want to pile on the details to make everything super clear and leave no room for any misunderstandings, in this case you should reign yourself in! The publisher normally doesn’t need to know about the ten potential edge cases for a particular mechanic and their every possible solution. They normally don’t want to read page after page of plot details, background lore, and detailed descriptions of every single object in the game.

Instead, their focus is directed at the overall, big-picture stuff:

• Does your design align with the interests of your game’s intended audience?
• (If platform owner) Does it cover the platform’s default requirements for feature X, Y, Z?

They’ll also want to know the risk factors of the design, especially when it comes to…

• Anything that touches on real-life cultures and groups
• Conforming to the privacy laws and regulations of every region where the game will be published
• How it could affect the game’s age rating: You don’t want a game targeted at young kids to be unexpectedly rated 12+ because you included too graphic violence or explicit language.

By thinking about and covering these aspects in the design document from the start, we can help ease the game’s approval process and reduce the chances of friction in the working relationship between the development studio and the publisher.

Depending on the publisher — and the project — they might want more detail or less detail, but that’s something you’ll learn based on the feedback they provide, the questions they ask, and any potential requests they make for additional information.

However, working with external partners on third-party IPs can drastically change the picture here, as there’s a high chance they’ll want a say in anything that directly relates to their IP, requiring more elaborate approval processes, more iterating on designs (and art!), more meetings, and more reviews.

Writing for Producers

To some extent, Producers tend to think along the same lines as Game Designers when it comes to reading and interpreting design documents. (Chances are, a given Producer was also a Game Designer at some point in their career!)

They will compare the design to other games with similar implementations; they’ll attempt to poke holes in the design to see where improvements can be made, and they will pull at loose threads to see if the design unravels.

However, their primary focus will be on the product side, and with, y’know… producing:

• How long will this design take to implement? Does it fit into the allotted time in the production schedule, or does the design need to be adjusted/cut down to fit? Will there be enough time for QA testing?
• What kinds of resources need to be allocated to make it happen? How many Engineers can be spared, how much is on the Art team’s plate already?
• How complex is the implementation? Is this something the team has had experience doing before, or is it something completely new, with unknown factors that could affect implementation time?
• What potential impact does the feature/mechanic have when it comes to player retention, player ratings, player’s willingness to spend money on the game, etc.?
• What are the risks involved in this design, and how can those risks potentially be mitigated/avoided? Can the design be simplified to eliminate some of these?

As Game Designers, we can also make the lives of Producers slightly easier by keeping the below considerations in mind while writing our design documents:

• We can divide the design into logical sections/versions that can be considered (and implemented) independently of one another. Version 1 of the design includes X, version 2 includes Y, and version 3 expands on X and Y to provide Z.
• We can offer several levels of granularity so the design can be read both from a high-level perspective and from a more in-depth one. Depending on the tools used for writing the designs, this can be achieved by: colour-coding different sections of the text; using spoilers or toggles that hide extreme details for someone just wanting to skim over the document; using sub-pages; or by having dedicated sections that summarise the most important parts of the design.
• We can consult Engineers/Artists up front about the feasibility of certain aspects of the design, including what kind of effort would likely be required to realise them, and either include these estimates in the design or adjust the design accordingly.
• We can think about the potential risks of the design up front and provide our own initial thoughts on how to mitigate them.

Writing for Engineers

When the time comes to prepare your design documents for implementation, you’ll be writing with Engineers as your target audience. That means you need to think like an Engineer, seeking more detail, more thought put into edge cases, and more specificity about the needs of the design:

• What kinds of support tools are needed for the design, if any?
• What kind of format should be used to store data for use by Designers?
• What are the potential edge cases of the design, and how should they be handled?
• If the design of a multiplayer game says a shop timer should reset once every day, should it reset at the same time for all players globally or regionally, or should each player have their own individual timer, independent of others?
• What happens if a player has reached max level and gains additional XP? Should the game cap the additional XP, or let the player hoard it for later?
• If a player claims a reward but then closes the game or restarts before the reward animation/FX are over, what should happen the next time the player starts the game?

Don’t be shy: Engineers are detail-oriented by nature, and not being clear enough about how something should work will prompt them to ask more questions anyway, potentially even delaying the implementation if an answer cannot be provided straight away.

Don’t rely on them to figure it all out on their own, however. If details aren’t treated in enough depth, Engineers might implement the design based on assumptions made off the back of your vague design, in a manner you didn’t intend, and you’ll either be stuck with that implementation (if there’s no time to redo), or you’ll have wasted precious Engineer time that could have been put to better use — not to mention the time it’ll then take to redo the work in the “correct” manner instead.

Writing for Artists

It’s perhaps rare that you’d write a design document aimed at Artists alone, but invariably there will be sections of your document that are more important to your Art team than others. In order to allow them to accurately scope the work needed to support the design, you need to be specific about what you ask for:

• Instead of saying “The player will be able to choose from various different cosmetic options”, you might be better of going a bit more in depth: “The player will be able to choose between 10–15 different types of hats to wear. The hats will all be animated, and the player’s choice will be on display both in the main menu lobby and in-game, visible to both themselves and other players.”

The Art team can then scope out how much time and effort it would take to prepare the assets, which they can then adjust for when planning other work. Maybe they’ll get back to you and say “Sorry, in the given time frame we’ll only be able to provide X hats, and only Y animated ones — the rest will be static.” Then you can update your design accordingly, or negotiate with Art team/producer on how to get the most out of their time.

If a character ability requires a special effect to convey to the player what the ability does, the Artists might need to know details such as:

• Should the ability button itself have an effect, or should there only be an effect on the character?
• Does the ability have an activation time, and if so does should effect play from the start, only kick in once he activation time is over, or be separated into multiple stages, e.g. build-up -> activation -> lingering effect?

Being specific is also important when it comes to UI: For example, the UI/UX designer will need to know that the design requires buttons X, Y and Z, that button X brings up a popup with a confirmation dialogue, that button Y should be disabled under certain circumstances, and that button Z should cause an explosion of confetti on the player’s screen.

• The design doesn’t need to state where all these buttons are down to the exact coordinates of each pixel, but creating a simple mock-up on your own (Designer art is the best art!) can help get the general idea across and ensure that what the Artists deliver is aligned with what’s in your head.

Since the Artists will find information about these things more helpful than, say, the handling of edge cases surrounding match-making or detailed rules for how leaderboard resets affect player points, it can be a good idea to separate out art-specific details of the design document into their own sub-sections so that all relevant information can be found in one place.

But… What about writing for Designers?

You may have noticed I didn’t mention anything up above about writing for other Designers. The reason for that is quite simple: As a Game Designer, you should not be writing design documents targeted specifically at other Designers! Like yourself, those other Designers should already be capable of reading and grokking the essence of a design regardless of whether it’s written for an external third-party publisher or the Engineering team.

Even if your design is still in its very early exploration stages, when you’re still writing the outline of the design and you find yourself in need of some input from fellow designers on how to proceed with the design — you’ll still not be writing the design with those other Designers in mind.

At that point, you’ll effectively be writing the document for yourself so that you can fully get to grips with the design, and while this might make it easy for likeminded Designers to grasp its essence, they should still not be thought of as the intended audience.

You should already at this point start to think about who is going to read the design document, and about how you can ensure that the message you want to convey comes across as clearly as possible.

Well, that’s all from me. If you found any of the above tips helpful or insightful in any way, or if you have your own thoughts or best practices for how to write game design documents targeted at specific audiences, feel free to leave a comment below!

---

Play to the Crowd was originally published in Mighty Bear Games on Medium, where people are continuing the conversation by highlighting and responding to this story.