Dependencies - Designing Games - page 327

Remember that the boxes in the stack aren't just the words you
see—each one represents a detailed design of several pages. The details
of these designs interlock. For example, the construction design describes
each button, highlight, and option of the interface players use to construct
things. Similarly, the farming design describes in detail how farms are
placed, managed, and removed. But the farming design assumes the con-
struction design is true and correct. What happens if the details in the
construction interface change—if the buttons are rearranged, or changed
to a mouse gesture interface? Construction is still in the game, but it has
changed, and now all the details of farming must be redesigned to match.
This is why farming is dependent on construction .
There are many more dependencies of this type than are written in
the stack. For example, I've placed walls above construction . But it's pos-
sible that during development, the designers may discover that they need
to change the construction interface to make placing walls easier. So walls
depends on construction , and construction depends on walls —a circular
dependency. And these threads of dependency are all over Fantasy Castle .
Walls may have to be changed to be easier to place around farms . The inven-
tion system may be affected by friendships , if friends can put one another
in inventive or uninventive moods. In a sense, everything can affect every-
thing else, so everything depends on everything else.
But some of these dependencies are stronger than others. Significant
changes in walls might, in some cases, affect construction . But changes
in construction will almost certainly affect walls . The dependency stack
deliberately ignores the weakest dependencies so that we can focus on the
most important and potentially dangerous ones. Finding this focus is the
stack's purpose.
The dependency stack is reductive. It leaves out important parts of
the reality of development. But when you're just a human, faced with a
problem as complex as a hundred interdependent design elements sharing
a hundred thousand relationships, intelligent reduction is the only way to
make progress. We have to ignore some dependencies or we'd sink into
analysis paralysis. The dependency stack isn't an academic exercise; it's a
tool for making decisions. And those decisions are best guided by focusing
on the strongest dependencies.
Depending on the details of the design, there may be more than one
way to construct a dependency stack. One could imagine a castle building
game in which there is construction , but no characters . Or one in which
there are goblin raids without walls . I've constructed this stack based on