In my forays around the internet looking for examples and advice I have noticed that the majority of these sorts of projects flounder, fail, or stall out for varying reasons, but one key reason appear to be common; Lack of a clear, documented design goal.
Design for the win!
Having an idea is a good start but to keep things moving in the right direction you need a design document.
If you’re working with a team the design document is a way to clearly communicate what you want to achieve, what decisions you have already made, and the motivation behind them while for a solo programmer it is a way to ensure that you stay on target for what you want to achieve.
Design documents come in many shapes and sizes, but I would suggest that the key points to address are;
- Clearly state the ultimate goal
- Provide an overview of the main aspects
- Specify the key features
- Provide detail by section of each key area
1. For Rain City my goal is; ‘Rain City will be an immersive 3D role-playing environment utilising a ‘free-play’ system that does not constrain players to a set role or storyline. You will be able to develop relationships with the other inhabitants of the city and pursue your chosen role and any of the diverse sub-plots…or just roam freely.’
2. From this I can identify several aspects that form the goal; ‘immersive’, ‘role-playing’, ‘free-play’, ‘relationships’, etc and provide a bit more detail, including why these are important to our goal.
I also include in this section a set of common questions and answers, such as; ‘What is Rain City?’, ‘What is the setting?’, ‘What is the main focus?’, etc.
3. This section details the technical features; ‘3D engine’, ‘1st/3rd person view’, ‘interpersonal interaction model’, ‘character design system’, ‘storylines influenced by player actions’, etc. This allows me to build upon and demonstrate decisions that have been made about what to include, why, and further strengthen the design to meet the goal.
4. I then take each section in turn; ‘game world’, ‘characters’, ‘scenarios’, etc., and flesh out what decisions have been made and why, and what each section needs to achieve.
At this point I have made few technical statements, beyond the feature set, but have focused on look and feel, where necessary providing the background to that focus.
Because this is going to be based in part on a pen-n-paper role-play system I also have a separate Rules document that details the underlying game system mechanics, and a Background document that details the game world background.
The combination of these documents provides the basis for all future decision that will be made during development. Where you would normally be quite strict in constraining the computer game within the bounds of the RPG game system and background, I have the flexibility to adjust those if it simplifies or enhances the computer game.
A design document doesn’t have to be complete when you begin coding, and will evolve during actual implementation, but it should be as complete as it can be by that point. This avoids going off target, or exploring other avenues already rejected, which both wastes time and can be divisive in a team environment.