Game Design
Game Design vs. Feature Design
Why one approach no longer rules them all
There’s no shortage of guides, tutorials, and other material in the complete annals of mankind’s collective knowledge (the Internet) that deal with how to become a game designer, and how to write game design documents. Countless resources are available to teach you the proper way to document your game idea, plus how to structure the different sections of the document, often with document samples or templates provided.
What I want to highlight in this article, however, is something I feel many of those how-tos often neglect to mention: that there are a few crucial differences between designing a game and designing a game feature. Read on as I attempt to provide you with some insights into this distinction and why it matters.
Chances are, as a fresh designer entering the game dev industry for the very first time, you will NOT be asked to write a design document for a game!
Unless you’re joining a small indie startup as the only designer on the team, it’s likely you will instead be asked to:
- Design a new feature for an existing game
- Come up with improvements to existing features
- Make balance adjustments (a topic worthy of an article all its own) to systems that might already be live and in the hands of players.
At surface level, the distinction might not yet be apparent, as you’d still be writing game design documents and putting your design skills to use. A design document is a design document, right?
The Traditional Game Design Document
To help further clarify the difference, let’s first take a step back and look briefly at the traditional game design document, the one most people (that is, most people aware of the existence of game design) associate with the discipline. Historically, these have been humongous “vision documents” or “design bibles” that outline in extreme detail all the different systems, mechanics, and features that make up a game, with everything from scripts, storyboards, game flows, mock-ups, concepts, and technical specifications planned out and prepared ahead of time before the game begins production.
Such documents had a tendency to become very long, difficult to read, and even more difficult to maintain, as they contained everything that in theory would be needed by artists and engineers to implement a game, and would be followed slavishly once the designs had been approved and signed off.¹
This style of game design document was the de facto standard in many studios and formed the basis for development of many legendary games released throughout the 1980s and ‘90s.
Some of those designs have since been made² available³ online, much to the delight of game designers and game archivists everywhere!
The Living Design Document
Over time, however, with project management and development practices shifting from Waterfall⁴ to Agile⁵, as well as game development becoming more modular and tools like Unity and Unreal Engine allowing for more efficient prototyping, the need for the extensive pre-planning that led to those huge game design “vision bibles” vanished. What took its place were living documents gradually written and improved upon throughout a game’s development cycle.
In fact, these “living” design documents now often act more like “concept documents”, written as low-resolution guides to help align a development team on the overall vision for a game, to present publishers with an overview of what the team is attempting to build, and to form the basis for production plans, milestones, estimated delivery dates, etc.
While this kind of document still outlines all the features needed by a game, the initial version no longer delves as deep into all the details, requirements, and edge cases for each specific system or mechanic. Instead, their fleshing-out is left as individual exercises for designers to take up at different stages of the development cycle, as needed and as dictated by the production plans and milestones and based on up-to-date information on what’s needed for the project at any point.
In some cases, this living design document might not even exist as a single “document” any more, but might sooner consist of a collection of documents, each one covering a different aspect of the game, like a specific feature, system, or mechanic.
The Feature Design Document
This brings us to the feature design document, which as a designer you will write with a high-resolution focus on one specific feature, whether it’s a brand new concept, a deeper dive into a feature listed briefly in the game’s overview, or an improvement on an existing feature.
Unlike the vision documents that focus on big-picture stuff for the entire game, this document covers all the information that artists, engineers, and other designers might need to actually implement a given feature. (Closer to the level of detail in old-school design documents, in other words!)
It’s common practice to document a feature from a hypothetical player’s perspective, explaining how the feature is ideally experienced and how it behaves under different circumstances and conditions (and why). Ideally, this means laying out all the requirements of the feature in a concise and easy-to-understand manner, while leaving the finer details of implementation up to the engineers and artists who will work on it later.
Depending on the practices of each designer and/or studio, the designer might also be responsible for coming up with their own UX flowcharts, and potentially also early UI mock-ups which can better convey the objective and purpose of the design to other members of the development team. In other cases, these might be passed on to specialised UX designers to create.
Either way, as the game designer writing this document you’ll be responsible for crossing all the T’s and dotting all the I’s. It’s up to you to make sure that obvious edge cases are handled, and that any potential design risks and concerns are called out and addressed by the team — preferably before they start the implementation phase!
Once the document is complete, has gone through the proper review processes and iterations, and is ultimately approved, it takes its place among the other documents that make up the living design document for the game, and the immediate focus (for the designer) can shift to the next feature!
TL;DR
The difference between designing a game versus designing a game feature is in the details. When designing a game, you’ll be focusing on the overall, cohesive design that ties all the game’s features together. When designing a game feature you’ll be digging deep into the bowels of said feature to pull out all the dirty details and expose them to the world (or at least your team members).
Game Feature Design Template
As a bonus, and in the spirit of game design guides everywhere, I’ll include a basic document template for writing game features. If you should find it helpful, don’t forget to clap!
Title — The title describing the feature.
Objective — Specify the player experience and goal of the feature in one sentence, without going into details on how to achieve that.
Summary — Summarise the feature in one paragraph, or in a few bullet points. This is often written after the rest of the design is ready!
Detailed Design — The nitty gritty of the feature: its details, how it works, and how the player experiences it. Divide this into several sub-sections if needed, but don’t leave anything out. Keep in mind that bullet points, diagrams, and mock-ups are superior to walls of text!
Design Risks — Highlight potential risks and concerns with the design and/or the feature itself, to be addressed by the team in design reviews, etc.
References — Good designers copy, great designers steal! Include any relevant references for the design here, be it articles, studies, screenshots from other games with similar features, etc.
[1]: The Anatomy of a Design Document, Part 2: Documentation Guidelines for the Functional and Technical Specifications
https://www.gamasutra.com/view/feature/131818/the_anatomy_of_a_design_document_.php
[2]: Game Documents. A collection of publicly released design documents for games and other related content
https://gamedocs.org/
[3]: Game Designs. Game Designs from some of Al Lowe’s adventure games from 1991 to 1998
http://allowe.com/games/game-designs.html
[4]: Waterfall model. A breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one and corresponds to the specialisation of tasks
https://en.wikipedia.org/wiki/Waterfall_model
[5]: Agile software development. Discovering requirements and developing solutions through the collaborative effort of self-organising and cross-functional teams and their customer(s)/end user(s)
https://en.wikipedia.org/wiki/Agile_software_development
