Software lifecycle models for game development l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 27

Software Lifecycle Models for Game Development PowerPoint PPT Presentation

Software Lifecycle Models for Game Development 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.

Download Presentation

Software Lifecycle Models for Game Development

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Software lifecycle models for game development l.jpg

Software Lifecycle Modelsfor Game Development


Software lifecycles l.jpg

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.


Software lifecycles3 l.jpg

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.


The waterfall model l.jpg

Concept

Requirements

Analysis

Design

Coding

Testing

Release

and

Maintenance

The Waterfall Model


Stages of the waterfall model l.jpg

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.


Stages of the waterfall model6 l.jpg

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.


Stages of the waterfall model7 l.jpg

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.


Discussion of the waterfall model l.jpg

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.


The modified waterfall model l.jpg

Concept

Requirements

Analysis

Design

Coding

Testing

Release

and

Maintenance

The Modified Waterfall Model


Stages of the modified waterfall model l.jpg

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.


Discussion of the modified waterfall model l.jpg

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.


The evolutionary prototyping model l.jpg

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


The evolutionary prototyping model13 l.jpg

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.


Stages of the evolutionary prototyping model l.jpg

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.


Discussion of the evolutionary prototyping model l.jpg

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.


The throwaway prototyping model l.jpg

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


The throwaway prototyping model17 l.jpg

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.


Stages of the throwaway prototyping model l.jpg

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.


Discussion of the throwaway prototyping model l.jpg

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.


The spiral model l.jpg

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


The spiral model21 l.jpg

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.


Stages of the spiral model l.jpg

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.


Discussion of the spiral model l.jpg

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.


The transformational model l.jpg

Requirements

Analysis

Requirements

Comparison

Formal

Specification

Testing

Transform

#1

Transform

#n

Transform

#2

Release

and

Maintenance

The Transformational Model


The transformational model25 l.jpg

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.


Stages of the transformational model l.jpg

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.


Discussion of the transformational model l.jpg

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.


  • Login