Dependencies - Designing Games - page 330

We start at the bottom, with the pieces of the design that depend
on nothing. After that foundation has been iterated and playtested a few
times, it becomes more certain. On paper it might have been 40% certain,
but once we've redesigned it through a few playtests, it might reach 90%
certainty. Next, we can build the elements that depend on that founda-
tion and have confidence that they won't get torn apart by later changes
cascading up from below. And we just work our way up the stack this way,
building upward. Unexpected design results will still appear and shake
the whole structure, but we reduce their frequency and impact by doing
our work in the right order.
For example, in Fantasy Castle we might start developing the game
with nothing but basic characters , construction , and walls . At first, it's just
a game about people building walls. Once those have been iterated a few
times and work well, we might add farming . Once that's been iterated a
few times, we put in trading and seasons . We work our way up, building a
tower of dependencies from foundations upward. And the design is likely
to change partway through—we may feel after playtesting farming that
seasons are unnecessary, but a new crop diseases element would add more
interest. So the top of the stack re-forms as the bottom solidifies.
tHe Design BaCklog
Just because designs at the top of the stack are very uncertain doesn't
mean they're worthless. We have thoughts, ideas, and observations all the
time, and that inspiration should be recorded because it is valuable. But
writing them in an interlocking, detailed design requires a lot of work that
is likely to be invalidated by cascading uncertainty.
The solution is to retain the ideas in a liquid, noninterlocking form, by
recording them in a design backlog .
The DESIGN BACKLOG is an unordered, liquid reservoir of ideas,
concepts, and impressions that aren't being worked on and won't be
worked on soon. Most ideas should go in the design backlog.
The design backlog is named after a similar concept from the popular
Scrum software development methodology, the product backlog . However,
unlike Scrum, it isn't intended to be part of a formalized development
process. It's an informal tool for retaining inspiration.
So just because most of the Fantasy Castle design is baloney due to
cascading uncertainty doesn't mean it's worthless. Rather, it should just