Dependencies - Designing Games - page 328

imagined details of Fantasy Castle that I don't have space to write here. If
the design documents were written differently, the stack would look differ-
ent, even if all the titles were the same.
CasCaDing unCeRtainty
We've already seen how designs don't tend to work how we think they will.
The designers can write a document stating how goblin raids will work,
but they can't be certain it will work as expected until they build it and
playtest it.
This uncertainty is why we need to pay attention to dependencies. If
we assumed no uncertainty, it wouldn't matter in what order we did the
work. We would have our ideas, write them down, build them in any order,
and on the last day of development the design would click together per-
fectly, like a jigsaw puzzle. And in cases of very derivative designs based
on proven ideas, this can almost work, because every element of the design
is so certain.
But in games with some originality, written designs often don't trans-
late to reality. There is some probability that an element of the design will
need to change during development. And it's this uncertainty that makes
dependencies important.
Uncertainty multiplies through dependencies.
For example, the goblin raids system is described in a two-page sum-
mary somewhere in the design bible. It covers how and when the goblins
are spawned, the tactics they use, the capabilities they have, and strategies
for defeating them.
Like every plan, this design has some uncertainty level associated
with it. This uncertainty level reflects the likelihood that the design will
not work as expected. Let's assume it's a very unoriginal design, so the
certainty is 80%. The designers estimate that eight out of 10 times in this
situation, this system will work as written without major changes. That's
pretty solid.
But does that mean that, from the start of the design process, we can
be 80% sure that goblin raids will end up in the game as written?
Unfortunately not; that 80% figure only covers the uncertainty of the
goblin raids design itself. But goblin raids is not only vulnerable to changes
caused by failures in its own design. It's also vulnerable to changes caused
by failures in designs it depends on.