Dependencies - Designing Games - page 329

To implement goblin raids as planned, we first have to implement char-
acters , construction , wall constructions , and fighting systems. If any one of
these systems shifts significantly, changes will cascade upward through
the dependency stack and force changes in goblin raids . Even if each of
those foundational elements has an extremely favorable 80% certainty
tag, the chance of goblin raids working as expected is only 0.8 multiplied
with itself five times, or 0.33 (33%), because a failure in any one of the five
foundational elements will force goblin raids to change.
And most designs don't have nearly an 80% certainty rate. In design
work on risky, potentially breakthrough games, most designs fail. Per-
system certainty is often less than 30%. In these conditions, a design five
layers up the dependency stack will only survive unchanged 0.2% of the
time. So, basically, never.
Cascading uncertainty means that the upper elements of a dependency
stack almost always need major redesign.
This means that most of the written design of Fantasy Castle is
baloney. The foundational systems will almost certainly change when im-
plemented or tested, and those changes will cascade through the design,
forcing changes everywhere. The concepts may remain, but all the specif-
ics will change again and again. By the end of development, most of the
upper part of the stack will have been cut or redesigned several times.
It seems a simple bit of math, but there's a powerful truth here. Every
working designer has seen how much games—especially original ones—
transform over the course of development. But it's often hard to articulate
exactly why this happens. Simple uncertainty about the individual pieces
of a design isn't enough to explain it. The real problem is the way that
every change creates shockwaves of further changes that ripple through
the design via dependencies. This is the real culprit behind the massive
to-and-fro chaos of so many design processes. It's a key reason why we
have to iterate.
But not just any iteration will do. We have to iterate in a specific way,
as informed by the dependencies we've identified using the stack. The
general strategy is simple.
Start at the bottom of the dependency stack, and work upward through
each iteration loop.