I'm late to the party, but I've been brushing up my game design skills lately and I checked to see if anyone in this community used a GDD. Not many it seems, but I do think it would be a benefit to the process of many. If not a GDD then one of the other common process documents.
I assume the situation is like this:
- Game development is hard, Indie gamedev is harder, Amateur gamedev is nearly impossible.
Games are inherently complex having a setting, characters, story, mechanics and many types of assets (audio, video, UI, 2d, 3d, etc), thus needing many different skills. Limiting the game to a VN with default stuff makes this less so, but plenty remains.
- AAA studio's are so ambitious and large that they need coordination. Professional documents provide that.
- Indie gamedev's lack the money to hire all the specialists, but they have time, so they wing it. There must be some coordination between team members, because they are doing things that may impact each other. Also you and your future self need to communicate as you have many task and you can only hold so much in your head.
- Amateurs have an even harder time as they lack money and time. It may be weeks before you can work on a task again, so you better write something down that helps you get in the flow again.
- Money is not a driver for amateur's, but finishing a game and the quality it will have, is.
Having something written down to help you start up again when you where away a wile, will help you finish the game. Having something guide you will help you keep the game consistent.
- Documents are communications and can be used to guide people as well as correct them.
You do not have to be strict with yourself or your team, but you may be able to keep on track and help them pointing the right way. (In your day job you're probably being "optimized" by a manager or project lead in a coercive way, having a hobby project that does the same, is probably a bit much. Look to organizations that work with volunteers to see a different way of working.)
As writing documents as well as reading them will not produce the game only help the process. Therefor the documents should be as short and clear as possible.
The documentation ranked from shortest to most detailed. Pick what you think will help and skip the rest:
- Log line and Genre
A line similar to the ones found in a TV guide. It describes the setting and the goal(s) of the game. Possibly includes the protagonist, antagonist and ensuing incident. The "hook" that makes the game interesting to play should be included here too. When fishing for an audience, you need a hook to catch your audience mind.
This is intended for players to choose the game out from all the others, but also for developers as a North Star point of reference they are aiming for.
- Game Pitch (also called Game Concept Document)
Brief document where the idea is explained using images. It's similar to a start-up elevator pitch.
This is intended for investors to see if they are interested, as many specialize on game type and/or platform. For amateurs this is an advertising tool to solicit support.
The following are all 1 Powerpoint slide Cover, Concept, Genre, Platform, Look/Visual Style, Target, references. The Look may be borrowed by using other peoples images as long as they get your point across.
- Game Proposal
For a normal game this is the planning and budgeting intended for investors. For an amateur game you and your team mates are the investors. It will help avoid burnout if you set reasonable deadlines for yourself and budget your time. This also includes the cost of things you buy like software tools, assets packs and people you hire like Fiver or Upwork artists. Your estimates will turn out bad, but that's ok. Having some idea about your project, is better as having no idea.
- Game page (here, steam, patreon, kickstarter)
As soon as you have fixed your art style you get your page up.
This is intended for to gauge players interest.
For indies it's a long road to get those Wishlist's over 10k to have a successful launch at steam. Here you probably want to build a community to get you through the rough patches of development.
- Story
The setting of the game influences the mechanics and art. I would write the story part of the game before the mechanics as text is easy to change. For an Indie finding the "fun" mechanics may be the hardest, so they start with that and build the story around it (when needed). As a VN or RPG is story driven, with those genres even an indie may start with the story.
- Treatment (also called Synopsis)
A short description of what happens in the story and it's setting.
It's intended to support writers fleshing out the story with dialog, programmers tying in mechanics and action, artists tying in assets into the story.
For a movie this ranges from half a page to 3 or even 6 pages. The sorter version is preferred as with interest the full screenplay is read.
- Screenplay (if there's dialog)
Contains the dialog contained in scenes laid out linearly in a document, including pointers for the actors and crew. It's the architecture of a movie. For a AAA games it commonly used for voice actors as those are used to that format.
For a VN or RPG it may be advantages for writers to have an overview of the dialog and the story situations, but it may be more efficient to write directly in the tool you are using for the game.
- Story Bible also called Lore Bible
Generally it's a Wiki on a closed server, but it may be public.
It's intended for the whole team to quickly look up specific location, character or story parts.
This is common if there are many side stories as in a open world game where you can non linearly visit many NPC's. It's much of the not so important stuff that has to be there to make the world seem real.
Could be applicable for a RPG(maker) game as you are free to organize the wiki how you like, but probably more efficient to do in the tool directly.
- Mechanics
- High level Game Design Document
The whole team uses the GDD, but it's primary intended for programmers.
it contains the log line, pitch, proposal and treatment information and add the high level mechanics and concept art. The screenplay is separate from the GDD as it's too large.
- Low level/detailed GDD
Similar to the High level version but the mechanics are more fleshed out in detail.
Concrete game art may be added to the concept art too, but artist will generally have their own art description documents.
Generally a Low Level Design Document is unwieldy and replaced by a wiki.
- UI Design
This is a part of the mechanics as mechanics need buttons, icons, reports etc. to function , but the controller input is also defined here. It is sometimes separated out from the GDD if there is a UX designer in the team. More often it's very close to being the manual of the game and it's used to analyse how the tutorial of the game needs to be handled.
- A wiki with Feature Spec's
Feature Spec's are specific documents describing a feature to be implement by a programmer. They are intended to be distributed to programmers as a complete package, so they can focus on one task only.
On small teams with lots of communication this isn't needed. (In agile methods like Scrum working software is preferred over documentation, but documentation is NOT prohibited)
- Art
- Concept Art
Intended for artists to get an idea of how the game and mainly it's setting looks.
- Character
- Character Sketch/Study
A simple sketch of the most prominent features of the (main) character(s). This should be easy to change as it has to react to changes in the story or mechanics.
This is intended to have an idea of the look of the game, so that can be discussed with artists, writers and designers.
- Character Design
A detailed design of the (main) character(s) intended as an example for the artists doing pixel art, photoshop or 3d modelling etc.
This is intended as concrete guidelines for the artists implementing the design.
- Character Animation Sheet
Drawn Motion captures (MoCap's) of how the character moves in various ways.
This is intended as concrete guidelines for the artists implementing the animation.
- Art Bible
This is all the art described in a wiki including image examples.
The intent is to have a central place for artists to reference assets.
Some of it may be stored there, but assets can get quite big so a file server is commonly used.
- Project tracking
An amateur might only need to track the project as long as there are people interested in the state of the project or you want to get better at estimating. Supporters, your teammates and yourself do have expectations about the duration of the development process and you can compare those expectation with the data in tracking documents. If you're not willing to steer, cut or otherwise manage your project, it can only be ensuring or worrying.
- Time estimates with a Gantt chart
Looks very professional and it's directly related to spending for a professional. How much is your time as an amateur worth? It does help if there are dependencies between parts of the game, like assets for a level that have to be done before the level can be designed.
- Asset list
This is a list of all the assets in the game. Because creating assets takes a lot of time you probably want to keep an eye on it.
It also denotes what assets must be available for what deliverable at the end of a faze of gamedev.
Examples of deliverables are:
- Prototype
This is a test of a questionable/innovative/alternative mechanic in the game. It probably needs some assets to properly function an then fairly assessed. This is delivered to the game designer and the team to improve the fun of the game. These are internal to the team and there might be multiple of them.
- Vertical Slice Demo
This shows the first area of the game (or otherwise a representative area) that is reasonably playable with completed/polished art. This is for games where visuals are important like in the action genre. It's delivered to publishers for investment and the public at large to gauge interest.
- First Playable Demo
This shows the completed/polished mechanics of the game, but it's limited in it's art. It's for a systems oriented games like those in the strategy genre. It's delivered to publishers for investment and the public at large to build momentum.
- Specific iterations of the game, Alpha version, Beta version, Finished game
The assets list shows when all the assets for the iteration or version are done, in working order, placed, sized, rigged, described, tied in, handling events etc. When artists may finish before the rest they could continue on the next iteration, but they could also make key art for marketing purposes or already work on an expansion.
- Expansions/DLC/follow up versions
As these are separate from the game, you probably have a separate asset list to know when you are done.
- Lists relating to mechanics and deliverables
Generally Excel sheets that show ordered entities in the game that need to be managed, balanced or tracked.
Examples are:
- Key item list, for items need to be held to advance the story or open an area. Useful for adventure games that need certain items at certain points.
- Loot system spreadsheet, for characters that can be dressed with item drops etc.
- Upgrade system, for characters gaining experience for instance in a RPG.
- Economic tables, to be able to balance the producers and consumers of items/materials/credits etc.
Industry specialization has lead to a number of specific designers in the games industry. These leadership roles may help you think about who might add to what document. On smaller games people have multiple roles so don't limit yourself.
- The role that defines the mechanics, rules, victory and defeat conditions etc. is the Game Designer for example: Will Wright.
- The role that defines the game concept, genre, setting, aesthetic is the Creative Director for example: Hideo Kojima.
- The role that defines the scenario elements, level layout, game situations, level mechanics is the Level Designer for example: Tom Hall.
When developing a game that has the art as it's main goal the Creative Director holds more sway. In a game that's more about gameplay the Game Designer is more important. The career path for these roles indicates about how they relate to other roles:
- In previous times programmers ended up as game designers, as they understood the technical difficulties.
- Currently some UX designers moved to the game designer role, because they have a thorough understanding of the player/user.
- Game journalists and streamers have also moved to the game designer role, as the sheer volume of different games played and judged, gives them an intuitive understanding of the player and a mental catalogue of mechanics used in games.
- The path now seems most common now, especially within a company, is from Level Designer, to Game Designer to Creative Director. The Level Designer works within the rules established by the Game Designer and in turn, works with the concepts of the Creative Director. Note that a Modder is generally an amateur Level Designer as he works with existing assets and mechanics. When a Modder makes or commissions specific assets and/or changes mechanics then he's actually a Game Designer or Creative Director using another game as a (temporary) basis.
- Another path is that of both the 2d and 3d artist to Concept Artist and then to the Creative Director role. The Concept Artist is a coordinating role that tries to have a consistent output between artists and can move to the Creative Director role when getting into the genre and game concepts.
The documents used depend on the needs of the project. Large projects need more coordination and have more stakeholders that need to be informed.
Large projects often switch to using Wiki's and they generally combine the Story Bible, Art Bible and Feature Specs into one big Wiki. Some parts like character description will then have a Design, Story and Feature specifications on 1 page.
When making a game the first few things you will probably do naturally. Starting with a short treatment is advisable, so you know your setting.
Creating a GDD would involve putting that together adding the high level mechanics, the UI design, the Concept Art and Character Sketches and your good to go.
I think it's a good idea to update the GDD regularly as it's living document and you want to communicate what you have learned about your game while developing it. A "lessens learned" or "design tried but failed" is advisable as in a few months time someone on your team may have a similar idea and you can point to it. An example often coming up for arcade type indie games is, adding online multiplayer to the game. When investigated it often turn out that it's technically difficult with latency concerns, having to run servers 24/7 and monetization issues. Having that written down helps with the next hire, intern, beta tester etc.
Updating the GDD also helps you to get away from the details of implementing the game and into the "Meta" of designing the game, as going a little slower the right way, is better as going fast the wrong way. Having something documented when you take an occasional step back to take note of your situation, will help with that. Write some of your thoughts down and your future self will thank you for it.
References:
-
You must be registered to see the links
-
You must be registered to see the links
-
You must be registered to see the links
Edit: typo's and improved unclear writing without invalidating Metis Anansi's comment.
Edit2: Add the Project tracking documents for completion sake.
