Game Production: planning and risk

Transcription

1 Game Production: planning and risk Fabiano Dalpiaz 1

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) 2

3 Outline Lecture contents 1. Game plan: introduction 2. Schedules 3. Staffing and budgets 4. Outsourcing 5. Risk management 3

4 1. Game plan: introduction A refresher (recall the previous lecture) 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? 4

5 1. Game plan: introduction Conflicting forces The role of a producer in planning is to balance the following conflicting forces Without disrupting the project! Resources Schedule Quality Features 5

6 1. Game plan: introduction Conflicting forces: example 1 Scenario: more quality is demanded by the management How would you react? Resources Schedule Quality Features 6

7 1. Game plan: introduction Conflicting forces: example 1 Scenario: more quality is demanded by the management New resources shall be allocated More time (rescheduling) Re-prioritize the features Resources Schedule Quality Features 7

8 1. Game plan: introduction Conflicting forces: example 2 Scenario: some team members are re-allocated on a different project Again, how would you react? Resources Schedule Quality Features 8

9 1. Game plan: introduction Conflicting forces: example 2 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? Resources Schedule Quality Features 9

10 What do they contain? 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 10

11 The importance of milestones 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? 11

12 Who creates the schedule? 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 12

13 i. The initial schedule 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 13

14 i. Initial schedule: example (1/4) Justice Unit 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 Estimated Date Notes 14

15 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 15

16 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 16

17 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 17

18 ii. Work breakdown structure (WBS) 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 18

19 ii. WBS example (1/2) Art Tasks (Villain's Lair) Create prototype Implement prototype feedback Create level geometry Add placeholder textures Fix first round of bugs Create destructible objects Add final textures Create player reference map Create special effects Optimize level for budget constraints Polish map Fix final round of bugs Design Tasks (Villain's Lair) Design initial level layout Design initial mission scripting Script prototype Playtest prototype scripting Implement prototype feedback Script first pass of mission scripting Script first pass of multiplayer scripting Review scripting Script second pass Verify all supporting files are tagged correctly Create localization tags for in-game dialog Polish scripting Fix final round of bugs Duration 5 days 1 day 20 days 3 days 3 days 2 days 10 days.5 days 2 day 5 days 5 days 3 days Duration 2 days 2 days.5 days.5 days 1 day 5 days 2 days 1 days 5 days 1 day 1 day 3 days 2 days 19

20 ii. WBS example (2/2) Sound Tasks (Villain's Lair) Create sound design Implement sound design prototype Implement prototype feedback Complete first pass of sound implementation Polish sound Fix final round of bugs QA Tasks (Villain's Lair) Playtest prototype Test geometry and terrain navigation Check textures Test initial scripting Test second pass scripting Final test all level geometry and textures Final test for mission scripting Approvals (Villain's Lair) Approve initial layout Approve initial art prototype Approve initial design prototype Approve sound design Approve final level, scripting, and sound Duration 3 days 2 days 2 days 3 days 2 days 1 day Duration 1 day 7 days 2 days 1 day 1 day 5 days 1 day Duration 1 day 1 day 1 day 1 day 1 day 20

21 iii. Detailing the schedule 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 21

22 Scheduling: initial draft 15 days (with unlimited resources) 22

23 Scheduling: assigning resources 1 artist, 1 designer 1 sound designer 1 tester 1 manager = 63 days! 23

24 Scheduling: assigning resources Resources have limited time! 24

25 Scheduling: task dependencies With task dependencies (but no resource assignment): 77 days 25

26 Scheduling: resources AND task dependencies 81 days! 26

27 PERT diagrams 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 27

28 PERT diagram: an example What are nodes? What are arrows? 28

29 PERT diagram: two flavors 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 29

30 PERT diagram: two flavors Activity-on-node Activity-on-arrow 30

31 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 31

32 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 32

33 Dummy activities: no multiple tasks sharing start/end Not allowed!!! 33

34 Dummy activities: only one arrow for the same task How to do it? 34

35 Dummy activities: only one arrow for the same task How to do it? 35

36 Critical Path Method (CPM) 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 36

37 CPM: syntax ET Earliest time the node is reached, given activity duration and precedence relationships LT Latest time the node is reached, assuming no delays 37

38 CPM: what does it compute? 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 38

39 Illustrating the schedule: GANTT chart 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 reallocate resources and re-schedule if necessary No details here Pretty straightforward process (automated) Named after Henry Gantt, dates back to

40 A GANTT chart 40

41 Characteristics of a GANTT chart 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) 41

