Design Docs

1. Design Docs With thanks to Jason Schreiber and Damion Schubert

2. A brief review:

3. IDEA • Simple version: IDEA  Realized idea delivered to “consumer” • What are the steps necessary to take a game from concept to completion • Here’s what you did so far:

4. Argue (Group Design) • You should have a long list of things you want to “build” for your game • How they will interact • Now comes the arguing. • This sucks, that sucks, you suck… (hopefully you were more descriptive) • End Result: group agreement on direction

5. Programming • What to code? What should “it” do? • Explore options – programmers and designers interact • good programmers can converse with designers to point out the error of their ways… POLITELY. “Cabal process”. • Big picture ideas. What’s cool. No, that’s not cool. Yes, it is. Wait, this would be cooler. What if it was like this? No, that!!!! • This is the “fun” part -- when it’s OK to say “Wouldn’t it be cool”. It is not OK to say this during development without consequences.

6. Production • Newsflash: everything needs to made. • We talked about the three pillars (art, design, computer) how does anyone know what to do? Production. • Write it down

7. Design Document • DETAILED document • ideally with illustrations • Leaves no doubts as to what the game will consist of

8. What’s in a typical GDD? • Deus Ex example. • How many referred to it while writing their GDDs?

9. Where’s Waldo?

10. Mechanistic outline of a GDD • Overview of the game: Give a short overview of what the game’s all about at first, to give a glimpse of the big picture without reading everything.

11. Mechanistic outline of a GDD • Complete rules of the game: Describe the mechanics of the gameplay. • By “Complete” we mean, “COMPLETE”

12. Mechanistic outline of a GDD • Game modes: If your game has multiple modes (single player and multiplayer for example, or Career and Quick Play) explain their unique characteristics.

13. Mechanistic outline of a GDD • The player characters: What can the player character do? How do he move? Does his health restore or drop over time? Explain everything needed about the main protagonist.

14. Mechanistic outline of a GDD • Enemies, weapons, collectables, power-ups, etc.: You need to describe pretty much everything interactive that will be encountered during gameplay. • What did you prototype? • What works? • What would be in the ‘alpha’?

15. Mechanistic outline of a GDD • Description of each level: Where is it located? What are the memorable events that occur? Any cutscenes or special events?

16. Part 2, TOC • Controls: Give complete mappings of the controls. • Story: Put in the whole story, as seen by the player. It may be a good idea to give this its own document if your game has lots of dialog. • Tutorial: How is the player introduced to the game? • Menu flow: Draw a flow-chart of how each menu page leads to each other. • Gameplay flow: Show how each part of the game leads to each other. Especially necessary if your game isn’t linear. • Saving & loading scheme: How does your game save and loads progress? Automatically? Manually?

17. Technical Design Document • Details every element that will be in the game (design document for engineers) • Every player action mapped out • Every bit of tech defined • Milestone chart • Memory map • UI Flow chart • Control diagram (mapping of console buttons) • Other uses: Beta Test, Marketing, PR, etc.

18. Storyboards and mockups • Smaller games (e.g., YOURS) – a good idea to storyboard or mock up every single screen • detailed description of each element on screen. • What tech used, what assets required, predecessor screen(s), destination screen(s), sound. • Very helpful production tool (gets everyone literally on the same page.) • Easier for GBA than large consoles.

19. give players powerful, general, intuitive tools • configurable battlefields • player-generated solutions

20. Would you rather read this: • Upon determining their weaponry and opponent, the player will enter into the arena and the real time, action oriented game play will take over. At this point, the game enters a first-person perspective facing the opposing gladiator. The player will see four specific pieces of information onscreen: • Health bar • Opponent’s Health bar • Concentration meter • Current amount of ammunition • The player will wait with his or her hands poised on the mouse and the keyboard. At this point an arena announcer will call out “DRAW!” With this, two things will immediately happen: time will slow down to half speed and the player’s Concentration meter will begin to deplete at a fixed rate. The Concentration meter represents the player’s ability to focus under pressure, represented by the slowing down of time. With this, the player has a limited amount of time to make one of two choices:

21. Or see this?

22. Contingencies • There is always something that happens • Personnel issues • Client mind change • Change of direction • Technology issues (oops, we can’t do that)

23. Your own roadblocks to writing a GDD… • “Design documentation is a waste of time” • “No one reads design docs.” • “My programmers find reviewing design documents a total time sink.” • This is probably a statement about your documentation, not a true testament of documentation in general.

24. Collaboration and Communication • All designers should want to share their ideas • All programmers (and other team members) should want to know what they’re building • This means: be specific

25. Goals when writing your GDD • Capture design consensus • Primary vision conduit between departments • Aid in scheduling • Offer focus • Give visibility to future dependencies and design conflicts

26. Keep it concise. • Short documents are: • Easier to read • Easier to write • Easier to maintain and keep up-to-date • Easier to handle politically • Less likely to be contradictory • More likely to be simple designs

