Designing a dream...
Name:
Game Development Series
Author: Peter
Dwyer
Date: January 27, 1999
Description: This will be my third article in my game development and design series. As such I will cover the actual creation of a game design from the original concept to handing out the work assignments. I will tell you how to get it to the level where it is ready for coding and where the designer (namely you) will want to get a team together to make the design a reality.
This series of articles were originally posted to the alt.games.programming newsgroup and I felt the might be useful. They are reprinted here by permission of the author.
Ideas ideas everywhere and not a pen with ink!
I'll start off with some good advice (as if I don't always do this). You will want to have a pen/pencil and a pad of some kind with you at all times. This may seem odd, and if you dress in anoraks, you may well be mistaken for a train spotter, but it will ensure that you do not forget any ideas you have while away from a means of recording them.
There have been many occasions that I have been on a train or on a bus, and suddenly though
"That would work well in this project or ureka my next project will be called ..."
Only to find that I have no means to record the idea. This is fine if you are five minutes from home and can rush inside and write it down, but is complete hell if the journey is going to last another hour or so.
Once you have written down some ideas and concepts, you will want to choose one to actually implement. The process of choosing is a very hard one. You will have to take into account the fact that you and possible four or five other individuals, will be working on this design for anywhere from six months to two years.
The idea you select will need to be practical i.e achievable by current technology or immenent technology and importantly the idea must be fun for the player. To determine if an idea is fun, you will want to ask as many trusted people as possible (this does not include everyone on the internet!). You need to get their honest oppinions of the idea and not simple a universal agreement, because they do not want to hurt your feelings.
It would do you well to remember that their answers will be based on the types of games they like, so if you are planning on designing a shoot-em up, then ask people who like shoot 'em ups. They will be able to tell you if the idea sounds great to them, stale or simply wierd.
At this stage you should be left with a few ideas and suggestions for your original concepts. Do not take any negative comments as a personal attack against you. If the people you have asked have been honest, then their suggestions and comments will serve you well.
Often designers become so attached to their ideas that they fail to take into account that they will not be the ones playing the final product or shelling out upwards of 35 - 40 pounds/dollars for it. The second most common misconception that games designers have, is that because they like their game concept, everyone else MUST like it. The important thing at this stage is to refine your concept until it sounds good to both you and the type of people who will be playing (and paying) for it.
A simple design document layout
The following sections are one possible design document layout :
- Introduction
- Concept.
- Key Design elements
- Key features
- Expected Platforms
- Known issues
- System Requirements
Taking these sections individually, the expected content is as follows
Introduction
This is a brief introduction to the project, detailing what the document covers and who is expected to read the document. This will be something along the lines of :
This document covers the concept for game x as well as those elements of the concept that have been identified as key to the design of this game. This document also covers the key features of the concept (such as required engine features, expected colour depths, etc etc). The document also details the lowest and recommended platforms that this design will be expected to run on and the expected system requirements.
Those expected to read this document are all those involved with the xxx project.
This document is version x.xx dated dd/mm/yyyy updated by xxxxxxxxxx
Concept
This is the game concept itself, and as such should be as detailed as possible, without being restrictive. By this I mean that the game concept should not include any mention of colour depths or engine features. It should simply cover the storyline of the game, key protagonists such as the evil empire of blog etc. As many key elements of the story should be mentioned here, such as why the main character/s is/are doing what they do. What area the story covers, background information on the story etc.
This will all help to clarify and focus the team when coding begins. You will often need to refer back to this document to get the team back on track and to ensure that during production, you have not deviated too much from the original concept.
Bare in mind that this document is almost certainly going to be updated and changed at some point during production. Often to add elements that had not been properly thought out during the original design, or to remove elements that have been found to hinder rather than enhance the design or even to remove elements that have been found to be impossible to implement.
When this happens, you will need to ensure that you do not alter the original gist of the concept and that any changes are not at the cost of previous design content.
Key Design Elements
This section should contain details of the key elements of the design, such as gameplay elements, special attacks, look and feel ideas, concept maps of the areas to be created within the game, special weapons, mothership designs etc etc.
An example of a key design element would be the ocarina in Legend of Zelda 64, this is the linch pin of the whole game and allows the main character to travel back and forth in time, as well as open doors and move blocks that would otherwise be impossible to move etc.
In your own design, it may be a sword that is the key element, or even the character himself (FFVII is a good example of the characters being the key design elements).
Key Features
This section details the hardware related side of the key game elements, such as the colour depth expected, the features of the game engine that will be needed to create the world, the level design ideas i.e do you want the levels to be dark and moody or light and breezy, is there a continuous sound track that tells the player about danger approaching etc.
The control method you want to use (joystick, pad, keyboard) and how it will be used within the game.
You may also want to mention camera options, such as a roaming camera, a known game view such as three quarter view, isometric etc.
Above all this section should try to cover as much of the hardware related design issues as possible.
Expected platforms
This covers the expected platforms for this game. If you plan to create a playstation, N64 and PC game, then you will need to tailor your design for the lowest common denominator i.e if you were planning full motion video, this will not be possible on the N64 and so your design will have to remove this or find a way of doing the same sort of thing in realtime 2D or 3D.
Known Issues
This section covers the known issues, as raised by the target platform/s and the limitations of the available technology. This section will not contain much to begin with, but will undoubtedly grow as the project progresses. This section should be tackled throughout production and most of the known limitations should be eliminated. Wether this is done through redesign of the original concept, or programming trickery is up to you and to a large extent what is required to deliver the project in as close a state as possible to the original design.
System Requirements
This section is normally filled in with a base system requirement at the start of the project, and refined as the project nears completion. The PII 333 you suggest at the start of the project may well not be powerfull enough to handle the final beasts that emerges.
Finally I should state that you may add or remove, or even amalgamate my suggested sections as you see fit. Remeber this is your project and you ultimately decide what is important to it. If you think of a section that should be in here, that I have not mentioned, then by all means put it into your design document. One obvious ommission is the copyright notice. This will be needed for your final design, and you will need to get it properly registered. A lawyer will be able to tell you what you need to do to protect your design idea correctly and a simple consultation will not set you back too much.
Hardware Limitations
At this point you are probably thinking that there is no way you will be able to produce this design with your current budget ( probably nothing if you started out as I did ) and your current hardware.
This happily is not the case. I got by for quite a while with a single ( all be it high spec ) PC. The machine I used was also my word processor, games machine and design factory. My graphics man used his own PC to create the in game graphics, and would mail or hand deliver them as necessary. Our sound man used an ancient commodore Amiga to produce .mid files to die for and our tools designer used his university computer labs to design a series of tools that any professional tool designer would be proud of.
My point is that you do not need killer hardware to get your project to a level that will cause interest in the games distribution community.
Feeding the Beast
When you have your production about at the 50% mark and are able to show potential distributers what you have, you can get both funding for your design (don't sign anything that gives the funding party 50% or above of your newly formed company. Trust me on this one!!) and a means of getting it out to the public.
It is also at this point that you will want to upgrade your hardware and perhaps aquire some offices. This should be included in any budget you give to a potential funding source. Anyone funding you will want to see where every penny of their money is going and the expected return on their money will have to justify their initial outlay. At this point you will need to produce your design document to sell the idea to any potential sponsors. Having a 50% finished and hopefully visually pleasing demo to show will also serve to further make your case.
Don't worry if you don't get funding immediately, this is common. You may even be asked to go away and add or remove certain features, before funding will be given. This is also a common request, and seems to be used to test if you are committed to your project or not.
If you give in and agree to change the project, then you can almost guarantee that funding is not going to be forth coming from that sponsor. They will see your compromise not as a willingness to incorporate their ideas into your game, but rather as an act of weakness and a risky investment of their money.
Remember potential sponsors may know nothing about game design and will at you purely as an investment opportunity. If you don't show that you can lead your company into a profitable and stable future, then why would they give you money?
A Mountain of Documents
Enough about funding. I may return to this subject at a later posting, but for now back to the design and production.
You should now have a fairly robust design document ( complete with rough sketches of characters, weapons and items if necessary ). You should also have a pretty good idea of the hardware you will need to produce this design. This is where you will suddenly feel like a typist on a mountain of documents. Confused? Then let me explain.
Though the design document is the key document, it is by no means the only document you will need. In fact it is only the beginning of the paper trail. You will need to produce design specifications for the game engine, the level, animation and texture tools and a design document for the main program. You will then need to distribute these documents to your team who in turn will need to look over the documents and tell you if they will be able to produce the required programs and if so, how long this will take.
Remember that your tool design documents must have detailed descriptions of any file formats that need to be produced. The engine programmer will have to rely on the tools producing the correct file formats or problems will occur when the data is imported.
By the abyss I've started haven't I?
Yes! You have now started production of your project. You will need to keep in mind that this is just the beginning and there is a very long treck before you finish. The road will not be easy and if you think it will be, then your in for a big shock.
You will need to ensure that you monitor the progress of your team and that you are on hand to answer any questions they have and provide any assistance they need.
In my next article I will cover team meetings and how to hold a meeting when your team is spread across the world.
Peter Dwyer (software engineer, designer and sometime whip cracker)