Software Lifecycle Models for Game Development

1. Software Lifecycle Modelsfor Game Development

2. Software Lifecycles • Before it is anything else, building a game is a software development project. • Because the end product is entertainment, you may try to compare the process to movie production or writing a book. • In the end, however, the process taken should be from software engineering.

3. Software Lifecycles • Software engineering recognizes several formal approaches to design and development. • Some are best suited to very small projects. • Others are better for very large projects. • Most game projects fall somewhere in the middle. • The choice of software lifecycle is critical, and can ultimately lead to the success or failure of a game’s development.

4. Concept Requirements Analysis Design Coding Testing Release and Maintenance The Waterfall Model

5. Stages of The Waterfall Model • Concept • As with all software, a game begins with its first concept. This concept has been refined and developed into a game proposal. • Requirements Analysis • The requirements of the game have been determined during preproduction. • The result of this was the game design document, a functional specification of how the game should operate.

6. Stages of The Waterfall Model • Design • Software design was also carried out to a certain extent during preproduction, resulting in the technical design document. • Further refinements might be necessary during development before coding can proceed. • Coding • This is when the game code is actually developed and written based on the detailed software design.

7. Stages of The Waterfall Model • Testing • This is when the game is tested for adherence to the game design document and to ensure that the game design results in exciting and interesting gameplay. • Bugs discovered during testing are naturally removed. • Unit, system, and acceptance testing. • In gaming, Alpha and Beta testing are used frequently as well. • Release and Maintenance • This is when the game is sold to and used by players. • Certain maintenance may be necessary to add features and new content, or to fix bugs that were not removed during the testing phase.

8. Discussion of the Waterfall Model • In a perfect world, software development would follow the classic waterfall model. • This works best if the requirements are well defined up front and will not change. • Most new game projects are significantly more chaotic than this model allows for. • If you are doing a sequel or port of a game, this might work well. • Enough is known in advance that a linear progression of development is suitable.

9. Concept Requirements Analysis Design Coding Testing Release and Maintenance The Modified Waterfall Model

10. Stages of the Modified Waterfall Model • The modified waterfall model has the same basic stages and functionality as the classic waterfall model. • The difference is that there is now feedback between stages. • If a problem is discovered in one stage, suitable corrective actions can be taken in the previous stage. • This can have a cascading effect, going back further and further up the waterfall until the problem can be corrected properly.

11. Discussion of the Modified Waterfall Model • The modified waterfall model works better in most cases than the classic waterfall model. • It has the same breakdown of development tasks, but has the additional feature of feedback to make things better. • Consequently, this approach can handle more dynamic projects. • For most new games, however, this approach is still too linear in nature, even with the addition of feedback.

12. Requirements Analysis Prototype Requirements Prototype Design Prototype Coding List of Revisions List of Revisions List of Revisions List of Revisions Prototype Testing Release and Maintenance The Evolutionary Prototyping Model

13. The Evolutionary Prototyping Model • In this approach, a prototype game is made as quickly as possible. • At each stage of prototyping, revisions can be made that will feed back into the process to create a new version of the prototype. • With sufficient revisions, the game will evolve to the point where it is acceptable to release. • This approach is known as evolutionary prototyping as a result.

14. Stages of the Evolutionary Prototyping Model • Similar stages of requirements analysis, design, coding, and testing from the waterfall model are used for each prototype. • This time, revisions from each prototype are fed back into earlier stages to commence the development of a new prototype. • The intention here is that each stage is much shorter than the corresponding stage in the waterfall model. Each stage, however, is visited multiple times with each new prototype.

15. Discussion of the Evolutionary Prototyping Model • This is likely the best development model for most new games. • It allows you to quickly make changes to refine your vision of the game as development proceeds. • One must be careful though: • Do not get ahead of yourself. • Do not let hacks or bad code live from one prototype to the next. Clean these things out! • Each prototype should have its own tight cycle of development, managed and scheduled in much the same way as the full project.

16. Initial Requirements Prototype Requirements Prototype Design Prototype Coding List of Revisions List of Revisions List of Revisions List of Revisions Prototype Testing Final Requirements The Throwaway Prototyping Model

17. The Throwaway Prototyping Model • The general premise behind throwaway prototyping is that the final game product is not a prototype. • Prototyping is instead used to go from initial requirements in the game proposal to the final requirements in the design documents. • It is meant to finalize these functional requirements so that a waterfall model can succeed in short order from this point. • In essence, prototypes developed are part of preproduction, not production, as was the case with evolutionary prototyping.

18. Stages of the Throwaway Prototyping Model • The stages of this model are essentially a combination of evolutionary prototyping and a waterfall model. • Prototyping is carried out to refine and finalize functional requirements. • From these finalized requirements, the waterfall model takes over to develop the game from scratch. • The original prototype code is thrown away and not part of the final game.

19. Discussion of the Throwaway Prototyping Model • You get the benefits of prototyping to ensure gameplay is exactly where you want. • You also ensure that any hacks or poor practices used in the haste of developing prototypes is not part of the final game. • There are some drawbacks, though. • It can be hard to throwaway initial prototypes because of the investments of time, money, and emotions made in them. • There is also the risk of the final game not being like the prototypes, and missing expectations as a result. • This is still a reasonable alternative.

20. The Spiral Model Evaluate Alternatives and Risks Determine Goals, Alternatives, and Constraints Risk Analysis Constraints Constraints Risk Analysis Alternatives Risk Prototype Alternatives A, C Prototype Prototype R, P A, C Plan Concept Requirements Plan Plan Coding Design Testing Product Planning Development and Testing

21. The Spiral Model • The spiral model combines waterfall elements with prototyping and risk analysis. • While most people would agree that risk is part of any software project, only this model recognizes it as part of the process. • The idea is to periodically look for risks and formalize plans to minimize and control them.

22. Stages of the Spiral Model • The stages are the same as what we have seen as part of previous models. • Except, of course for periodic planning, alternative and constraint formulation, and risk analyses. • The stages are organized so that you start in the middle of the spiral, and work your way out as development proceeds. • The end result is that between each stage of the typical waterfall model, there are planning, formulation, risk analysis, and prototyping stages. • When the spiral is exited, the product is complete.

23. Discussion of the Spiral Model • If your publisher is very cautious or has doubts about the game project, this model might best suit your needs. • It allows you to calm their fears as you progress through development. • The downside of this, of course, is that the additional planning, formulations, and risk analyses take time and cost money. • If constraints are tight, this is not likely the model for you.

24. Requirements Analysis Requirements Comparison … Formal Specification Testing Transform #1 Transform #n Transform #2 Release and Maintenance The Transformational Model

25. The Transformational Model • The original functional specification of the game in the game design document is in a very informal form. • If this informal specification is made formal, then a series of transformations can be applied to transform the specification into code. • After sanity testing, this can be released with assurances it will work.

26. Stages of the Transformational Model • In this model, design and coding are replaced with transformations. • The original specification of the game is converted into a formal specification (such as the Z notation). • This formal specification goes through iterations where it is compared to the original and refined to ensure it properly addresses original intentions. • A series of transforms are applied to the formal specifications to generate code meeting the specifications. • When done, the resulting code should implement the game described in the original game design document.

27. Discussion of the Transformational Model • There are several drawbacks to this approach: • Formally specifying a game can be incredibly difficult and time consuming, if at all possible. • Producing transforms to generate good game code is also difficult and time consuming. • Considerable time is spent working from the original game design document; if this needs to be changed significantly, you need to start over. • In theory, transforms can be reused. • Once they are developed once, all new games only need to be specified formally, and the rest of development occurs automagically, resulting in a game that meets specifications.