Object-Oriented Game Development : Iterative Development Techniques

Two important, fundamental questions in development ('What order should tasks be performed?' and 'When is the game finished?') are discussed and a single answer is provided for both. As far as development is concerned, the worst thing that can happen is to be writing system-critical code towards the end of a project. It is such a common occurrence that you think someone will spot it and put a stop to it. It will not only stress the team, but also guaranteed to introduce other problems that were considered stable. It's always ideal to prioritise your tasks so that the problem can be avoided. It is rather tricky to describe the criteria for “completion” of a game. Some functionality and features of games that are selling are only of a certain percentage of the ambitions of the game development team. We'll normally revisit the different parts of the code to further improve the game. Thus, we need a system that allows time and space for evolution which will not spend extra time and or end up panicking that distinguishes most development processes.

One of the cons developers have to deal with how different milestones and the schedules are interpreted by production teams and management. To developers, schedules represent how well a product will evolve over time while the management see it as a contract between them and developers, promising certain things at times. Thus, developers often have to work long hours under pressure to get “promised” features out and the management have responsibility for financial balances that depend on the features being in place. Development of a game should not be shown to the management no matter how much the developers want to impress the management. Otherwise, it will just lead them to doom! It is always right to prioritise and do the most important tasks first and the superficial tasks last. Application is defined as of release quality if and only if its required features are at the nominal level. It is referred to as complete if and only if its desired features are at the optimal level. From these definitions, we see the difference of a product that cannot be sold all the way up to implementing and polishing every feature the specification has. It just gets better and better, and – provided that the tasks have been prioritise and undertaken in a sensible order – can be released any time after it becomes of release quality. Another point to note is that Object Oriented development is perfectly suited to a level-based scheme (and conversely procedural development does not adapt as easily). By writing an object in a suitably object-oriented fashion, we may end up with a reusable component.


2 things the author recommend doing:

• It places a greater emphasis on getting the most important games systems to a releasable quality. It also means we can get to work on one or two of the flash bits earlier, and from week to week, we can see both growth and improvement in our game.
• Communication is important – all programmers should know what other programmers are doing via code reviews. They should be clear and informatively documented (either via meaningful commenting or actual paper or electronic documentation) and systems should be engineered to be as self-contained and maintainable as is humanly possible.

2 things the author don't recommend doing:

• The disadvantage is that after the base level, no new functionality appears – it only improves the existing stuff. While this is fine if you view it from a purely theoretical standpoint, it does make it difficult to impress others.
• If there is only one programmer and he/she is absent from work, who will be able to do the work when only the programmer understands his/her own work? And what if there are more than 1 programmer and there is lack of communication among them, there will be a loss of momentum whenever programmers change task. Although the changes are probably smaller, it can happen several times over the course of the project, and the damage can be intensifying.