1. Game Design Vishnu Kotrajaras, PhD
Design Document
Game Design
Vishnu Kotrajaras, PhD

2. What is it?
It is a way to communicate your detailed ideas to all team members.
Concept
Target audience
Gameplay
Interfaces
Controls
Characters
Levels
Used by everyone needs it to do his/her job as best as he/she can.

3. What about focus? Need that one too.
It’s hard these days to start production without a detailed design document.
Designer need to write and maintain the document throughout production.
Remember, you must still talk and hold meetings.

4. Without it Everyone may interpret the game differently.
Art can’t be used.
Gameplay not represented in the levels.

5. Creating it
Work with every other member of the team to make sure that the areas of the document affecting their work are
Accurate
Achievable
pages (longer, and people will not read)
Labeled, so busy member can find areas related to them quickly.
If need expansion, do a sub document (only give this to affected people).

6. Contents No formula, but usually
Overview and vision statement
Marketing and legal information
Gameplay
Characters(if applicable)
Story(if applicable)
World(if applcable)
Media list
There may be technical detail , but this usually is put in a separate technical specification.

7. tips
Don’t write it until you’ve built and playtested a working prototype.
Keep updating it as you go through the development process.
Must organise your document well, so it can be updated easily.
And it is easier for a person to find what he’s looking for.
Fill out sections as they become clear.

8. Example (this is a guideline only)
Design history
Version 1.0
Version 2.0
Version 2.1
Vision statement (totally1-2 pages)
Game logline: describe your game in 1 sentence.
Gameplay synopsis: describe how your game plays and what the user experiences (keep it short). You should include
Uniqueness
Mechanic: the core play mechanic
Setting: your world
Look and feel

9. Marketing information
Target audience: age, gender, geographic location.
Platform: what? And why?
System requirements: what and why?
Top performers: list other top selling games in the same market
Sales figure, release dates, sequels, and platform, as well as brief descriptions of each title.
Feature comparison: why would a consumer purchase your game over the others.
Sales expectations: estimate the sales for each 4 months
How many would be sold globally?
How many would be sold within key markets?

11. Legal analysis: copyrights, trademarks, contracts, licensing agreements.
Gameplay
Overview: tie directly to your prototype.
Gameplay descriptions: detailed description of how the game function.
Controls: map game procedures and controls.
Interfaces:
Wireframe for every interface the artists will need to create. Describe how each wireframe functions.
Put detail on every state of the interface.
Rules: define all game objects, the behaviours, and how they relate to one another.
Scoring/winning conditions

12. Modes and other features Levels: detailed design of each level.
Flowchart:
Create a flowchart showing all areas and screens that will need to be created.
Editor: describe the necessary functions of level editor and details on its functionality.

13. Game characters
Character design: describe game characters and their attributes.
Types: PC
NPC
Monsters and enemies
Friends and allies
Neutral
Other types
Guidelines
Traits
Behaviour AI

17. Story Synopsis: summarise story in 1-2 paragraphs.
Complete story: outline the entire story.
Structure it so that it unfolds as the game progresses. Write like a player’s guide.
Backstory: good to have for references even though it may not make it into the game.
Narrative devices: describes various ways you plan to reveal the story.
Subplots: describe each subplot and how it ties with the main plot.

19. Profession system in World of Warcraft
cooking
tailoring
skinning

20. The world Overview Key locations Travel Mapping Scale Physical objects
Weather conditions
Day and night
Time
Physics
Society and culture ??

22. Media list: list all the media that will need to be produced.
Also, create a file naming convention.
Interface assets
Environments
Characters
Animation
Music and sound effects

23. Technical spec: (prepared by technical leader, usually separate from the design document)
Technical analysis
New technology: describe new technology that you plan to develop for this game.
Major software development tasks: do you use engines? Or do you develop them yourselves?
Risks.
Alternatives: any alternatives that may lower risks and cost.
Estimated resources required: hardware and software needed for this development.
delivery
CD, Over the net, or wireless devices?
Describe hardware, software, and materials required for delivery.

24. Interface technical specs
Game engine
Technical specs
Design: features, details
Collision detection: how does it work?
Interface technical specs
Technical perspective of the interfaces, including the tools you plan to use.
Controls technical specs
Any specific input devices that require specialised programming?
Lighting models: describe what you require
Modes
Models
Light sources

25. Tekken is one of the first games on Playstation that uses light source.
Tekken 3 is the first game that supports rumble joypad.

26. Internet/network spec System parameters
Rendering system
Technical specs
2D/3D rendering
Camera
Internet/network spec
System parameters
Max players
Servers
Customization
Connectivity
Web sites
Persistence
Saving game
Loading game

27. See Godzilla document in the book
Other
Help menu
Manuals
Setup and installation routine
Appendices
Reference materials that do not belong to the main text of the design document.
See Godzilla document in the book

28. Starting to write? Make sure the prototype is good first.
Flowcharting the entire game.
See flowchart for Wheel of Fortune.
Make wireframe interface for every screens.
See sketches from Wheel of fortune.
Wireframe is a good communication tool because seeing picture is often clearer than words.
Expand flowchart and wireframe with bullet points in the document.

29. File format of the design document
Word
Web
Easy for everyone to access and update. You can easily post links to new sketches, builds, levels.
Not portable and not easy to printout.
Website can be difficult to code and maintain.
Wiki
Better to have weekly update (not more often than this because people will get bored)
everyone about the details of the change.

30. Work with the team to create each section
-> an example