Good Documentation is a MustIn the introduction, I've pretty much given a good example of what could go wrong if you don't have good documentation. However, let's take a look at what could "go right" and in the end - benefit the entire team:
- You get the chance to map out your ideas and analyze them as time goes by.
- Everyone knows what's going on with the project.
- Getting someone up to speed with what you're doing with the project.
- Keeping the development consistent.
- Keeping track of the code. This is very useful for a future refactoring process.
- Getting an overview of the main points of your concept and the way that you implement them.
- Project Blueprint
- Design Documentation
- Technical Documentation
- Workflow Documentation
- Version Documentation
Documentation How-ToThe process of writing down your documentation has to start after your first brainstorming or whatever it is that the individual indie studio does to get their concept together. Enter the Blueprint - the project blueprint is something really, really important. It's not supposed to be a several hundred pages long book - it's supposed to be a blueprint. That means that in it, you have to write down only basic things and map out what you are going to do as a base idea and what you are going to build upon. This would include:
- Basic story - don't get into writing storyboards. Just map out that in your game, for example, a guy will be slaying dragons, obtaining items and saving damsels.
- Basic gameplay features - again, no details. You don't need to have the complete rule set or high-end concept. Try to put in perspective the genre of your game, the most basic concepts of the gameplay aspect and some ground rules. To build upon the example from the previous paragraph, you should put in your blueprint that you are going to have a 3rd person hack'n' slash game, where you will have three playable classes, you will have bosses, mobs and you will gather items and level up.
- Target groups - this one is very important. You need to map out your audience and also, the platform you are going to build this game for. That's not to say that you are going to include numbers here or go out of your way to do deep research. Just something like this (again, applicable for the example above) - target is RPG fans, the platform is PC.
- Basic technical specs - this is really the meat of your document. Here you should write down what you are going to use to develop the game. You are going to choose your programming language, your game engine (if you are planning on using such and not go too low-level), your database, probable server connections, software tools (for the 2D/3D arts and sound) and so on and so forth. Here you do not need to write code specifications. Just map out the technologies that you are going to use.
- Estimations - this one is not to be taken lightly. It's essential that your work is traced by your own project estimations. And by estimations here, I'm not talking so much in time, as this is something that simply can't be really estimated, but more in terms of resources. You need to estimate what kind of resource is going to go into what you are about to do. Are you going to purchase some software, or are you planning to go Open Source? How are you going to match your development process? Are there some additional things that need to be included into the estimate? Those are the things you really need to worry about.
- Other groundwork stuff - on a game-to-game basis, this may vary or not exist as a paragraph all together. However, some games have very specific needs. If such a thing is going on with your idea, you better write it down.
- First stage - building core mechanics on a test stage/level/whatever. Here you will build up the core mechanics and have something to upgrade and build on, in order to make a better product in the future.
- Second stage - refine mechanics from first stage and start to add features.
Interesting PointsSome things to look out for when writing this type of documentation:
- You are a specialist at your field, be it developer, game designer and so on. Don't become a documentation fiend. You should keep your documentation writing at the low end. Write the most important things and things that have strong dependencies. Don't waste time.
- Do not include personal thoughts in plain text in your documentation - this is work, not the fantasy universe of Lord of the Rings.
- Keep in mind, this is internal documentation for use within the team. High level of professional and business talk only wastes your time and that of your colleagues. Go straight to the point.
- No need for tables and graphs. Period.