Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Get the latest Education e-news
 
  • So You Want to Be a Game Designer

    [09.15.06]
    - Marc Mencher
  •  Creating a Design Document

    To be a game designer, you need to understand the fundamentals of the design document. Just as a blueprint aids the construction of a house, a design document shows where every element of a game fits into the larger picture. Because there are just as many ways to produce a design document as there are ways to write a book, for the purposes of this article, we’ll use a relatively basic and familiar format. Don’t panic at the detail; this is just to familiarize you with what you’ll tackle in your professional life.

    First, before you even sit down to draft a design document, you must ask yourself, "Who will be reading this?" If this is a document to sell your idea to a marketing staff, or to get funding, then you might focus on shorter explanations of technical subjects and move the meat and potatoes to the beginning of the document.

    Also, before the actual design document drafting begins, you need to have had creative meetings and a pooling of all the best ideas, design notes, and diagrams that will make up the game play and look of the product. Don't worry if everything is not nailed down in minute detail; that will work itself out once you reach the assignment stage. Just get all of the key elements down, including your “killer aps,” or "that which will make this product stand out in game play, looks, and feel." Killer aps (for “applications”) are critical to the overall success of your product, and it is where you will spend most of your production time.

    Your pre-drafting compilation should also include any conceptual art. If you don't have any, you should definitely consider having some made. One of the key responsibilities of a designer, producer, or manager is keeping the team focused on the vision of the game. Because the art staff on a project tends to make up almost two-thirds of the production team, visual aids such as conceptual art and storyboards are critical to getting the art staff excited and motivated.

    The following is a breakdown of the different subjects used to outline a typical design document. You may want to add or remove subjects that are not applicable to your particular concept design. For example, if you are making a puzzle game, then the idea of a player or monster character may not fit into the design.

    Title Page and Copyrights. A title page for a design document is very important. It will be seen often, so avoid a title name or a font format with which you are unhappy. Certain copyright and trademark information must also be presented for you and/or your company’s legal protection.

    Table of Contents. This gives the reader an overview of what is contained within the design document, including page numbers. From the designer’s standpoint, it becomes very useful in helping him or her see how all of the subjects in the design flow into the overall structure of the product design. This information should be kept simple, to the point, and very easy to read.

    Production Mission Statement. A mission statement is a relatively concise, often one-page description of what you want this product to accomplish for the company. It should include such items as the theme of the product (like action or puzzle), the style of the product (like 2-D top-down shooter), style of game play (perhaps it plays like “Tomb Raider” or “Zelda”), character art style (like cartoony or realistic), background art style (like dark fantasy or sci-fi), target age group, target rating, target platform, special hardware (like a light gun), minimum hardware requirements, estimated production team size, and scheduled completion date. Also, include a short list of no more than three competitive products that are on the market making certain that you explain your edge over these titles point by point.

    The Game Concept Overview. If you had only one page of text to get across all of the key points that make your concept great and sellable, what would you include? It’s almost like a sell sheet that the sales and marketing department would use to promote the game. Don't get overly technical. This is the section that most marketing and sales people will review, and you don't want to scare them off with techno-babble. Also, don't omit how you came up with the idea and why you picked it as your production goal. You want to bring the skeptics around to your way of thinking.

    The Game Back Story. Although the back-story for a product is often fluff, it helps to bring your team into the world you envision.

    The Product Flowchart. This is a handy device to demonstrate how all of the big elements fit together to make the product. In this section, you simply walk the reader through each stage of the start-up interface, all the way down into the game, and back out to all possible endings, making sure to show how each section branches off to the different options. Don't worry about the level-by-level and bonus section stuff just yet. That will come in the next section.

    The Game Play Flowchart. Here you walk the reader through each playable stage of the game, including all possible branches and sub-endings. Make sure to list all the levels out by name or number. This helps avoid confusion during production.

    The Game Interface. The typical video game interface has several primary functions, including introducing the publisher and/or developer, informing the public about the copyright/trademark status of the product, presenting a pre-rendered or pre-animated or static story that leads the player into the game, and giving the player the lead-in options for the game (such as Start or Options or Difficulty). Also, the interface displays an ongoing status of the game while you play, it presents the player with special rewards for goals achieved, and it explains the punishment for failing goals.

    Game Play Overview. This is where you walk the player through the product's play experience. For example, here you would list out Levels 1, 2, 3, and so on, making sure to explain where the level is in the game, and what elements make up the game play for that world. Also, don't forget to add notes on what the level might look like; this will give the art team a starting point.

    The Player Character. Here is where you explain all of the things that make up your player character, including looks, abilities, and limitations. Ideally, in this section, you find the conceptual art for the player character along with a description of moves that may range from a simple walk to a back flip. It should also contain special acquired abilities that the player character can pick up from any number of sources during the game. You also want to include the player character’s combat and defensive abilities, the type of weapons the player can use, whether the player will take damage from fire or sharp objects or other items, and what the player character’s reaction will be when being hit by, say, a monster.

    Game Controls. Provide a drawing of the game controller or keyboard. Be sure to note whether the controls might be changed by the player prior to or during game play.

    Game Characters. This is where it gets really fun, where you get to create all of the great monsters and other characters for your game.

    Game Pickup Items. What pickup items will the player encounter and collect during game play?

    The Game World Design. Here’s where you list—in level-by-level style—all the topics that make up each stage of the game. For instance, include things like a description of any lead-in CG cinematic to the level, general description of the level, description of ground-based gameplay, notes on any land-based or sky-based level animations required, what story characters are located in the level, and anything else you can think of. Then just repeat this section for each of the levels in your design. It’s a great idea at this stage to sit down with some of the programmers and work out what they need to know about all the elements that will make up the game. A successful design document must be usable by designers, programmers, and artists alike.

    Music and Sound Effects List. This has a number of important uses, including costing the work out. Also, it is important to list in order of need so the music and sound contractors know what to deliver first.

    Engine Overview. List information from your programming staff on what the game system and engine can and can’t do. If needed, prototype to learn the limits and set realistic guidelines for your project. Include such things as the number of characters you can have on the screen at once, how many animations there can be per character, any camera and game view restrictions, how may polygons can exist per level and character, and the number of colors per texture map. All of this information will be crucial for the designers and artists who need to know as much as possible before starting to work.

    Once the design document is completed, you can move on to produce the production schedule for the game. Without a design document that outlines everything we’ve discussed—and more—a production schedule will not hold and, in the end, the game and/or the budget will suffer.

    So, still want to be a game designer? As you’ve learned, the job requires much more than simply coming up with cool game ideas. It’s about efficient organizing, effective communicating, and, above all, excellent writing.

    Marc Mencher is a specialist in game industry careers who has helped thousands of jobseekers land positions with the hottest gaming companies. Before founding GameRecruiter.com, he worked for such game companies as Spectrum Holobyte, Microprose, and 3DO. Marc is the author of “Get In The Game!”—an instructional book on careers in the video games industry.

Comments

comments powered by Disqus