game production: planning and risk · 2 acknowledgment these slides are based on chapter 11 of...
TRANSCRIPT
2
Acknowledgment
These slides are based on
Chapter 11 of Chandler’s book
Chapter 7 of “Project management: the managerial process”, fifth edition, Erik W. Larson and Clifford F. Gray
Slides from the “G64SPM - Software Project Management” course held at the University of Nottingham (2008/09)
3
Outline
1. Game plan: introduction
2. Schedules
3. Staffing and budgets
4. Outsourcing
5. Risk management
Lecture contents
4
1. Game plan: introduction
The game plan details
What work must be done
In what order the work is done
Who will do the work
When the work must be completed
Assembled on the basis of the requirements
… but the requirements can (do) change after the initial game plan is completed
Why?
A refresher (recall the previous lecture)
5
1. Game plan: introduction
The role of a producer in planning is to balance the following conflicting forces
Without disrupting the project!
Conflicting forces
Resources Schedule
Quality Features
6
1. Game plan: introduction
Scenario: more quality is demanded by the management
How would you react?
Conflicting forces: example 1
Resources Schedule
Quality Features
7
1. Game plan: introduction
Scenario: more quality is demanded by the management
New resources shall be allocated
More time (rescheduling)
Re-prioritize the features
Conflicting forces: example 1
Resources Schedule
Quality Features
8
1. Game plan: introduction
Scenario: some team members are re-allocated on a different project
Again, how would you react?
Conflicting forces: example 2
Resources Schedule
Quality Features
9
1. Game plan: introduction
Scenario: some team members are re-allocated on a different project
Deadlines may have to be postponed
Should quality be lowered?
Can some features be dropped?
Conflicting forces: example 2
Resources Schedule
Quality Features
10
2. Schedules
Schedules are a crucial means to define a plan
They define
Tasks to be completed
• Implement character XYZ
• Implement the load/save menu
• Create music for level 1
Estimated task duration
• In business terms, a week is 40 hours
Responsible/performer for a task
• They may be different – why?
Dependencies among tasks
• Testing XYZ cannot start before the implementation of XYZ is over
What do they contain?
11
2. Schedules
Milestones are events of high importance
Often put at the end of a stage
Milestones often imply rescheduling
Are we lagging behind?
Are we just in time?
Are we ahead of schedule? (rare)
Continuous rescheduling is hardly possible
… that’s why milestones are used
Any examples of milestones?
The importance of milestones
12
2. Schedules
The producer should involve the entire team
Team members know feasibility better for their own parts
This creates cohesion in the team
Team members feel the schedule is their schedule, and not a mandated one
The ultimate decision is up to the producer though
He is the one who is responsible for delivering the game
Who creates the schedule?
13
2. Schedules
This is created in preproduction and communicated to the development team
Objective: plan for key days
Consists of exit criteria (task/phase outcomes) for each area of the game
Fill in estimated dates
Where to start from?
Take already produced documentation
• Feature lists
• Deliverables
• Art/design/technical documentation
i. The initial schedule
14
2. Schedules
i. Initial schedule: example (1/4)
Justice UnitEstimated
Date Notes
Languages: English, German, French, Italian, Spanish
Production
Concept Phase Completed
Requirements Phase Completed
Initial Game Plan Completed
First Playable
Alpha
Code Freeze
Beta
Pre-Cert Submission to Microsoft
Code Release Candidate
Certification Submission to Microsoft
Approvals
Concept Approval
Requirements Approval
Game Plan Approval
License Approval
Console Manufacturer Approval
15
2. Schedules
i. Initial schedule: example (2/4)
Design
Deliverables Completed for Concept Phase
Deliverables Completed for Requirements Phase
Detailed Documentation Completed for Game
Features
Character and Story Documents Completed
Voiceover Scripts Completed
Mission and Scenarios Designed
Mission Prototypes Scripted
Playtesting
Final Missions Scripted
Art
Deliverables Completed for Concept Phase
Deliverables Completed for Requirements Phase
Prototypes Completed
First Playable Level Completed
Special Effects Completed
UI Completed
Cinematics Completed
16
2. Schedules
i. Initial schedule: example (3/4)
Engineering
Deliverables Completed for Concept Phase
Deliverables Completed for Requirements Phase
Art and Design Tools Completed
Production Pipeline Completed
Engineering Prototypes Completed
All Major Game Play Features Implemented
Code Freeze
Audio
Sound Designs Completed
Sound Prototypes Complete
Placeholder VO Recorded
Final VO Recorded
Final Music Implemented in Game
Localization
Determine Localization Needs
Organize Assets for Translation
Integrate Assets
Functionality Testing
Linguistic Testing
17
2. Schedules
i. Initial schedule: example (4/4)
QA
Test Plan Completed
First Playable Testing Completed
Alpha Testing Completed
Playtesting Completed
1st Code Release Candidate to QA
Code Release
Cinematics (External Vendor)
Deliver Initial Specs to Vendor
Storyboard from Vendor
Animatic from Vendor
Rough Cut from Vendor
Final Movie from Vendor (no sound)
Movie to Sound Designer
Final Movie Ready for Game
Marketing
Demo Build
E3 Build
Preview Code for Journalists
Review Code for Journalists
18
2. Schedules
A technique for breaking large tasks into smaller ones
Usually created with the joint effort of producers and team leaders via brainstorming meetings
From exit criteria to tasks
Sample process
1. Define the main assets to create: e.g., levels/missions
2. Identify the tasks/features to be completed for each step
3. Group the tasks by department (art, engineering, …)
4. Place the tasks in rough chronological order
5. Set durations for each task
ii. Work breakdown structure (WBS)
19
2. Schedules
ii. WBS example (1/2)Art Tasks (Villain's Lair) Duration
Create prototype 5 days
Implement prototype feedback 1 day
Create level geometry 20 days
Add placeholder textures 3 days
Fix first round of bugs 3 days
Create destructible objects 2 days
Add final textures 10 days
Create player reference map .5 days
Create special effects 2 day
Optimize level for budget constraints 5 days
Polish map 5 days
Fix final round of bugs 3 days
Design Tasks (Villain's Lair) Duration
Design initial level layout 2 days
Design initial mission scripting 2 days
Script prototype .5 days
Playtest prototype scripting .5 days
Implement prototype feedback 1 day
Script first pass of mission scripting 5 days
Script first pass of multiplayer scripting 2 days
Review scripting 1 days
Script second pass 5 days
Verify all supporting files are tagged correctly 1 day
Create localization tags for in-game dialog 1 day
Polish scripting 3 days
Fix final round of bugs 2 days
20
2. Schedules
ii. WBS example (2/2)
Sound Tasks (Villain's Lair) Duration
Create sound design 3 days
Implement sound design prototype 2 days
Implement prototype feedback 2 days
Complete first pass of sound implementation 3 days
Polish sound 2 days
Fix final round of bugs 1 day
QA Tasks (Villain's Lair) Duration
Playtest prototype 1 day
Test geometry and terrain navigation 7 days
Check textures 2 days
Test initial scripting 1 day
Test second pass scripting 1 day
Final test all level geometry and textures 5 days
Final test for mission scripting 1 day
Approvals (Villain's Lair) Duration
Approve initial layout 1 day
Approve initial art prototype 1 day
Approve initial design prototype 1 day
Approve sound design 1 day
Approve final level, scripting, and sound 1 day
21
2. Schedules
The WBS has to be refined
Define the exact ordering
Identify dependencies
Assign team members
Guidelines
Keep the tasks small (a few days)
The task assignee (owner) has to agree
Never leave the task duration blank
Allow for extra time
• Sick days
• Vacations
• Known unknowns, unknown unknowns
Do not schedule overtime
Assume employees will be productive 5-6 hours in a day
iii. Detailing the schedule
22
2. Schedules
Scheduling: initial draft
15 days (with unlimited resources)
23
2. Schedules
Scheduling: assigning resources
1 artist, 1 designer 1 sound designer 1 tester 1 manager=63 days!
24
2. Schedules
Scheduling: assigning resources
Resources have limited time!
25
2. Schedules
Scheduling: task dependencies
With task dependencies (but no resource
assignment): 77 days
26
2. Schedules
Scheduling: resources AND task dependencies
81 days!
27
2. Schedules
Program Evaluation and Review Technique
It is a network model that allows for randomness in activity completion times
Tool used to control the length of projects
Educational tool for project managers
Supported by several tools
PERT diagrams
28
2. Schedules
What are nodes?
What are arrows?
PERT diagram: an example
29
2. Schedules
Activity-on-node diagrams
Nodes represent activities
Arrows indicate precedence constraints
May have more than one single start and end node
Activity-on-arrow diagrams
Arrows represent activities
Nodes indicate synchronization points
One single start and one single end node
PERT diagram: two flavors
30
2. Schedules
PERT diagram: two flavors
Activity-on-node
Activity-on-arrow
31
2. Schedules
Activity-on-arrow PERT diagrams
Some basic rules
Tasks are represented as arrows
Nodes represent the start and finish points of tasks
There is only one overall start node
There is only one overall finish node
Two tasks cannot share the same start and end node
32
2. Schedules
Dummy activities
Sometimes it is necessary to insert dummy activities (duration zero)
To maintain the clarity of the diagram
To indicate precedence relationships between activities
In activity-on-arrow PERT diagrams, each activity must be uniquely identifiable by its start and end nodes
However, sometimes multiple tasks have the same predecessors and successors
33
2. Schedules
Dummy activities: no multiple tasks sharing start/end
Not allowed!!!
34
2. Schedules
Dummy activities: only one arrow for the same task
How to do it?
35
2. Schedules
Dummy activities: only one arrow for the same task
How to do it?
36
2. Schedules
CPM determines the total calendar time required for the project
It is determined by adding the times for the activities in each sequence
Computes the critical path: a sequence of activities that, when delayed, also delay the entire project
Activities outside the critical path can speed up or slow down (within limits) without affecting the total project time
The amount of time that a non-critical activity can be delayed without delaying the project is called slack-time
Critical Path Method (CPM)
37
2. Schedules
ET – Earliest time the node is reached, given activity duration and precedence relationships
LT – Latest time the node is reached, assuming no delays
CPM: syntax
38
2. Schedules
ES – Activity earliest start time
LS – Activity latest start time
EF – Activity earliest finishing time
LF – Activity latest finishing time
Slack Time – Maximum activity delay time
Details on the algorithms in the slides at the end of the slide deck
CPM: what does it compute?
39
2. Schedules
A GANTT chart is a type of bar chart that illustrates a project schedule
After the PERT/CPM analysis is completed, the following phase is to construct the GANTT chart and then to re-allocate resources and re-schedule if necessary
No details here
Pretty straightforward process (automated)
Named after Henry Gantt, dates back to 1910-1915
Illustrating the schedule: GANTT chart
40
2. Schedules
A GANTT chart
41
2. Schedules
The bar in each row identifies the corresponding task
The horizontal position of the bar identifies start and end times of the task
Bar length represents the duration of the task
Precedence relationships are represented using arrows
Critical activities are usually highlighted
No specific syntax though
Relation with PERT
An activity’s bar begins at the activity earliest start time (ES)
An activity’s bar ends at the activity latest finish time (LF)
Characteristics of a GANTT chart
42
2. Schedules
Advantages
Simple
Good visual communication to others
Task durations can be compared easily
Good for scheduling resources
Disadvantages
Dependencies are more difficult to visualize (than PERT)
Minor changes in data can cause major changes in the chart
GANTT: pros and cons
43
3. Staffing and budgets
The staffing plan determines who will perform the tasks
Check the effect of alternative plans on the schedule
Who is doing the tasks?
44
3. Staffing and budgets
A budget has to include all the costs associated with the project
Personnel
Overhead (rent, utilities, taxes)
Hardware
Software
Create the budget based on game requirements
Step 1: create a list of the major line items
Creating a budget
Personnel Costs
Art Personnel
Design Personnel
Engineering Personnel
Production Personnel
QA Personnel
Audio Personnel
Other Major Costs
Hardware
Software
IP Licensing Fees
External Vendors
Food
Shipping
Office Supplies
Overhead (HR benefits, insurance, office space, etc.)
45
3. Staffing and budgets
Step 2: break the teams down!
Creating a budget
Art Personnel
Art Director
Lead Artist
Concept Artist
World Builder
Asset Artist
Animator
Technical Artist
Marketing Artist
Design Personnel
Creative Director
Lead Designer
Designer
Writer
Engineering Personnel
Technical Director
Lead Engineer
Networking Engineer
Sound Engineer
Tools Engineer
AI Engineer
Gameplay Engineer
Production Personnel
Executive Producer
Producer
Associate Producer
QA Personnel
Lead QA Analyst
Tester
46
3. Staffing and budgets
Step 3: create personnel budget
Creating a budgetProduction Personnel Number Monthly Rate # of Months Cost
Producer 1 $8,000 24 $192,000
Associate Producer 3 $6,000 18 $324,000
Art Personnel
Lead Artist 1 $10,000 24 $240,000
Technical Artist 1 $8,000 24 $192,000
Concept Artist 2 $6,000 10 $120,000
World Builder 10 $6,000 12 $720,000
Object Artist 3 $6,000 8 $144,000
Texture Artist 4 $6,000 12 $288,000
Marketing Artist 1 $6,000 12 $72,000
Animator 3 $8,000 8 $192,000
Engineering Personnel
Lead Engineer 1 $10,000 24 $240,000
Networking Engineer 2 $8,000 16 $256,000
Graphics Engineer 4 $8,000 18 $576,000
UI Engineer 1 $8,000 12 $96,000
AI Engineer 4 $8,000 18 $576,000
Sound Engineer 1 $8,000 12 $96,000
Tools Engineer 3 $8,000 18 $432,000
General Engineer 5 $8,000 18 $720,000
AI Engineer 2 $8,000 12 $192,000
Design Personnel
Lead Designer 1 $8,000 24 $192,000
Designer 4 $6,000 18 $432,000
Sound Designer 1 $6,000 12 $72,000
Writer 1 $6,000 6 $36,000
QA Personnel
Lead QA Analyst 1 $8,000 24 $192,000
Tester 20 $6,000 10 $1,200,000
GRAND TOTAL 80 $7,792,000
47
3. Staffing and budgets
Step 4: create other items budget
Creating a budget
Hardware Number Rate Cost
Computers 80 $3,000 $240,000
Console Development Kits 40 $10,000 $400,000
Controllers 60 $100 $6,000
Graphics Cards 80 $300 $24,000
Software
Perforce 76 $750 $57,000
3DSMax 19 $4,000 $76,000
Photoshop 4 $600 $2,400
MS Project 5 $1,000 $5,000
Unreal 3.0 Engine 1 $1,000,000 $1,000,000
Visual C++ 23 $3,000 $69,000
Licensing Fees
Justice Unit Royalty 1 $500,000 $500,000
External Vendors
Voiceover 1 $250,000 $250,000
Music 1 $50,000 $50,000
Cinematics 1 $300,000 $300,000
Localization 4 $50,000 $200,000
Other \
Travel 24 $1,000 $24,000
Food 24 $500 $12,000
Shipping/Postage 24 $200 $4,800
GRAND TOTAL $3,220,200
48
4. Outsourcing
Outsourcing means assigning responsibilities for parts of a product/project (here, a game) to external vendors
Outsourcing allows to save time and money
Pick tasks that are not dependent on inter-team work. Mainly design- and art-related tasks
Cinematics and animation
Motion capture
Voiceover
Music
Sound effects
Writing
Localization
Outsourcing engineering is more risky. Why?
a.k.a., learning to trust others
49
4. Outsourcing
Before contacting an external vendor, define exactly what is the scope of the work to outsource
Provide as much information as possible about the game
Align the external vendor with the game’s vision
Drawbacks of outsourcing
Lost flexibility to reschedule tasks
Risk: will the vendor deliver on time?
Tricks
Keep an effective communication
Avoid involving multiple people in the communication
Make informed choice about which vendor to rely upon
How to outsource?
50
5. Risk management
Risk: uncertain or chance events that planning can not overcome or control
Risk Management: a proactive attempt to recognize and manage internal events and external threats that affect the likelihood of a project’s success.
What can go wrong (risk event)
How to minimize the risk event’s impact (consequences)
What can be done before an event occurs (anticipation)
What to do when an event occurs (contingency plans)
Basic terms
51
5. Risk management
The risk event graph
52
5. Risk management
How?
A proactive rather than reactive approach
Why?
Reduces surprises and negative consequences
Prepares the project manager to take advantage of appropriate risks
Provides better control over the future
Improves chances of reaching project performance objectives within budget and on time
How and why
53
5. Risk management
The risk management process
54
5. Risk management
Step 1: Risk Identification
Generate a list of possible risks through brainstorming, problem identification and risk profiling.
• Macro risks first, then specific events
Step 2: Risk Assessment
Scenario analysis for event probability and impact
Risk assessment matrix
Failure Mode and Effects Analysis (FMEA)
Probability analysis
Semi-quantitative scenario analysis
Managing risk: identification and assessment
55
5. Risk management
Step 1. Risk identification
56
5. Risk management
Step 2. Risk assessment, scale
57
5. Risk management
Step 2. Risk assessment with FMEA
Failure Mode and Effects Analysis (FMEA)Impact × Probability × Detection = Risk Value
58
5. Risk management
Step 3. Managing risk: response development
Step 3: Risk Response Development
Mitigating Risk
• Reducing the likelihood an adverse event will occur.
• Reducing impact of adverse event.
Avoiding Risk
• Changing the project plan to eliminate the risk or condition.
Transferring Risk
• Paying a premium to pass the risk to another party.
• Requiring Build-Own-Operate-Transfer (BOOT) provisions.
Retaining Risk
• Making a conscious decision to accept the risk.
59
5. Risk management
Step 3. Contingency planning
Contingency Plan
An alternative plan that will be used if a possible foreseen risk event actually occurs
A plan of actions that will reduce or mitigate the negative impact (consequences) of a risk event
Risks of Not Having a Contingency Plan
Having no plan may slow managerial response
Decisions made under pressure can be potentially dangerous and costly
60
5. Risk management
Step 3. The risk response matrix
61
5. Risk management
Step 4. Managing risk: control
Risk control
Execution of the risk response strategy
Monitoring of triggering events
Initiating contingency plans
Watching out for new risks
Establishing a Change Management System
Monitoring, tracking, and reporting risk
Fostering an open organization environment
Repeating risk identification/assessment exercises
Assigning and documenting responsibility for managing risk
62
References
1. Hartmann, Sönke, and Dirk Briskorn. “A survey of variants and extensions of the resource-constrained project scheduling problem.” European Journal of Operational Research 207.1 (2010): 1-14.
Mandatory
63
Further slides
The critical path method explained!
64
2. Schedules
Step 1. Calculate ET for each node
For each node i for which predecessors j are labelled with ET(j), ET(i) is given by:
ET(i)= maxj [ET(j)+ t(j,i)]
where t(j,i) is the duration of task between nodes (j,i)
CPM: step 1
65
2. Schedules
Calculating ET: example
66
2. Schedules
Calculating ET: example
67
2. Schedules
Calculating ET: example
68
2. Schedules
Calculating ET: example
69
2. Schedules
Calculating ET: example
70
2. Schedules
Step 2. Calculate LT for each node
For each node i for which successors j are labelled with LT(j), LT(i) is given by:
LT(i)= minj [LT(j) – t(i,j)]
where t(j,i) is the duration of task between nodes (j,i)
CPM: step 2
71
2. Schedules
Calculating LT: example
72
2. Schedules
Calculating LT: example
73
2. Schedules
Calculating LT: example
74
2. Schedules
Calculating LT: example
75
2. Schedules
Step 3. Calculate processing times for each activity
For each activity X with start node i and end node j:
ES(X) = ET(i)
EF(X) = ES(X) + t(X)
LF(X) = LT(j)
LS(X) = LF(X) – t(X)
Slack Time (X) = LS(X) – ES(X) = LF(X) – EF(X)
Where t(X) is the duration of activity X
An activity with zero slack time is a critical activity and cannot be delayed without causing a delay in the project
CFP: step 3
76
2. Schedules
Critical activities, an example
Task Duration ES EF LS LF Slack Critical Task
A 3 0 3 5 8 5 No
B 4 0 4 0 4 0 Yes
C 7 4 11 4 11 0 Yes
D 5 3 8 8 13 5 No
E 2 11 13 11 13 0 Yes
77
2. Schedules
Critical activities, visualized