This article is adapted from http://www.gamasutra.com/features/20050720/gold_01.shtml.
During the course of game development, most objects rarely get written once. Often we have to revisit them to fix bugs, add/remove features and for optimization. Thus, this article provides a practical method and an effective schedule to ensure your game is completed or otherwise a not-so-wonderful releasable version.
They keep track how much our game is completed.
They mark the completion of important game features.
They are the sub-goals we have to achieve at given deadlines.
- We must work towards milestones
- Milestones MUST NOT be unrealistic, even if it will benefit alot financially or ease expenses.
It is also important to include visible/audible progress in our milestones. We must be able to see/hear the progress we have made (or at least to show it to the management) although it is usually not the case.
Visiblity and Completeness go together.
It is also essential to build working versions frequently, weekly if not daily. However, it is recommended that we show the previous working versions to management if they ask for it, rather than the current version. It is important to show progress and it is necessary to upgrade or rewrite the current code to give another release with significant improvements. In other words, BE AHEAD OF TIME.
We will require some things before we jump into coding.
1. Create a comprehensive design of the game
- characters (if any)
- storyline (if any)
2. Create a big list of all classes that would be used in the game
Divide the list into 3 main categories:
- Core -> the most fundamental, critical, foundational
- Required -> features that define the game, make it playable Core & Required would make a game releasable with minimal features, but not exactly fun
- Desired -> features that would make a game great but not essential
Object Functionality: 4 Levels
- Null version -> initial version. May be compiled but not doing anything useful
- Base version -> shows some functionality, used to show the object's basic behaviour
- Nominal version -> fully implemented, visually accepted, commercially viable
- Optimal version -> ultimate version, state-of-the-art
An application is defined as of release quality if and only if its required features are at the nominal level.
An application is referred to as complete if and only if its desired features are at the optimal level.
Iterative Delivery: Ordering using priorities and levels
- Create null implementation of each object, starting from core than required than to desired.It then should be able to build and run, just without any features implemented.
- Now go back to the core tasks and start writing nominal implementations, then the required.The game should then be releasable. Subsequently, write the nominal implementations for the desired.
- Repeat the sweep from core to desired, writing the optimal implementations till we're done or stopped by external factors
Basically it means this:
Null Implementation: CORE -> REQUIRED -> DESIRED
Base & Nominal Implementation: CORE -> REQUIRED -> DESIRED
Optimal Implementation: CORE -> REQUIRED -> DESIRED
Firstly, we have to provide a definition of a 'good enough' game in order to measure our progress. With the iterated delivery method, we'll solve several problems that will arise such as miscalculating the amount of time needed till delivery. This method will ensure that time will be allocated for code revision and improvision.
As defined in Gamasutra:
The time scheduled for a task is the sum of the times for the null, base, nominal and optimal levels.