CDMM02 Week 1

1
CDMM02Week 1

• Game Unified Process (GUP)

2
Lifecycle approaches

• Waterfall
• WinWin

3
Waterfall Development Basics

• The waterfall development process is the one
  commonly used in game development. It has
  distinct phases that need to be completed in a
  certain order. Once a phase has been complete
  there is no turning back and it is on to the next
  phase.
• Waterfall processes occur at various levels of
  complexity. The following are the larger
  categories found in game development, described
  in a common sequence of execution.

4
Waterfall
5
Win Win Spiral model

• The original spiral model Boehm, 1988 uses a
  cyclic approach to develop increasingly more
  detailed versions of a software system
  culminating in incremental releases of the
  systems operational capability.
• Each cycle involves four main activities
• Elaborate the system or subsystems product and
  process objectives, constraints, and
  alternatives.
• Evaluate the alternatives with respect to the
  objectives and constraints. Identify and resolve
  major sources of product and process risk.
• Elaborate the definition of the product and
  process.
• Plan the next cycle, and update the life-cycle
  plan, including partition of the system into
  subsystems to be addressed in parallel cycles.
  This can include a plan to terminate the project
  if it is too risky or infeasible. Secure the
  managements commitment to proceed as planned.
• (Boehm, Egyed, Kwan and Machy, 1997)

6
(No Transcript)
7
GUP Waterfall method
8
Conception

• The business analysts, product managers, and
  senior development personnel get together and
  discuss what the game should be. Among other
  issues, they may discuss the following
• Audience
• Platform
• Development time frame
• Some of the features of the game
• Some of the high-level technical and artistic
  challenges
• The group may (or may not) produce a document
  describing all of the expectations for the game
  and some of the detail about how a group might
  approach development. In some cases a series of
  discussions results in a go or no-go decision

9
Game specification

• If the team gets the go ahead to proceed, a
  document is crafted by the product manager and/or
  producer that describes what the user experience
  will be in the game. This involves play
  characteristics, platform decisions, and
  potential artistic mockups of the game. It is a
  description of the game from the end user's
  perspective. This document is circulated to
  high-level art directors, game designers, and
  architects.

10

• Art bible/story bible
• I have compressed the art and story bible into
  one phase. They are different but they are
  executed at about the same time in the process
  and are linked because the producers and artists
  need to work together to create these documents.
• The art bible contains what the name implies. It
  defines the overriding art style that will be
  used, the tools to develop this art, and mock-ups
  to validate that approach. The story bible
  describes how the game will flow. It discusses
  the overriding objective of the game and how that
  objective will be expressed in various scenarios.
  

11
Technical specifications

• In this document the engineers detail the
  architecture of the game. It could be expressed
  in unified modeling language (UML) or with system
  diagrams. If development is to be object
  oriented, high-level objects and their
  interactions are defined. Core fundamental tools
  are defined and a platform for the game is
  recommended. The interactions between art assets
  and programming code are defined. Security and
  access methods might be part of the game
  technical specification.

12
Construction

• The decision is made to go ahead architecture
  and concept documents are completed the
  platforms have been established the full team is
  hired and the development environment is up and
  running. Then people begin to construct the game.
  The producers, managers, and project leads form
  the organizational glue within their respective
  disciplines and across organizational lines. The
  artists and developers begin to develop the game
  using all of the documents that have been
  previously developed.
• QA system test

13
QA system test

• Upon completion, pieces of the game go to the
  quality assurance (QA) organization, which takes
  all of the previously mentioned documents and
  tests the game against these documents. Any
  problems that are found are logged and reported
  back to the development teams. The development
  team responds by fixing the problems, redesigning
  certain key modules, or adding additional
  functionality.

14
Play testing

• Once the QA organization has an opportunity to
  give feedback to the development teams and the
  game is up in some working order, play testing
  begins. In this exercise, producers organize
  group sessions to demonstrate the play
  characteristics of the game. These sessions are
  usually attended by product and marketing
  managers as well as members of the development
  staff. The goal is to validate or critique the
  play characteristics of the game at that point in
  time. These sessions may occur a number of times
  during the testing cycle. Each play test session
  involves feedback that must be addressed by
  developers. The feedback can require cosmetic or
  fundamental changes to the game.

15
Alpha testing

• When producers, product managers, and developers
  agree that the game is ready for a wider
  audience, the producer will release the product
  to a select group of evaluators that provide
  feedback on the game.
• This feedback can result in required changes to
  the game. Some of these changes could be
  substantial. The assumption is that the changes
  will not be drastic in nature.

16

• Beta testing
• In this phase the game is released to a much
  wider audience with little knowledge of the game.
  People play the game and provide feedback on
  problems that occur, features they like or
  dislike, and the overall game experience. For
  console games it is difficult to get a
  comprehensive beta test because the game is
  usually kept inside the company that is making
  it. On the Web the first release of a game is
  frequently considered the beta test. Sometimes
  this is called release 1.0 and is quickly
  followed by a subsequent more robust release.

17

• Golden master or final release
• With all the feedback received and changes made,
  the game is released to the general public.

18
Defects in the GWPSo what is wrong with the
waterfall process?

• It has been used for years. It results in
  feedback along the way and everyone can be made
  aware of when each phase is complete. This way
  the development group and all people involved in
  the process are aware of the progress against the
  target date.
• If you look closely at this linear process you
  see that each phase exposes the game to different
  classes of observers. The test team does not see
  the product until after the developers determine
  it is time for them to see it. In some cases the
  product managers will not see the game until the
  developers schedule a play test. If play tests
  are not scheduled early in the cycle, product
  managers may not see the game until late in the
  cycle. Alpha evaluators may not see the game
  until very late in the cycle.

19

• The reality is that as each of these groups sees
  the game they may request drastic changes.
• This has a cascading effect, introducing problems
  into the game and sending the game back into
  phases that were expected to be complete, and
  possibly forcing the development team into
  emergency mode very late in the development
  cycle.
• The actual process may become very chaotic
  because the sequence of the waterfall development
  process has been broken. Development activity
  that should have occurred early in the cycle is
  actually occurring late in the cycle.
• Also, many unplanned mini-cycles may be occurring
  at the same time. These issues are common themes
  in game development post mortems.