Gamasutra: The Art & Business of Making Gamesspacer
The Anatomy of a Design Document, Part 1: Documentation Guidelines for the Game Concept and Proposal

Printer-Friendly VersionPrinter-Friendly Version
View All     RSS
April 16, 2014
arrowPress Releases
April 16, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM TechWeb sites:


 
The Anatomy of a Design Document, Part 1: Documentation Guidelines for the Game Concept and Proposal

October 19, 1999 Article Start Previous Page 2 of 4 Next
 

Guidelines for the Game Concept

A game-concept document expresses the core idea of the game. It's a one- to two-page document that's necessarily brief and simple in order to encourage a flow of ideas. The target audience for the game concept is all those to whom you want to describe your game, but particularly those responsible for advancing the idea to the next step: a formal game proposal.

Typically, all concepts are presented to the director of product development (or executive producer) before they get outside of the product development department. The director will determine whether or not the idea has merit and will either toss it or dedicate some resources to developing the game proposal.

The director might like the concept but still request some changes. He or she may toss the concept around among the design staff and producers or open it up to the whole department or company. The concept can become considerably more compelling with the imagination and exuberance of a wide group of talented people.

A game concept should include the following features:

  • Introduction
  • Background (optional)
  • Description
  • Key features
  • Genre
  • Platform(s)
  • Concept art (optional)

Introduction: The introduction to your game concept contains what are probably the most important words in the document - these words will sell the document to the reader. In one sentence, try to describe the game in an excited manner. Include the title, genre, direction, setting, edge, platform, and any other meaningful bits of information that cannot wait until the next sentence. The edge is what's going to set this game apart from the other games in the genre. For example:

"Man or Machine is a first-person shooter for the PC that uses the proven Quake II engine to thrust players into the role of an android space marine caught up in the epic saga of the interstellar techno-wars of the thirty-seventh century."

Breaking the introduction up into several sentences for the sake of clarity is acceptable. Just know that the longer your introduction, the more diluted your vision will seem.

Background (optional): The background section of your game concept simply expands upon other products, projects, licenses, or other properties that may be mentioned in the introduction; so it's optional. The background section is physically separated from the introduction so that readers can skip it if they already have the information presented. But the background section is important for licensed properties and sequels and concepts with strong influences from previously released titles in the same genre. If you intend to use an existing set of code or tools or to license a game engine, then describe these items and their success stories here.

Description: In a few paragraphs or a page, describe the game to the readers as if they are the players. Use the second-person perspective -- "you." Try to make this section an exciting narrative of the player's experience. Encompass all the key elements that define the core game play by describing exactly what the player does and sees. Avoid specifics such as mouse-clicks and keystrokes, but don't be too vague. You want the readers to become the player's character. Hover your detail level right above the GUI interaction. You would say something such as, "You scan your tactical radar and pick up two more bogies coming up the rear," instead of "You click on your tactical radar button and the window pops up revealing two bogies coming up the rear." The description section should make the content and entertainment value of the game obvious and convincing.

Key features: Your game concept's key features section is a bullet point list of items that will set this game apart from others and provide goals to which the subsequent documentation and implementation should aspire. It's a summary of the features alluded to in the description. These bullet points are what would appear on the back of the game box or on a sell sheet, but include some supporting details. For example:

"Advanced Artificial Intelligence (AI): Man or Machine will recreate and advance the challenging and realistic AI that made Half-Life game of the year."

Determining how many features to list is a delicate balancing act. Listing only one or two key features is a bad idea if you're doing anything more complex than a puzzle game; listing more than a page of features implies that the project would be a Herculean task and may scare off the bean counters. Listing too few features might sell your concept short; listing too many waters down the concepts' strongest features.

Keep in mind that you need not list features that are given, such as "great graphics" and "compelling music," unless you really think such features are going to be far superior to those of the competition. Great graphics, compelling music, and the like are the understood goals of every game project. On the other hand, if the particular flavor of graphics and music provides your game with an edge in the market, then you should spell that out.

Genre: In a few words, define the game genre and flavor. Use existing games' classifications from magazines and awards as a guide. For example, you could choose one of the following: sports, real-time strategy, first-person shooter, puzzle, racing simulation, adventure, role-playing game, flight simulation, racing shooter, god simulation, strategy, action-strategy, turn-based strategy, side-scrolling shooter, edutainment, or flight shooter. Then you can refine your game's niche genre with these or other words for flavor: modern, WWII, alternate reality, post-apocalyptic, futuristic, sci-fi, fantasy, medieval, ancient, space, cyberpunk, and so on.

