Monday, 4 February 2013

XB3002 - Unify GDD Skeletal Draft 1



Unify
Intro
1 paragraph description of the game. Describe your game in as few words as possible, as if you only had seven seconds to explain it to somebody. Attempt to capture the feel of the game - general enthusiasm ("This is a fantastic and exciting 3D platforming game!") is less valuable than text written in-theme, such as:
The dame's gone missing, and, just like always, you're to blame. Now you've gotta beat your way through an undead horde before she's sacrificed to Zombie Jesus... and you didn't even get to eat breakfast. The Battle for Zombie Breakfast is a horror/noir 2D side-scrolling beat-em-up starring Isaiah Stakes.

Character bios
1-2 paragraph description of each of the major characters. Mention in particular how they figure into the game itself, and the way the player will perceive them initially vs. once they get to know them.
Charlie:
Mom:
            Dad:

Plot Overview
4-6 paragraphs. With as little backstory as possible, describe the game from start to finish. Include a rough breakdown of what is cutscene, what is gameplay, etc. With each part of the plot, it should be obvious how it will be presented in the game itself.
Parents divorce -> Charlie decides to take matters into their own hands and re-unite the family -> Charlie talks to townsfolk for advice and help -> but no-one is 100% happy with the idea -> Charlie must complete quests for each of the townsfolk ->

Gameplay description
1-2 paragraphs describing each distinct mode of gameplay, starting with core gameplay. For instance, Half Life 2 would first describe general running around and shooting, then twists on the core gameplay (such as the gravity gun), then vehicle sequences.

Artistic style outline
2-3 paragraphs describing the artistic style and feel. Cover actual in-game art, UI and menus and sound. Mocked up screenshots are preferred, if not, reference art.

Systematic breakdown of components
A rough outline of what systems will be required (for example, ones that will show up on most lists: 2D and/or 3D renderer, state machine, save/load system, UI system, collision system, particle system, etc). Include special features that, while they may not have their own system, will still need to be accounted for when creating systems (ie. day/night cycles, sound affecting gameplay, etc). If you will be using an API/SDK for a system, note it down - you'll still have to do some work learning/integrating the foreign system.

Asset breakdown
Similar to the System Breakdown, but for visual assets, text and sound.
Art Assets: List each major area of artwork (Player, Enemies, Worlds, UI/Menus, HUD, Effects), specifying roughly how detailed animations and states will be, and however much you know at this point about the pipeline/programs used.
Text Assets: Identify major areas (tutorial, tips, scripted dialogue/quests, dynamically presented dialogue, narration), and attempt to gauge the amount of effort required on each section.
Sound Assets: Similarly, the major areas (In-game sound, UI/HUD feedback sound, music, voice) should be detailed and described.

Suggested Game Flow Diagram
The intent of this section is to lay out, step by step, what the player experiences from as soon as they turn on the game until the end. While this can be generic and use a lot of loops (ie. Start Game -> Cutscene -> Tutorial -> loop(Cutscene -> Level -> Results Screen) -> End), it's probably a good idea to attempt to envisage how your game might be able to break up the monotony that is evident in that design.
The great thing about this section is it gets you really thinking about what your game is and how it is presented, as opposed to the amalgam of disjointed ideas in your head. The deeper you get into this Game Flow Diagram, the more confident you will be about what your game is precisely made up of, and what the experience of playing it will be.

Suggested Project Timeline
Here's where we get to the part where hearts break and tempers are lost - laying out a rough schedule for the game's development that utilizes the breakdowns that were made earlier in the document. Schedule aggressively, but be realistic - you're probably not going to get all of your menus in and working in a day. You don't have to be specific about where and when - the most important information to end up with here is the number of man hours per team member required, and exactly who will be responsible for what.

Additional Ideas and Possibilities
This final section is a bit of an amalgam of everything that didn't fit in the sections before hand. It's an appendix of all of the things that you didn't think were necessarily core to the game, but you'd like to consider along the way. It's also for alternate possibilities - for instance, if you had two main characters in mind, put the better one in the main document, and then the alternate here. Finally, if you have any ideas that you're not sure about, but would like to prototype, then this is the place for that stuff as well.