Guest lecture on managing risk in video game development.

1. Risk Management
In Video Game Production
Dino Dini 2014

2. Cevat Yerli - Founder & CEO of Crytek
The way Yerli talks about discovering programming feels well-practiced, as do
most of his stories. It takes place around 1990, when he was only 12 years old
"I was playing a game called Kick Off, from a programmer called Dino Dini," Yerli
says, pronouncing his name carefully, almost reverently. "It combined my two
passions [soccer and games]. ... I played so long at this friend's place that I forgot
about time. It got [to be] late, late [in the] afternoon. The sun was going down and I
was supposed to be at home.
"I took my [bicycle], drove downhill and [was lost in] a daydream. And I just
snapped and the next thing I remember I was in a hospital."
Yerli was so consumed by thoughts of Kick Off that he smashed headlong into a
brick wall. He has no memory of the crash.
-Polygon interview 11/07/2013
Dino Dini 2014

3. Tool 1: Map of connected concepts
Risk Probability
Failure to
satisfy
clearly
defined
goals
Non
deterministic
processes
Project
failure
of
Unknowns
Knowns
Certainties Probabilities
Hard To
Measure
Easy To
Measure

4. Risk Probability
Failure to
satisfy clearly
defined goals
Non
deterministic
processes
Project failure
of
Unknowns
Knowns
Certainties Probabilities
Hard To
Measure
Easy To
Measure

5. Hard To
Measure
Easy To
Measure
Analysis is important. However, human nature means that
most often we focus on easy to measure things, regardless of
how effective they are in achieving our goals.

6. Hard To
Measure
Easy To
Measure
Pass Rates
Popularity
Scores
Revenue
Example of "Easy Bias": An educational establishment
Education
What is measured
What Matters

7. Hard To
Measure
Easy To
Measure
Budget
Features
Time
Example of "Easy Bias": The Video Game Industry
Entertainment
Value
What is measured
What Matters

8. Hard To
Measure
Easy To
Measure
More Objective
More
Subjective
There is often little faith in
subjective comparisons to track
progress, yet these usually matter
the most.
It is hard to argue with objective
comparisons, so these usually
overpower any analysis

9. Risk Unknowns
The more unknowns
you have, the greater
your risk
So… we should all eliminate
unknowns then, right?

10. Risk Unknowns
The more unknowns
you have, the greater
your risk
So… we should all eliminate
unknowns then, right?

11. Tool 2: Robust Triangles
Risk
Unknowns ?

12. Risk
The more unknowns
you have, the greater
your risk
Unknowns
This the the video game
industry. An artful
entertainment medium. It must
innovate, and innovation
increases unknowns.

13. Risk
The more unknowns
you have, the greater
your risk
Unknowns
Much of the important
development in video games
occurred in indie development
(before that was a term).

14. Risk
The more unknowns
you have, the greater
your risk
Unknowns
How can we compensate for
increasing unknowns?

15. Risk
Unknowns Flexibility

16. Risk
Unknowns Flexibility
FIXED
Choose
Between

17. Risk
Unknowns Flexibility
FIXED
Choose
Between

18. Risk
FIXED
Choose
Between
Unknowns Flexibility

19. Example on an unrobust triangle
Quality
Resources Time

20. Risk
Unknowns Flexibility

21. Often answers why. Groups more concrete concepts
More Abstract
More Abstract
Less AbsLterascst AbLsetrsasc At bstract
Often answers how.
Serves more abstract needs
Tool 3: Abstraction Graph

22. Flexibility Organising
complexity
How?
Negotiable
constraints
Abstraction
Simplification
Negotiable
time
Negotiable
budget
Negotiable
features
Reducing inter-dependencies
Priority List
Refactoring
Efficiency
?

23. Risk
Unknowns Flexibility

24. Reduce effect
of Unknowns Experience
How?
Prototyping
Hire
experienced
people
Training
Rapid
Protoyping
Prototyping
Budget
Analysis of
historical data /
Research
Faith in
(research)
process
Good
management
practices
Effective
assessment of
research value
Data driven
decision
making
Effective
procedures and
heuristics
Tools
Tools
Tools
Tools
Tools