Platform(s): In a few words, list the target platform(s). If you think the game concept is applicable to multiple platforms, you should also indicate which platform is preferred or initial. If you intend multiplayer support on the Internet, indicate that as well.

Concept art (optional): A little bit of art helps sell the idea and puts the readers in the right frame of mind. Use art to convey unique or complex ideas. Screen mock-ups go a long way to express your vision. Art for the game concept may be beyond most employees' capabilities, so requiring it would limit the number of submissions; thus, it is optional. If a concept has merit, the art can come later from a skilled resource. Often art from previous projects or off of the Internet will jazz up a document. Just be careful with any copyrighted material.

Common Mistakes
Here are some common mistakes that developers make in creating a game concept:

  • The concept is totally off base or inapplicable to the company's current plans. If you don't want to waste your time writing up concepts that get tossed, find out what the company in question is looking for and keep an ear to the ground for opportunities with which your idea may be a good fit.

  • In terms of resources, the document asks for the moon. Try to keep your concept within the realm of possibility. Keeping the budgets down by suggesting existing tools or properties to reuse is helpful. Limit your ideas to that which can be accomplished in a timely fashion and with a reasonable budget. Limit experimental technologies to one area. Don't suggest revolutionary AI as well as a new, state-of-the-art 3D engine. If you are being solicited to produce the game concept, find out what the time frame and budget expectations are first.

  • The document lacks content. Simply saying, "It's Command & Conquer meets MechWarrior where you order your 'Mechs in tactical combat," is insufficient. Your description has to explain the actions that the player will perform and make them seem fun. A good description might read, for example, "You order your 'Mech to fire at point-blank range on the exposed right torso of the Clan MadCat OmniMech." This kind of descriptive content will help mitigate misinterpretations of the core game play that you envision.

  • The game isn't fun. A useful exercise is to break down all of the player verbs (such as shoot, command, run, purchase, build, and look) and envision how player performs each. Then, for each verb, ask yourself if it's fun. Then ask yourself if the target market would find it fun. Be objective. If the action that the player takes isn't fun, figure out another action for the player to take that is fun or drop the verb entirely.

  • The game-concept document employs poor language and grammar. Don't make yourself look like an ass or an idiot. Check your grammar and spelling and avoid four-letter words and sexual innuendo. You don't know who will ultimately read your document or whom you might offend with some particularly expressive words. Even the macho, politically incorrect, culturally insensitive, slang-using manager with whom you exchange dirty jokes over a beer at lunchtime can get quite sensitive with documented verbiage.

  • The designer gives up. Don't give up submitting ideas. You never know when one of them will take off. Persistence pays off, believe me.

Article Start Previous Page 2 of 4 Next

Related Jobs

Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States
[04.16.14]

Associate Producer - Treyarch
Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States
[04.16.14]

Production Coordinator (temporary) - Treyarch
Vicarious Visions / Activision
Vicarious Visions / Activision — Albany, New York, United States
[04.16.14]

Software Engineer-Vicarious Visions
Sledgehammer Games / Activision
Sledgehammer Games / Activision — Foster City, California, United States
[04.16.14]

Desktop Support Technician, Temporary - Sledgehammer Games






Comments


Anupam Biswas
profile image
Thank you so much for this article Tim Ryan.

David Oso
profile image
eh?

the GDD needs to include the proposal as well as the concept design documents?

why should they both be included in the game design document?

the concept design document is used to get the publishers attention, proposal is used to pitch your idea to the publisher. So I don't know why both must be included in the GDD again.



do they have to be included?

Aaron Pierce
profile image
Why wouldn't they be? The proposal especially. It's the basis of the game, the "this is what we're going for" document. It's the backbone that says "Hey, we're off target on this feature" or "that feature is spot on" during the development process. And the concept design art is such an integral part of the games design process that I couldn't see it NOT being a part of the GDD. Now, mind you, chances are it be a supplement to the GDD (a concept design Bible of some sort), but it'd be a part of it none the less.

Danny Breen
profile image
thanks tim, this has helped me quite a bit with my coursework!

Narasimmarajan K
profile image
informative...

Celmar Galindez
profile image
Well, expressive thoughts. This is an useful tool for novice who had never been in the industry. Simple yet well-spoken.

Timothy Ryan
profile image
Wow, this is really dated. I should rewrite it. :) Thanks, Gamasutra. I'm glad this remains available.


none
 
Comment: