What is the contents of a HCD and what is it useful for?

A high concept document is like a resume for your game. It should contain enough information on a single page so that anyone that reads it can understand your game enough to decide if they want to collaborate with you.

The Contents:

High Concept:
You can think of this like the elevator pitch or a razor statement. The idea behind the high concept is to explain the games concept in only a couple of lines. This should give the reader a good idea of the concept without needing to think too hard.

Features:
A list of the key features should be included so that the reader can get a better understand of how the game works. Choosing what features to display here is important because you only want about two or three sentences per feature. This should explain the players experience and give the reader a mental image of how the game will play out, so make sure not to add unnecessary things such as physics or AI.

Target Audience:
A brief explanation of who the target audience is and why. This can include age, sex, or even people with certain interests.

Competition:
This section explains if there are any other products on the market like this one, and if there is how would this project compete with it.

Platform & Engine:
Knowing what platform the game is designed for and what engine it will be using can be the deciding point of whether or not someone will want to work on your game or not. This is an important part of the document.

Selling Points:
Explaining why this game is new to the market and why you believe it will sell successfully.

Design Goals:
A few points describing the design goals for the project can give readers an idea of the users experience. Things such as ‘Fast paced’ and ‘Easy to learn’ can say a lot about your game in a few words. Elaborate on each point with a sentence or two explaining how the game will achieve these goals.

Additional Information:
While this point can be detrimental to the document, it can also be a nice touch to include some interesting facts that the player may want to read about. Because it is right at the end there is nothing stopping the reader from reading if they lose interest and doesn’t take away from the rest of the document. This can include stuff such as concept art or character designs, just anything that sticks out about the game that hasn’t been explained yet.

The Purpose:

Overall the high concept document can be viewed as a sales tool, you can use it to explain to people your concept on a refined document. It is also useful as somewhere to store initial concepts. While brainstorming should be done on a separate document, the HCD serves as a place for your early concept to be written down before any other documentation is written.

What is the contents of a GDD and what is it useful for?

The game design document is meant to explain the intention of what the game is trying to achieve and also what is in the game from a design stand point. The GDD should be written in a way that it can be handed off to a team member and they understand every aspect of the games design, including the story, characters, gameplay, visuals and sound.

The Contents:

Overview:
An overview of the game will allow the reader to get an idea of what the game is trying to achieve from a paragraph or 2 description. The description should provide explain what aesthetic the game is appealing to and summarize how.

Story / Characters:
An in depth explanation of the story is required in a GDD if there is a narrative at all. It is the main place that the story will be communicated to the team members and should have the most detail it can.

Gameplay:
This is arguably the most important part of the document, it explains how the game is played and what the player will feel while playing.  Having things such as level design information that shows the players learning curve in relation to the level difficulty curve can help justify design decisions and communicate how it should be done throughout the project.

Controls:
Having a section for the controls is necessary if you want to expain how the game plays out. It is an important part of the gameplay to understand how the player uses the inputs. There is a large difference between using a trigger on a gamepad compared to using a key on a keyboard for controlling a cars acceleration. The games control layout should directly reflect what platform it is running on and how it can compliment the intended gameplay.

Visuals:
This is meant to be a quick overview of what the game is meant to look like. It usually contains some concept art or images from other media that help explain the art style. This is further gone into detail with the Art Bible if one exists.

Sounds:
An explanation of the sounds should go into full detail explaining the design decisions around the sounds and how they will compliment the gameplay. This should include background music, sound effects, UI sound, voice lines etc. The document should justify the decisions on the sounds to make sure it is the best it can be.

User Interface:
The user interface needs to be explained because it is a large part of the user experience. It should outline why any UI is present and what each UI element does. It is not meant to be a way to describe what it looks like in detail because that is what the art bible is for. This is meant to describe the functionality of the UI and how it can help teach the player and make the gameplay more intuitive. Having less UI is always a good thing so justifying why any UI is necessary is a must for this document.

The Purpose:

Overall the purpose of a GDD is to provide the relevant context to outside parties that may be collaborating on the project, used as a form of memory since the human brain is limited and unreliable, to account for any changes in the game design that may come down the road and to ensure that the implementation matches the intention of the game.

What is the contents of an Art Bible and what is it useful for?

An art bible is a document that is written by the art director and contains all the information about what the game will look like. This helps with the consistency of the art assets and the art direction which will ultimately result in a more polished looking game.

The Contents:

Art Style:
This can include information such as the time period, to who inhabitants the environment and their methods of construction. This is vital for artist to get an understanding of how the game will look.

Colour Palette:
The colour palette is very important to explain the intended feel of the game as well as the theme of the game. Information can include the colour swatches and their values such as hue, saturation, vibrance etc.

Character Art:
This includes the characters personality, their expressions, their costumes etc. that will help the artists see what the intended character looks like.

