Although failure is always an option, and something we should learn from, what are some things that we can do to reduce failure? Two tips tied together into one: Deadlines and Feedback.
Not everyone has taken on Project Management as a studied discipline which is unfortunate as some of the tactics a project manager will use can be really handy when making a computer game. Any good business college will have you take at least one class in PM, and you might walk out of it with a PMBOK (Project Managers Body of Knowledge). As an Amateur Computer Game Designer you most likely will not need every piece of information in the PMBOK, but you can still benefit from a couple points that project managers are fond of. They also happen to be popular advice among Indie game developers.
During his talk at PAX Scott MacMillan stated that Deadlines are very important. It was something that he learned the hard way. You can see his slides from that presentation, but you cannot see what he discusses during those slides. It’s something that I have also been learning about on the ZoRTS Project. Let me synthesize what has been learned first hand, what Scott was trying to say in his presentation, and a couple things picked up from Boston University.
Deadlines should be small tasks which can be completed regularly. There is an art to setting deadlines (with deliverables) in that they should not be made too big, nor too small. For example, here is a little list of things that could be deadlines for a computer game project.
- Game engine (due 1 year from today)
- Art (due 1 year from today)
- Sound (due 1 year from today)
- Text (due 1 year from today)
These are some of the major components when building a computer game. You have to produce the engine that runs the game. Someone has to produce the visual and the auditory art and someone has to write text (could be in the game, could be website material). What is wrong with this list of deadlines? They have no specificity to them, and no deliverables. Which means it will be harder to determine if progress is being made within the project (no feedback).
Instead lets try goals which are tied directly to a deliverable and have much shorter durations. The actual times, deliverables and goals are going to be based on your project, theses are just used as an example, they are not specific suggestions.
- Game Engine Prototype, with 1 unit, 1 building, 1 vehicle (due in 1 month).
- Art for each of those basic entities (due in 1 month)
- Intro music (due in 1 month), sound effects for each basic unit (due in 2 months).
- Completion of the Game Design Doc (due in 1 month)
- Basic website text (due in 2 months)