42 GANTT: pros and cons 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 42

43 3. Staffing and budgets Who is doing the tasks? The staffing plan determines who will perform the tasks Check the effect of alternative plans on the schedule 43

44 3. Staffing and budgets Creating a budget 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 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.) 44

45 3. Staffing and budgets Creating a budget Step 2: break the teams down! 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 45

46 3. Staffing and budgets Creating a budget Production Personnel Number Monthly Rate # of Months Cost Producer 1 $8, $192,000 Associate Producer 3 $6, $324,000 Step 3: create personnel budget Art Personnel Lead Artist 1 $10, $240,000 Technical Artist 1 $8, $192,000 Concept Artist 2 $6, $120,000 World Builder 10 $6, $720,000 Object Artist 3 $6,000 8 $144,000 Texture Artist 4 $6, $288,000 Marketing Artist 1 $6, $72,000 Animator 3 $8,000 8 $192,000 Engineering Personnel Lead Engineer 1 $10, $240,000 Networking Engineer 2 $8, $256,000 Graphics Engineer 4 $8, $576,000 UI Engineer 1 $8, $96,000 AI Engineer 4 $8, $576,000 Sound Engineer 1 $8, $96,000 Tools Engineer 3 $8, $432,000 General Engineer 5 $8, $720,000 AI Engineer 2 $8, $192,000 Design Personnel Lead Designer 1 $8, $192,000 Designer 4 $6, $432,000 Sound Designer 1 $6, $72,000 Writer 1 $6,000 6 $36,000 QA Personnel Lead QA Analyst 1 $8, $192,000 Tester 20 $6, $1,200,000 GRAND TOTAL 80 $7,792,000 46

47 3. Staffing and budgets Creating a budget Step 4: create other items 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 47

48 4. Outsourcing a.k.a., learning to trust others 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? 48

49 4. Outsourcing How to outsource? 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 49

50 5. Risk management Basic terms 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) 50

51 5. Risk management The risk event graph 51

52 5. Risk management How and why 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 52

53 5. Risk management The risk management process 53

54 5. Risk management Managing risk: identification and assessment 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 54

55 5. Risk management Step 1. Risk identification 55

56 5. Risk management Step 2. Risk assessment, scale 56

57 5. Risk management Step 2. Risk assessment with FMEA Failure Mode and Effects Analysis (FMEA) Impact Probability Detection = Risk Value 57

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. 58

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 59

60 5. Risk management Step 3. The risk response matrix 60

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 61

62 References Mandatory 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 (2010):

63 Further slides The critical path method explained! 63

64 CPM: step 1 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)= max j [ET(j)+ t(j,i)] where t(j,i) is the duration of task between nodes (j,i) 64

65 Calculating ET: example 65

66 Calculating ET: example 66

67 Calculating ET: example 67

68 Calculating ET: example 68

69 Calculating ET: example 69

70 CPM: step 2 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)= min j [LT(j) t(i,j)] where t(j,i) is the duration of task between nodes (j,i) 70

71 Calculating LT: example 71

72 Calculating LT: example 72

73 Calculating LT: example 73

74 Calculating LT: example 74

75 CFP: step 3 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 75

76 Critical activities, an example Task Duration ES EF LS LF Slack Critical Task A No B Yes C Yes D No E Yes 76

77 Critical activities, visualized 77