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 games development.

4
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
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
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
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
Concept
Plan
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
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.