Game Development Reference
In-Depth Information
be reorganized. Most of it should be regarded as no more than hypotheti-
cal ideas for the future. These elements shouldn't be interconnected into a
fixed plan because such an arrangement implies a certainty that we don't
have. Instead, they should be liquefied and placed in an unordered pool, to
be drawn from in the future. Only the pieces of the design that are going
to be worked on soon should be linked together and incorporated into the
official plan.
Rearranged this way,
Fantasy Castle
looks something like this:
My choice here was a judgment call. I committed to the community-
building elements of the design first, and moved everything else into the
design backlog. Another designer might have focused on combat or reli-
gion. But whatever the choice, the point is that we're acknowledging that
we have to start somewhere and iterate there before we build upward from
that foundation. Otherwise, we're building on a foundation of sand.
Anything higher on the stack than those three base elements would
be exposed to excessive cascading uncertainty and so wouldn't be worth
implementing. At the paper design stage, that would likely push certainty
below 50%. But as we implement, study, research, and test those three
elements, their certainty will increase. The
farming
system, for example,
will go from a design on paper with, say, 60% certainty, to a functional,
playtested design with 90% certainty or better. It may change during itera-
tion of it or its foundation, but that's not a problem since nothing depends
on it yet.
