MIT3643 Computer Games Development

1
MIT3643 Computer Games Development

• Lecture 14
• Game Project Management

2
Overview

• The requirements analysis, game design, and
  technical design phases have covered the most
  difficult part of project planning identifying
  the tasks we must perform.
• Second to identifying the tasks is estimating how
  long it will take to complete them.
• It is impossible at the start of the project to
  identify all the tasks that must be performed,
  and it is more than impossible to estimate
  exactly how long it will take to finish a
  creative and innovative game.
• However, failure to estimate the time required
  for a game project normally result in failure of
  the game project.

3
Success Criteria for Game Development

• Time
• Cost
• Quality
• Achieved through
• Project Management
• Quality Management

4
Responsibilities of a Project Manager

• defining lines of communication between
  departments and teams
• producing a quality project plan
• making sure appropriate components, tools and
  techniques are used
• analyse and control risk
• select people for the project
• organize project teams
• estimate work content and cost
• schedule work
• assign tasks to teams and team members
• monitor progress of project
• keep project on track.

5
Estimation

• For example, roughly one person-hour of effort
  to deliver two or three lines of finished program
  code on average. This includes all the effort
  from requirements analysis through coding to
  testing and delivery.

6
Two Interrelated Project Factors

• Game Project Size
• Game Project Complexity

7
Game Project Size

• Measured initially by the number of features, the
  amount of data and the number of players (Single
  / Multi-players).
• At completion of the project, it can be measured
  by the number of lines of code (LOC, or KLOC for
  thousands of lines of code) and the volume of
  data.

8
Project Complexity

• For a given size of game project, complexity will
  vary depending upon the genre of gameplay.

9
A Typical Estimation Method

• 1. Estimate the game size, using what you know
  about the game at the stage at which you are
  making the estimate.
• 2. Adjust the size to take account of the game
  complexity and various other factors such as the
  experience of the software engineers.
• 3. Convert the estimated LOC or other size
  measure into effort required.
• 4. Estimate the optimal time to complete the game
  development.
• 5. Estimate other properties of the software,
  such as expected defect rate and quality.

10
Function Point Analysis (FPA)

• Function point analysis is a well established
  technique for estimating the size and complexity
  of a game project.

11
Procedure of FPA (OO Approach)

• Working from the use cases that model the
  requirements, every use case that is connected to
  an actor (or may be several actors) outside the
  system boundary counts as an element of
  functionality. Call this count of the externally
  visible use cases FU.
• Every class in the class model of requirements
  counts as an element of stored data. Call this
  count FC.

12
Calculation of Function Points (FP)

• FP FU x WU FC x WC
• Adjusting factors basing on the complexity of
  uses cases and classes
• WU in the range 4 to 7 for use cases
• WC - in the range 7 to 15 for classes

13
Adjustment of the FP value

• FPadjusted FP X (0.65 0.01 X ?Fi)
• where the Fi are fourteen factors, each with an
  integer value in the range of 0 to 5 obtained in
  answer to the following questions.

14
Questions for the Fi

• Does the system require reliable back-up and
  recovery?
• Are data communications required?
• Are there distributed processing functions?
• Is performance critical?
• Will the system run in an existing, heavily
  utilized operational environment?
• Does the system require on-line data entry?
• Does the on-line data entry require the input
  transaction to be built over multiple screens or
  transactions?

15
Questions for the Fi (Contd)

• Are the master files updated on-line?
• Are the inputs, outputs or enquiries complex?
• Is the internal processing complex?
• Is the code designed to be reusable?
• Are conversion and installation included in the
  design?
• Is the system designed for multiple installations
  in different organizations?
• Is the application designed to facilitate change
  and ease of use by the user?

16
Determination of the value given to the
corresponding factor

• 0 no influence
• 1 incidental
• 2 moderate
• 3 average
• 4 significant
• 5 essential

17
Mapping from function points to lines of code
18
COnstructor COst MOdel (COCOMO)

• a simple means of converting from code size (in
  KLOCs) to effort in person-months and to optimal
  project duration in months.

19
Formula for effort E

• E a(KLOC)b person-months
• Where a is the nominal productivity, in
  person-months, to produce one thousand lines of
  code (1 KLOC) and b determines the degree of
  diseconomy of scale (if it is greater than 1) or
  economy of scale (if it is less than 1). So, for
  example, a million lines of code (1000 KLOC) is
  estimated as requiring proportionately twice as
  much effort if b 1.1 and four times as much if
  b 1.2, while it is estimated as requiring
  proportionately half as much effort if b 0.9.

20
Optimal project duration D

• DcEd
• where c is the basic duration, in months, per
  person-month and d gives a measure of the
  non-linearity larger projects should take a
  proportionately shorter time (for example by
  adding more people), so typically d should be
  less than 1.

21
Three classes of Game Project

• organic relatively small, simple game projects
  
• semi-detached intermediate projects in terms of
  size and complexity
• embedded complex online/multiplayer projects.

22
The parameter values for Basic COCOMO
Game
23
Example

• Consider the problem of developing an
  educational game for the primary students.
  Analysis of the problem produced a use case model
  and a class model. We shall use these models,
  together with function point analysis and COCOMO,
  to estimate the effort and time required to
  develop the Game for the kids.

24
Step 1 apply object-oriented function points

• FP FU x WU FC x WC
• 8 x 7 5 x 9 56 45 101
• FPadjusted 101 x (0.65 0.01 x 25) 101 x 0.9
  90.9
• Lines of code 90.9 x 30 lines of OO code per FP
  2700 lines

25
Step 2 apply COCOMO to obtain effort and duration

• Viewing the game as an exceptionally simple
  organic system,
• E 2.4 x 2.71.05 ? 6.8 person-months.
• The optimal duration is then
• D 2.5 x 6.80.38 ? 5.2 months.

26
Work Breakdown and Scheduling

• To decompose the overall task of developing the
  software into many much smaller activities, which
  are well defined, can be assigned to individual
  teams or persons and can be individually
  scheduled (allocate dates when the work will be
  done).

27
Two commonly used ways for Project Plan

• PERT (Program Evaluation and Review Technique)
  charts, which show the activities as boxes with
  lines joining them to indicate the
  interdependencies and flow of critical
  information
• Gantt charts, in which the horizontal direction
  represents time and the vertical direction
  represents activities, and which can be set out
  as tables, whose rows show when the work takes
  place, or as bar charts, whose horizontal bars
  show when the work takes place.

28
Sample Gantt Chart for a project
29
Sample PERT chart for a project