27. How do you do this? • Kill the fluff • Kill empty sections • Kill ‘cut and paste’ stuff • Kill unnecessary text of obvious systems

28. Not keeping it short: • “The physics of DA is, for the most part, centered around a two-dimensional world, with the exception of the Flight upgrade. The projectiles from turrets follow a straight path, without being affected by additional forces such as gravity or wind. If a virus physically – from the player’s point of view – comes in contact with a projectile, that virus will take a certain amount of damage. The exception to this rule is if the player holds the Flight upgrade; the only projectiles that can damage viruses in this case would be those from the Anti-Air turret. All other projectiles will pass below the viruses. The straight forward upgrade system and the fact that DA is in 2D are what make gravity an unnecessary feature. It could possibly be implemented to add a visual factor to the range of the turrets’ projectile, or perhaps to provide for better animations of flying viruses, but the 2D restriction of the game would make these features very inefficient in terms of development time. Further, the end result would probably not add enough to the game to be worth it.

29. Better. • Movement in DA takes place in a two-dimensional world, with the exception of the Flight upgrade. The projectiles from turrets follow a straight path.” • Viruses are damaged when it comes in contact with a projectile. Airborne viruses (using the flight upgrade) can only be damaged by projectiles from the Anti Air Turret.

30. Let others do their job. • Remember this? What does that have to do with the heading of the slide?

32. Did you give something actionable to the programmers? • Memory considerations of quest variables. • There will be approximately 2500 quests in the game. • Players may have 20 open quests at a time. • Players can make up to 10 decision points in one quest, the status of which must be stored until the quest is completed. • Players may find content later which is unlocked by quests they have already completed – the completion state (and outcome) of a quest must be stored.

33. Prioritization • Give the features a priority, break them into phases • Be sure document clearly separates out later phase features.

34. Did you do this? • Phase 1: Prototype feature • (necessary to validate or demo the game) • Phase 2: Core feature. • (features and tools that hold up content creation go here) • Phase 3: Must be in shipped product • (includes features that depend on priority 2 features) • Phase 4: Wishlist, possibly expansion • Phase 5: Yeah, right

35. Across project • Prioritization is across the project, not the feature – an entire feature or document may be full of phase 2, phase 3, or phase 4 features.

36. ‘User Stories’ – or, what the user experiences/sees/does/etc… • Did you write a minute of gameplay in your GDD?

37. ‘User Stories’ – or, what the user experiences/sees/does/etc… • Fizzle using Fishing Rod – 32 pixels wide, 32 pixels long (1st-2nd frames), • 32 pixels wide, 32 pixels long (3rd frame) • Fizzle will able to reel in certain enemies. • What’s wrong with this?

38. Organization • Don’t make people hunt for the information they want. • Separate content into appendices, or into tables.

39. Streamline • Duplication is the devil, leads to confusion, update errors. • Make sure there are no contradictions in your document!

40. Thoughts on this? Romancing NPCs (Prototype) Players can attempt to romance NPCs of the opposite sex by dialogue options Players can also attempt to romance NPCs of the opposite sex by serenading them with songs they’ve learned. Advanced Romance (Phase Four) Players can craft their own songs for use in the romance system. • Players might be able to woo NPCs of the opposite sex. • In the future, we may add the functionality to increase your chances to woo women by playing sappy love songs. • If this is implemented, maybe players can write their own love songs.

41. It’s a plan, not a Christmas wishlist. • Use strong, declarative language • No ‘maybe’, ‘could’, ‘might’ • Even avoid ‘may’. • Don’t be ambiguous • Don’t say ‘we’ • Choose a direction • Move ‘maybe’ features to later phases.

42. You do want to share your reasoning… • Capturing your reasoning is especially useful for longer projects, where the team may literally forget why they chose one side or the other. • Capturing your reasoning, by extension, reduces the number of times contentious issues are reopened.

43. For example: • Any blob can capture an anchor point by moving onto it.  Once a blob captures an anchor point, it can't be moved by a blob force, but may still affect other blobs with its ability.  It can still be destroyed by a death ray or regular contact from a larger blob.  The anchor point, however, cannot be destroyed by Death Ray or Exploding blobs. The dynamic we wanted to support with anchor points is to allow players to rush and to mix up the types of interaction with blob forces

44. But compartmentalize it! • Any blob can capture an anchor point by moving onto it.  Once a blob captures an anchor point, it can't be moved by a blob force, but may still affect other blobs with its ability.  • (Some bullet points would have helped that last paragraph, huh?) ------------ Design Goals: • Anchor points allow players mix up the types of interaction with blob forces.

45. FADT and MDA: final note • Design docs won’t generally be structured around this • It’s supposed to be a lens to refine your process, not a checklist to describe your game • Use it in the right place, not to make me happy.

46. Here’s a look at a recent project

47. Woot. • Class is over! Now, crunch time! • Discuss final deliverables: • Design doc • TDD outline • Executable game • 360s