Remember, the goal when writing a design document is to help provide a road map for the feature or system you’re working on. You need to explain to the readers what you are building, why you are building it, and what you need in order to build it. When I write a design document, I usually try to address the following:

• High level goal - What is this feature/system/puzzle/etc. supposed to do? What kind of experience do I want the player to have?
• Reaching the goal - How to break the high level goal down into a set of rules and expected behaviors to achieve that goal
• Needs to reach the goal - What is needed from the stakeholders to reach the goal? Engineering for A, VFX for B, animations for C, environments for D, and so on.
• Minimum Viable Product - What is the least amount of work needed to prove out the design? What is most important to this design and must be done first? What are the stretch goals and nice-to-haves?

Let’s dig into this with an example. Imagine that I’m working on a looter shooter and I’m designing a new feature to extend the lifespan of player gear and allow more player customization of specific weapons they favor. Let’s call this hypothetical system the Weapon Inheritance feature.

High Level Goal

ALT

As a player, I want to be able to keep using my favorite weapon and dislike it when I have to drop it if I find another weapon that has better stats. I would like to be able to use new weapons I find to upgrade my preferred weapon to keep it relevant.

Reaching the goal

ALT

Weapon Inheritance is a means by which players can transfer bonuses from one weapon to another. Weapon inheritance will require the player to bring two weapons to a weapon modification station - one they wish to consume, and the other they wish to upgrade. The player will be able to choose which bonus or ability/proc from the donor weapon to be transferred to the receiving weapon and be prompted with a confirmation dialog to proceed. Once the player confirms, the donor weapon is destroyed and the receiving weapon receives the selected bonus or ability. The number of bonuses and procs on a weapon should be capped by rarity, with six being the maximum. A receiving weapon with maximum bonuses for the rarity should require the player to choose one old bonus to overwrite. Some abilities should be unique to certain weapons, we should be able to mark them as “uninheritable”.

Needs to reach the goal

ALT

• UI Art - New UI screens weapon inheritance overview, donor weapon selection, receiving weapon selection, weapon diagrams and highlights
• UI Engineering - new screen flow from weapon modification station: confirmation dialog, weapon inheritance overview, donor weapon selection, receiving weapon selection
• UI Engineering - means of selecting a specific ability to transfer
• Gameplay/Itemization Engineering - Ability to set/copy over a specific bonus or ability on a weapon, including any randomly-generated stats
• Gameplay/Itemization Engineering - Ability to mark a specific bonus or ability on a weapon as uninheritable
• Gameplay/UI Engineering - hook UI confirmation to call the code to execute the transfer
• Server/Persistence Engineering - weapon changes must be saved to the database upon successful transfer

Minimum Viable Product

ALT

Must Haves:

• Weapon Inheritance accessible via Weapon Mod Stations
• UI flow functions to select required
• Max # of bonuses is rarity-enforced
• Bonuses are transferred/overwritten
• Donor weapon is destroyed
• Transfers are saved to DB

Stretch goals:

• Uninheritable bonuses marked in data
• Rarity upgrade/transfer
• Scaling costs based on number of prior upgrades/rarity

ALT

These are the fundamentals to explain to your teammates what you’re trying to build, how you’re trying to build it, and what you need in order to build it, and the minimum success criteria for it to be evaluated. It gives them the needed direction to get started with the work they need to do. You can apply these principles to many kinds of design ideas, and your ability to identify what resources and work are needed for those tasks will improve over time as you level up in your chosen field. You can also practice writing design documents like this for features in other games. Pick a feature and try to break it down into these four categories. The more practice you get in, the easier the doc-writing will become.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

• Short questions: Ask a Game Dev on Twitter
• Long questions: Ask a Game Dev on Tumblr
• Frequent Questions: The FAQ