Game development usually works a bit different than application development. The reason is that games usually have far fewer and far less stringent requirements. You don't have a well-defined business problem your software is supposed to solve. The only true requirements of a game are "runs properly on the target platform", "appeals to the target demographic" and "is fun to play" (and maybe "sells a lot of microtransactions" if you are in that section of the industry). Everything else is subject to change during the development.
However, in order to make sure that all developers of the game are working in the same direction and not end up fighting to the death over creative differences, you should have some codified "vision" of how you want the final game to look and play. This vision is usually codified in a Game Design Document. Such a document usually describes:
- The basic premise of the game:
- The elevator pitch: The main game idea, described as briefly as possible.
- What is the genre of the game?
- Who is your target demographic?
- Which platform(s) are you targeting?
- The game mechanics:
- What actions can the player perform in this game and how do they affect the game?
- What non-player entities are in the game, how do they behave, and how do they interact with each other and with the player?
- The scope:
- How much content do you want the game to have?
- What level of quality do you want that content to have?
- The aesthetic direction of the game:
- What general atmosphere do you want the game to have?
- How do you want the game to look?
- How do you want the game to sound?
- When it comes to story, it depends a lot on the genre. Some games need no story at all. Many games only need a few sentences. But if you are creating a plot-driven game, like an RPG or adventure, then this can be in fact the longest part of the design document and can include:
- A description of the world in which the game takes place and its key locations
- A description of the important characters, their looks, their personality and their backstory
- A basic outline of the plot which is told during the game
If you look around the web, you can find a lot of templates for game design documents. The game industry is a lot less into formalities and standardized processes than the rest of the industry, so you won't find the one ISO-standard to rule them all. Just try to find one style which fits your project, your team and your work methodology.
However, be open to changes during development. When game design documents of popular games leak to the public, either intentionally or unintentionally, you can usually notice something interesting. If you compare these early design notes to the finished game, there will usually be lots of considerable differences. This is usually the result of a design process game developers call Fail Faster:
- Come up with a rough design
- Create a simple prototype
- Playtest it with a critical mindset and figure out what does not work about it
- Revise your design
- Go back to stage 2
So do not be afraid to change or cut features when you realize during playtesting that they aren't actually as fun as they were in your head. Also, be open to suggestions from the team. Most people in the game development industry decided to join the industry because they want to put their own game ideas into practice. So giving your team some creative influence can be a great motivator for them. But as a good producer, it is also your duty to say "No!" if you think an idea wouldn't work or would exceed the budget.
I am looking forward to playing your game.
