CO1301: Games cepts 2016

1. CO1301: Games cepts 2016 Lecture 3 Game Design Documentation Dr Nick Mitchell (Room CM 224) email: npmitchell@uclan.ac.uk Material originally prepared by Laurent Noel & Gareth Bellaby

2. Lecture Outline • Introduction • Design Document Structure • Game Overview • The Game World • Characters • Objects • UI Definition • Play Modes • Appendices

3. References • Rabin, Introduction to Game Development: • 7.1: "Game Production and Project Management" • Rollings & Morris, Game Architecture and Design: • Chapter 12: "Milestones and Deadlines" • Chapter 13: "Procedures and "Process"".

4. Introduction • One process is: • Pitch document • Game Design Document

5. Introduction • A variety of different documents will be produced during the course of developing a game. • There is no one process: different companies will have different ways of doing things and different circumstances may call for different approaches. • Documentation has different purposes. Consider the different objectives that you may need to achieve, e.g.: • To describe the game for development • As part of a project management plan • To help secure a publisher deal • As marketing material for consumers

6. Pitch document One starting point for the process is a pitch document. It is designed to test interest, e.g. to attract funding or to gain approval for project within a company. The pitch document is the simplest form of design document.

7. Game Design Document A commonly used phrase is the Game Design Document. Typically abbreviated to GDD. The GDD is not directed at the player but at the people who are going to make the game. The GDD may be the document from which the game is to built. The GDD is a design document. It is not a storybook, game manual or advertising. The company may also produce a Technical Design Document (TDD) which is more detailed and used during actual production.

8. GDD Examples A design document template has been created by Chris Taylor of "Dungeon Siege" fame. Sourced from http://www.runawaystudios.com/articles/chris_taylor_gdd.php Example of GDD by Chris Bateman of International Hobo, called "Design Document: Play With Fire", http://www.gamasutra.com/view/feature/1709/design_document_play_with_fire.php There is an example game design document at the end of Rollings & Morris, Game Architecture and Design: A New Edition. Tzvi Freeman, "Creating a Great Design Document", http://www.gamasutra.com/view/feature/3224/creating_a_great_design_document.php

9. Part 1: Design Document Structure • The detail needed for development includes: • Game Overview • Background • Game play description • The Game World • Levels / Key Locations • Progression / Travel • Characters • Player character(s) • Non-player characters (NPCs) • Character attributes • Character abilities & development

10. Development Documentation 2 • Continued… • Objects • Interactive world elements (e.g. doors) • Key Items (e.g. weapons) • Pick-ups / Inventory Items • User Interface (UI) • On screen display (OSD) • Controller usage • Camera / Point of View • Play Modes • Single Player – Full Story • Multiplayer • Appendices (Detailed lists, tables etc.)

11. Development Documentation 3 • Other development documentation that will be discussed later: • Audio-Visual Requirements • Models/graphics for world, characters and objects • List of animations for the above • Graphical User Interface (GUI) • Sound effects, vocals & text (& localisation) • Technical Considerations • Platform / hardware specifications • Rendering / 3D engine specification • AI requirements • Networking support • Game Tools

12. Other Documents • Project management documentation can be directly linked to a game design: • Development timescales • Asset management (people/code/artwork) • Budgets • When a design targets publishers or consumers you may include: • Unique Selling Points (USPs) • Show-reel / Prototype • Market research / Competitor analysis • We will not consider these aspects for now

