Archive for September 7th, 2010

September 7, 2010

Game Design Documents – Getting the impossible underway.

It’s now hit the glorious month of September. The weather here in Shanghai is becoming bearable (humidity is not my friend) and graduate job applications are beginning to open! Yes, the lord giveth and the lord taketh away.

The main point of this blog is to work as a diary and semi-portfolio of my work in game design. The ultimate goal is to get into a game development company back in the UK, starting from September 2011 (that’s when grad schemes begin). Therefore this point of the year signifies my 1 year deadline. While I obviously have to impress companies before I get offered the job, I’ve still set myself the deadline to finish my game by September 2011. As I was thinking about this target, and my complete lack of art, coding and testing ability, ‘impossible’ came to mind.

My current company is employing a small team and wants a game released from concept to execution in 4 months. These 5+ people have skills, they know how to make certain visual effects using Photoshop. They know ActionScript and they have the resources to test their games. 5 people, with knowledge, will be taking 4 months to complete. I am 1 person. I have no knowledge. Actually that’s not completely fair. I can use graphical software at an intermediate level, not Photoshop though… I hate it. I use Adobe Fireworks (formerly Macromedia). I’ve designed logos which have been used professionally, and I’ve designed interfaces and websites with my current skill set. Therefore I’m not too worried about menus and the user interface of my game. Creating models and effects on the other hand…


ActionScript 3 - My potential new language


During this year I will be teaching myself ActionScript from scratch (I think… more on that in an upcoming post), albeit with a slight background in Flash animation. I also want my game to have multiplayer functonality, so I’ll have to teach myself how to connect multiple players to my game through the internet. All this, in 12 months.

Impossible does seem to be the correct word to describe this, but my god I’m going to try!

So how do you start? How do you begin creating a game, from scratch? Fortunately I don’t need to impress investors, I’m doing this for free and for no-one but myself. Therefore I can make the game I love. However, I want this to be as professional as possible, so I’m going to do things properly. That begins with a Game Design Document.

Being the novice that I am, I had to Google the term to find out exactly what I have to do.

The first link I clicked was ‘The Anatomy of a Design Document, Part 1: Documentation Guidelines for the Game Concept and Proposal‘ by Tim Ryan on Gamasutra. This article is 11 years old, but I doubt the process has changed much (except perhaps a focus on social networking features which has emerged since then).


The purpose of design documentation is to express the vision for the game, describe the contents, and present a plan for implementation. A design document is a bible from which the producer preaches the goal, through which the designers champion their ideas, and from which the artists and programmers get their instructions and express their expertise.”

Tim Ryan, Gamasutra


The key things to pick out of this are; goal, ideas and instructions. Ryan goes on to explain the benefits of guidelines to a design document, saying;


Elimination of hype. Guidelines eliminate hype by forcing the designers to define the substantial elements of the game and scale back their ethereal, far-reaching pipe dreams to something doable.

Clarity and certainty. Guidelines promote clarity and certainty in the design process. They create uniformity, making documents easier to read. They also make documents easier to write, as the writers know what’s expected of them.

Guidelines ensure that certain processes or procedures are followed in the development of the documentation – processes such as market research, a technical evaluation, and a deep and thorough exploration and dissemination of the vision.

Ease of drafting schedules and test plans. Design documents that follow specific guidelines are easy to translate to tasks on a schedule. The document lists the art and sound requirements for the artists and composers. It breaks up the story into distinct levels for the level designers and lists game objects that require data entry and scripting. It identifies the distinct program areas and procedures for the programmers. Lastly, it identifies game elements, features, and functions that the quality assurance team should add to its test plan.

Varying from the guidelines. The uniqueness of your project may dictate that you abandon certain guidelines and strictly adhere to others. A porting project is often a no-brainer and may not require any documentation beyond a technical specification if no changes to the design are involved. Sequels (such as Wing Commander II, III, and so on) and other known designs (such as Monopoly or poker) may not require a thorough explanation of the game mechanics, but may instead refer the readers to the existing games or design documents. Only the specifics of the particular implementation need to be documented.”


From reading this, I can see the most important benefit to me (as an individual and not a development team); “Design documents that follow specific guidelines are easy to translate to tasks on a schedule”. Even though I’m not organizing a multi-functional team of artists, coders, producers and designers, I am in need of some structure to my project. As a complete novice, I could come up with what I think would make a good design document, but I’m sure there are important things I’d miss if I didn’t seek outside information on the process. Planning is good, so I intend to make a good plan based on the structure of my design document.


Time to fill this up!


Ryan begins with a Game Concept Document, which is used to persuade the Product Design Manager to take the idea past a concept, to explore the possibility of creating the game. He details that a concept document should have;


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.”


I believe my first goal will be to complete this concept document before moving onto the next stage. I’ve had a concept in my head for months now, so I’ll get it written down properly and post it on the blog.

Before I leave you for today, I also wanted to link to “The “Core” of a Game” by Brenda Braithwaite on her blog Applied Game Design. I will also be using the advice given in this article to help establish the key features of my concept document. It’s interesting reading so please give it a look!