The Design’s Main Page: Tip of the Iceberg

Your design doc will be made up of a single overview page linked to multiple detailed documents defining different aspects of the game.

The main page provides a high-level overview of the game concept as well as links to increasingly specific parts of the design. The main page should provide enough information for a stakeholder to quickly understand the game (at a high level) and its current status. Think of this as your high-level pitch in text/picture form.

Sections on the Main Page

Your main page should have the following information shown in easily accessible form. The goal here is to provide as much high-level information to the reader as possible, along with links to pages with more detailed information.

Working Title

Your game’s title communicates the gameplay and the style of the game. Don't be too attached to this title, as it may well change. At the same time, it's worth spending a few minutes coming up with something that evokes the central idea of the game you're creating.

Team Composition

List your team members and their areas of focus, if applicable. Keep this brief, and don’t get too hung up on big-sounding titles: just list the areas you are each working on in the game.

Current status

In a few sentences, state the game’s current status: is it still being designed, are parts being prototyped, or is the whole thing ready for greenlight for production? Is it on schedule? Are there significant issues worth calling out as part of general status?

This is most useful when you have stakeholders outside the team (supervisors, investors, nosy professors, etc.), or when you have remote teams (e.g., a separate art team) who have an interest in getting the current status at a glance. You should update this section frequently in such cases.

The status can also be useful even if your team is small and co-located, so that you make sure you are all in agreement about the project's current status, goals, and biggest issues. Calling these out clearly can prevent big problems from festering even in a small team.

A useful way to phrase this is as the game’s own Scrum report:

• What parts of the design are complete or have been reviewed?
• Which parts are being worked on?
• What if any blockers to progress are there
• What if any debt or major issues have arisen?

Concept Statement

In one or two sentences (“your game in a tweet,” or “a few words that create a question”) describe the most important aspects of your game. What is its theme and setting? What makes the game fun? How many players are there? Is it a quick pick-up game or a huge epic? Why would someone want to play the game?

Don’t try to cram too much information into a quick statement, but don’t leave out vital aspects of your game either. This can be a tough balancing act. Expect to spend some time iterating and polishing this.

Concept Paragraph and Unique Selling Points

Expanding on the Concept Statement, provide the reader with an overview of the gameplay. Briefly cover the game’s core loops, player progression, setting, look and feel, and any other aspects that are necessary to understand the core appeal of the game. Include links here to associated documents that contain more detailed loop diagrams and descriptions.

In particular, highlight your game’s unique selling points (USPs), sometimes also known as its hook: what are the things that makes your game fresh, intriguing, new, and worth someone’s time? Your game’s USPs must be clearly understood by you and anyone who reads the design docs.

In today's crowded market, you have to have a clear and compelling answer to the question: Why should I stop playing my current game and play this instead? That can be difficult and uncomfortable to answer, but if you can't come up with an answer that a potential player finds engaging and captivating, you are not ready to move forward with your game design and development.

You should have about three strong USPs. Just having one probably isn’t enough to make the game stand out; having more than four or five is too many for someone to understand easily – and probably points to serious scope issues with your game.

Be sure too that your USPs really are unique selling points. If a statement you want to make there applies commonly to other games as well (“player fights monsters!” or “the character increases in power as the game progresses”) that’s not a USP. Think through this carefully, and find what makes your game truly special.

A link to a current prototype, or even a video of a prototype, goes here once one exists.

Genre

While genre statements about the gameplay (“this is a bullet-hell platformer”) are helpful to calibrate what the game is and isn’t, avoid vague statements that don’t actually inform the reader (“this is a Castlevania-like game”) and that may hide lazy thinking about the details of the game’s design (if it’s “a Castlevania-like game” what exactly does that mean for your game?).

Note that single-genre games are often less interesting as the space has likely been well-explored. Genre hybrids or combinations can create interesting new angles on existing gameplay, but beware of a “something for everyone” design that contains multiple genres, as these often end up being a mishmash that’s fun for no one.

Target Audience

Who is the target player for this game? What other games might they have played? What is their age range or other relevant interests or attributes? What is the desired ESRB rating?

Note that if your answer to this question is “everyone,” you need to rethink it. “Everyone” is not going to be attracted to or play your game: who are you making this for?

You may want to briefly discuss the kinds of players you're aiming for, and then create and link to a more detailed page containing representative player personas that support the game's goals.

Player Experience

Who is the player in the game? What is the setting? How long does the game last? What is the fantasy or aspiration the game grants the player? What emotions does the player feel by playing the game? What are the major phases of the player’s experience in the game? (This section can link to “Player Objectives and Progression” and leave most of the detail to that part of the design.)

Key Moments

As part of the player experience, and to help others understand the design, briefly discuss a few “key moments” in the game. Typical examples include an initial positive experience in the first 1-5 minutes of the game; key struggles that must be overcome; and major victory, achievement, or resolution points the player experiences as part of their arc through the game.

You may want to provide a brief overview of some key moments on the main page, and then link to another page with more detail.

Current Target Platform (and any system requirements)

What is the first or current platform for the game – PC, web, tablet, phone, or something else? Keep this to the current target platform; leave off any “future” desired platforms. Note that aiming for more than one platform at the start is almost certainly out of scope: make the game work on one platform, and if it's successful there, then consider moving to others too.

Competition

What games are similar from the player’s point of view, or would compete directly with your game? Show their name, release date, any revenue and budget information you can find, and a brief description of each. Also include a brief description of what sets your game apart.

Keep in mind that having competition for your game is a good thing. It means players are already familiar with this kind of experience and are more likely to be interested in yours. If your game is truly like nothing else out there, you have a lot of work to do to educate players to get them to understand your game. You want your game to be original, but not so different that no one knows what to make of it.

With regard to your competition, your task is to differentiate your game from existing ones, particularly via your USPs. This is one reason your USPs must be meaningful from the player’s point of view. Saying, “my game is just like that big famous shooter, but in this game all the guns are purple” doesn’t really mean much. You need to show that you understand your competition – what they do well and what they don’t – and show how your game is similar but not the same, and how those differences are meaningful and exciting to players.

Art, sound and music

This section contains high-level information and examples about the visual and auditory style for the game, as well as links to more specific information. The high-level information here includes reference and concept art (and where possible, music) to give the reader a quick idea of the visual style and tone for the game.

A separated (linked) doc, usually in the form of a spreadsheet, delineates all known art and sound assets that are needed for the game. This includes all user interface assets, animations, environments, characters, etc, in complete detail.

Monetization

If the game is “free to play” or has in-game purchases, these need to be wholly integrated with the rest of the design. This section provides an overview of the monetization philosophy and the major systems. It is heavily linked with the systems and features section.