13. Part 2: Game Overview • The game overview gives the background story and describes the basic game play. • You should make a clear distinction in the Game Overview between the Background (story, setting, character) and Gameplay (i.e. a description of the game mechanics. • It can be derived directly from the proposal document, but there should be more detail. • Not too much detail though; refer to other sections in the document where appropriate • For example, when introducing a character in the overview, refer to the character section for a full description • Don’t include complex rules or tables etc. Such detail belongs later in the document.

14. Game Overview FAQ • The overview should answer these questions: • What is the game? • Where and when does the game take place? • Who or what do I control as a character? • How many characters do I control? • What is my character’s objective? • How will my character achieve the objective? • What threats does my character face? • What competition does my character face? • What help can my character find? • What game is the nearest comparison? • How is it different?

15. Part 3: The Game World • This can be one of the larger sections of the design. • It should begin with an introduction e.g.: • The criminal underworld of Perez City occupies an industrial wasteland between the glittering high-rises of the financial sector and the burnt-out slums of 3rd district… • The Pacific Rim Rally circuit takes in eight dramatic stages from the bleached-white sands of Hawaii to the gravel-strewn volcanoes of Sumatra… • These introductions should be compelling as well as descriptive.

16. Levels / Key Locations • Next, each level or key location should be described in detail. • Some games have very large environments with many areas rather than single levels • Describe the different areas in each environment • In some games location is not relevant, e.g. board games. • Still try to describe the visual environment of the game if possible. • The scale of each location should be indicated (e.g. 1km square, 2 blocks of a city)

17. Progression / Travel • Describe how the player progresses / travels through the levels / locations, e.g.: • By reaching a target position • By defeating all the enemies • By achieving other conditions (describe them) • Can simply walk from area to area • If progression from area to area is complex and limited by the storyline, it may be better to describe it as part of the full story later.

18. Part 4: Characters • Open this section with an in-depth profile of the key player characters, e.g.: • Jack Travis trained as a bare-knuckle boxer in ’50s Chicago… • The Lotus Elise is a small, light and agile sports car, ideal for novice racers… • Next, describe any other key characters that can not be controlled by the player. • Some games do not have specific characters, but types of character instead (e.g. archers, battleships). • Describe the player / non-player character types.

19. Character Attributes • Characters in the game will have particular attributes depending on the game genre: • Speed, acceleration… (Driving) • Strength, Skill, Morale… (War) • Age, weight, fighting style... (Beat ‘em up) • The attributes needed for characters in the game should be identified. • You should give actual values for the key characters. • This section can be combined with the previous. • Choosing a good attribute set is important to balancing a game.

20. Character Abilities & Development 1 • Characters may have innate abilities that they can use in the game. These should be listed. • Character development describes any change in character attributes or abilities due to experience / objects gained in the game. • Abilities and development can be very varied: • A wizard starts with a limited set of spells, and acquires new ones with experience and by reading books. List the basic & full set of spells. • A football team may have an initial set of ‘special’ passes and shots. They gain more with experience and funding. List the basic set of moves and the full range of new ones.

21. Character Abilities & Development 2 • Ensure you give all the required detail for a character development. How much experience is required, what objects, etc. • It is a good idea to give an overview of the character development in this section and then provide detailed tables in an appendix to the document. • For the wizard example, provide a selection of spells and descriptions in this section and a fully detailed table of spells, requirements, effects etc. in an appendix. • This is another critical game balance section.

22. Part 5: Objects • Objects may range from keys to buildings - anything with a distinct game-play function. • Categorise your objects into different types: • Key Items, e.g. the weapons in a FPS, the main building types in an RTS. These are central to the game-play, and need to be described carefully. • Inventory Items / pick-ups, e.g. keys, food, power-ups, armour etc. If there are many, give a short list here and a full list in an appendix. • Interactive environment elements, e.g. moving spikes, special platforms, ramps etc. Don’t include things that animate but have no special purpose. • Finer categories are useful if many objects.

23. Object Attributes • Objects usually have attributes just as characters do. These need to be detailed along with the object description. • Some examples are: • Strength, power requirement etc. for a building in an RTS. • Range, Ammo type, clip size for weapons in an FPS • Health gained for food / med-kit / potion • Damage dealt by spikes / toxic waste

24. Managing Detail in a Design • The game world, character and object sections of a design can contain a great deal of information. • A full design needs detail, but it should still be readable. Some tips: • Move large lists or tables of detail to appendices. • If necessary only detail a few example characters / objects in the main document – choose examples from early in the game. • Write designs on a computer, designs are often updated and paper based work can become messy very quickly.

25. Part 6: UI Definition • The UI of a game has three components: • The On Screen Display (OSD) • The camera / viewpoint. • The controller interface • You should justify your choice of OSD and compare it to other games. • However, do not simply copy an OSD design, especially if your game is innovative. • We will cover camera / viewpoint issues in another lecture.

26. OSD / Camera Mock-up • The OSD describes the things shown in front of the main view of the scene. • You must draw a picture of your OSD, including: • Cursor / Target • Critical information, e.g. health, ammo etc. • Control and status icons • This can be combined with a mock-up showing the camera view.

27. Controller Interface List the different controller methods the game can use. An sample controller layout may also be given. With a mouse / icon method, combine this section with the OSD. Identify any unusual control decisions. You must justify a complex control scheme.

28. Part 7: Play Modes • This section details the various single and multiplayer game modes. • Also the variations for each mode, e.g. • Single Player: Story mode, Timed Levels, Puzzle Mode, etc. • Multiplayer – Deathmatch, Capture the flag, etc. • Explain the differences between each variation. • Also this section should list: • Initial settings that affect the game-play rules. • Hours of game play for single player modes.

29. More Play Mode Detail State if there will be a way to save the game in progress. Also note if there will be any restrictions on game saving In a story-driven game, use this section to tell the story of the player as they progress through the scenes. Identify the conditions for progressing through each story section.

30. Multiplayer • Having multiplayer support in a game is a valuable asset. Describe it here. • Consider if there is any way to design some kind of multiplayer support even for non-standard games. Consider: • LAN / Internet multiplayer • Split-screen play • Single screen battle or co-operative modes • MMORPGs (Massive Multiplayer Online Role Playing Games) have many specific design considerations. • We will consider these later in the course.

31. Part 8: Appendices • Use the appendices to remove detail from the main document. Here are some examples: • A list of 30 spells, with their casting requirements, difficulty level and detailed effects. Some individual spells may need further tables of detail. • A list of 25 cars with engine, drive-train and suspension specs, and available upgrades. • For a fighting game, a list of all the moves for each character split into categories (e.g. high punch, low block), each move is also given attributes. Then a combat table stating the outcomes of all the combinations of attack / defence.

32. Other Appendix Information • Although not necessary, here are some other appendices you may wish to add: • Graphics / Animation lists • Sound Effect / Vocal lists • Music requirements and style • Future directions (ideas for the sequel) • Historical Notes (e.g. for a war game) • References (if you use any external content)