Posts Tagged Game Design
Once you have produced a rough design document then you can use the ‘technical features’ statements to help you to start thinking about the systems that you will be using to implement your design. I like to identify the large scale systems / requirements at this stage to guide the overall architecture.
Some systems will be common to all games / engines although most will have multiple possible approaches to satisfy the system requirements. For instance, pretty much all games require systems to manage the rendering, input, sound effects, music, scene management, loading / saving, etc. etc. but how they are implemented can be completely different.
Jason Gregory, in his excellent in-depth book ‘Game Engine Architecture’, discusses how the runtime engine architecture is built in layers, each layer depending upon the layers below to operate. Layers include the hardware, drivers, and Operating System, 3rd party libraries, a Platform Independence Layer, the Core Systems, Resources, low-level systems, front end and gameplay foundations, and finally game-specific systems.
Microsoft XNA Game Studio enables us to skip over some areas as it will handle those for us, acting as a framework to build our own work upon. As long as the Operating System is supported (and the hardware/drivers meet certain requirements) we can ignore much of the lowest levels of the architecture. Many 3rd party libraries are available for C# and XNA including physics, animation, scripting or other technologies. We don’t directly need a Platform Independence Layer as XNA handles that (as long as we code with alternate platforms in mind) and also provides some of the Core System and low-level rendering functionality as well.
The idea here is not to get too bogged down in the minutiae of the individual system implementations but to have a rough idea of the overall systems that will be used and how they will connect / communicate. If you are also using a particular design methodology or pattern(s) then this is the place to consider it and how that may guide the architecture.
Try not to over-analyse what you will need / implement or you may end up spending so much time on this that you lose impetus (known as analysis paralysis).
Another issue to avoid is becoming ‘locked in’ to particular design choices. You may find that an early design choice is not really appropriate later on, so rather than rigidly stick to the early design you have to be willing to adapt and evolve.
The balance between flexibility and the original goals should be a personal / team decision and clearly communicated early on, don’t be afraid to explore new ideas or change / trial different elements but keep the main aspects / key features in sight to keep you moving forward.
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.