Camera:
This explains the camera’s angle, field of view and any effects that may be on the camera. Knowing how the perspective of the camera is very important to understand what the game will look like and where it will be viewed from.

Level of Details:
The level of details explains how much detail should go into an asset. You don’t want the artist to spend a whole day making an asset that is barely see by the player when they could be working on more important stuff. This is a good way to prevent these sort of misunderstandings and also prevent too many questions arising for the artist.

Atmosphere:
The can include information such as the colouring of an area and the weather conditions. It’s a guide to help the artist set the mood of an environment. This can be really important to a games design if it relies on the environments atmosphere.

User Interface:
Information regarding the user interface can include animations, UI design reasoning, how the UI promoted user experience and how the UI will look. Having reasoning behind all art decisions is key to having a consistent art style.

Asset List:
A list of assets will help give the artists an idea of the variance needed for each asset as well as how much work is needed to get done. The level of detail should reflect the amount of assets to make sure the artists are not putting in too much or too little detail into certain assets.

Technical Stuff:
A final section including the technical details should explain what naming conventions are used for the files and what file types should be used. This is absolutely necessary because these files need to be handed off to multiple other people who are not artists and have no idea how the artists name their stuff and what file types they use. The file types should coincide with the file types listed in the TDD so that there is consistency across the board.

The Purpose:

Overall the art bible is an important document especially if your game is very artistic. It provides the artists and new members with sufficient information on how the game should look. It needs to explain why art decisions were made and how the art direction maintains consistency throughout the project. It also helps bridge the gap between game designers / programmers and artists. They come from different areas and may not have the same methods and conventions as one another, so having a document that can explain this so that everyone is on the same page is very important in a project.

What is the contents of a TDD and what is it useful for?

A technical design document is used to explain and log everything about the game from a technical stand point. Where a game design document communicates the intention of the game, the technical design document communicates how those intentions will be achieved. A team member should be able to look at the TDD and understand exactly how the game functions.

The Contents:

Overview of features:
An overview of all of the features in the game will explain to the reader the scope of the game and what the game is about.

Technical Information:
This can include information such as what game engine is being used, the system requirements of the game and the video memory calculations. This is used to ensure there are no technical limitations that may cause the program to not operate as intended.

Game Object List:
A list of every logical game object and what they’re purpose is, this can include stuff from a simple wall to a projectile. The character list can also be included with a short description.

Collision Detection:
Information on the objects that can and cannot collide with each other help communicate how the game with operate in the engine and also help with understanding the player interaction.

Object Interaction:
A table that includes all possible interactions between every logical game object in the program will help visualize how the game works. This is extremely important because this is the sort of stuff the team members should know when they start working on the game.

Art Tools:
A list of the tools needed to make all of the art assets is included in the document. This give an idea of what tools are needed for the project overall and also makes sure the same program is used for every asset type for consistency and smoother workflow.

Information such as the programs version, overview of the product and the exact tools that will be needed for the project is also included. This is so that the members are all using the same version if needed and also know their limitations on what can be used to make the assets.

Scene Management:
This section included the information on how the game moves between scenes and transfers information across scenes. This is important because all games ‘should’ be using more than 1 scene and having a system that can efficient do this is important.

Physics Behaviour:
A description of how the physics behaves in the game such as, “when the player walks into this traffic cone, it will fall over normally” compared to “when the player walks into this traffic cone, it will be knocked away with a small amount of force.” It’s necessary to understand how physics operates in a project if it is applicable.

Task List:
A list of all the required tasks that will be completed in order to finish the project along with who will be completing them. If someone is unsure about a task, they can simply read this section and know who to talk to about the task in question. It helps a lot with team work and workflow.

Schedule:
A schedule that outlines the milestones of the tasks mentioned above is also included in the document. This is included because it helps centralize the data, a team should always have a proper scheduling method, but this shouldn’t conflict because the milestones should be the same all the way through the project.

Artificial Intelligence:
If applicable, an explanation of the AI in a game is extremely important. This will include the structure of the system, the states that the AI can be in and how it moves between states.

Networking:
If the game has multiplayer it is important to have an explanation of how that will work. Even if the game doesn’t have multiplayer, still mentioning that in the document is helpful.

Scripts, functions and variables:
Some TDD’s will include a list of all the scripts used in the game as well as all the functions used in those scripts as well as all the variables used in those functions. This simplifies the programmers workflow down a lot and also helps the designers understand the game better.

The Purpose:

So overall the TDD can be a very important document and should be used if you want to make your game the best it can be. It helps with the workflow and also lessens the amount of required communication between team members by having all the technical information in a central place where it can be used as req gathering. A TDD ensures that the design is doing what it intends by looking at each element of the game in utmost detail. It explains how everything is implemented and why it should be implemented in that way. The document should account for any future changes and explain in detail how things should be changed when they need to be.