Dependencies - Designing Games - page 336

Once the core is iterated a few times, it will be certain enough to
build on. Only then should we draw something from the backlog, because
there's a good chance that speed and spin-kick will change before that
happens, or we'll have a better idea to build on top of them.
DePenDenCies anD exteRnal Design neeDs
There's a caveat to the dependency stack. Marketing and businesspeople
might need design decisions long before the game does.
In these cases, designers should negotiate to find some middle ground
with the person who needs the design decision. If the decision is high in
the stack and very detailed, the business or marketing benefit of providing
these extremely early decisions might not outweigh the cost of making
them so early. For example, it's probably not worth advertising Capp's
sweep dodge move until it's been iterated, because it's so likely that sweep
dodge will be twisted by cascading design changes.
Marketing and business are important. But at the same time, we
shouldn't lock a game design into a prison of unchangeable design deci-
sions. Stay fluid, don't assume the future, and pay attention to dependency-
driven risk. It takes daily effort, and not everybody will understand at first.
It can feel wasteful, even irresponsible. But in the end, it's the only way to
do a task as hard as game design with small human minds.