25. Rapid
Prototyping Focus on core
player
experience
Quick and
flexible
development
environment
Develop set of
identifying
constraints Middleware (e.g.
Unity)
Design game
considering
production
issues

26. Reducing inter-dependencies
Game Design
Production
Process
Design
How?
Team
management
Heuristic:
Avoid circular
dependencies
Heuristic: Limit
dependencies
between
art/prog/design
Communication
Tools
Heuristic: Avoid
central points of
failure
Heuristic: TOC

27. Efficiency
Theory of
Constraints
(TOC)
How?
TOC supplies heuristics and methods that help
manufacturing to be efficient. However, it turns
out that these are also invaluable in software
development projects.

28. Efficiency
How? Heuristic: Keep
Theory of
Constraints
(TOC)
all inventory as
low as possible
Algorithm
Find the biggest bottleneck
Reduce it
Repeat continuously
Integrate as
you go
Do not
stockpile
Constantly
monitor your
'stock'
Reassign
personnel to
remove
backlogs

29. Development Process as a factory
Tool 4: Process Diagram
Process Inventory

30. Development Process as a factory
Specs Design Tasks Dev
Work To
Check
Finished
Product
Project
tracking
QA (Unit)
Verified
work
Work to
integrate
Work to
check
Defects
to find
Defects
Found
Integration
QA
(Product)
Defects
to Find
Design
Issues

31. Development Process as a factory
Specs Design Tasks Dev
Work To
Check
Finished
Product
Project
tracking
QA (Unit)
Verified
work
Work to
integrate
Work to
check
Defects
to find
Defects
Found
Integration
QA
(Product)
Defects
to Find
Design
Issues
QA gets harder
when there is
more stuff to
work through

32. Development Process as a factory
Specs Design Tasks Dev
Work To
Check
Finished
Product
Project
tracking
QA (Unit)
Verified
work
Work to
integrate
Work to
check
Defects
to find
Defects
Found
Integration
QA
(Product)
Defects
to Find
Design
Issues
Imagine the horror after
you have used most of
your time

33. Development Process as a factory
Specs Design Tasks Dev
Work To
Check
Finished
Product
Project
tracking
QA (Unit)
Verified
work
Work to
integrate
Work to
check
Defects
to find
Defects
Found
Integration
QA
(Product)
Defects
to Find
Design
Issues
What strategy would you use in this case?

34. Why stockpiles are bad
● Work can become obsolete due to design changes
● Work could be cut from the product due to time pressure
● Work 'rusts'
● Stockpiles get in the way
● Stockpiles interfere with each other (e.g. finding and understanding bugs)
● Represent risk (not worth anything until integrated)
● Stockpiles damage morale

35. Why do stockpiles happen?
● The feeling that everyone should be doing something
● Generating the impression of hard work for naive managers
● Bad communication
● Bad planning
● Bad management

36. Stockpiles are so bad...
● That they can outweigh the benefit of continuing to run a process
● Yes, this means that it can actually make things worse
● So you sometimes need the courage to turn a process off

37. I can't have people doing nothing!
● Yes, you can. They can take a break… come back refreshed...
● You can reassign them to some other task to help with a backlog
● You can get them to refactor their existing work (reducing the need for QA)
● You can assign them to QA if that is what is needed
● You can assign them low risk work
● You can assign them research tasks
Anything is better than making a bad situation worse!

38. Production
Process
Design
Design, Art and Programming all in one big
soup.
Integrate
QA
La-La-Land

39. Production
Process
Design
Design Art Programming
Integrate
QA
La-La-Land
Minimise
dependencies
between
tracks

40. Production
Process
Design
Design Art Programming Integration QA
Final testing and integration
Happy Land

41. What's Your Biggest Risk?
There now follows an important
heuristic for risk management..

42. What's Your Biggest Risk?
Always know your biggest risk and deal with it first.
Find the biggest risk
Mitigate it
Repeat continuously
How do we mitigate a risk? You know now...

43. Conclusion
(key points
covered)
Risk
Management
Minimise
unknowns and
their effects
Increase
Flexibility
Reduce
dependencies
Increase
Efficiency
Design &
management
TOC
Experience/
Expertise
Prototyping
Biggest Risk
Reduce scope

44. Thank you