Friday, July 18, 2014

Dependency Stack

I recently finished reading a book called Designing Games by Tynan Syvester. It's a really great treatment of the basics of designing fun games. Near the end of the book he goes into the process of programming a game and the various organizational, team dynamic, communication issues etc.. that can arise.

http://tynansylvester.com/book/


One of the things he points out is that there's a relationship between game mechanics, level design and artwork. Essentially that a tiny tweak in a game mechanic might cause significant changes to all levels in the game some of which are hidden. These little changes can in turn affect the artwork in a game to the point were it might need to be redone.

He says that iteration is necessary because trying to plan the game out in its entirety at the start is doomed to fail. In order to reduce the burden of iteration he suggests mapping the dependencies between the different aspects of the game. He called it a dependency stack. It's used to figure out which things to work on now in which things to work on later.

When a dependency stack is built is you draw all the different aspects of the game such that a concept with a dependency on the fundamental concept of online as those from it to the fundamental concept. The more fundamental a concept lowered as in the diagram. Using this diagram is easy to see which concepts are the most fundamental and how changes to them will cascade through the whole system. The idea is you do the most core elements of the game first in until you a basic game consisting of just those items. This will allows you to reduce uncertainty in the interactions of those elements first before tacking other things.

I like this idea of a dependency stack. At Intelerad we've used similar techniques to map the relationships between various projects we have in the pipeline. Many of these projects have common core components. While every developer may carry around one of these diagrams in their head it very useful to put it down on paper because then it easier to communicate to those people who are making decisions about which project green light next.

Intelerad has been around a while and has a large amount of infrastructure in its software. Adding a new feature can sometimes cause a cascading series of changes that go all the way back to a central piece of infrastructure. Changes to the central piece of infrastructure and cause a cascade of changes up to the various pieces that depend on it. I suspect it would be possible to build a dependency stack which would attempt to explain the dependency relationships between various different pieces of our software. Using this dependency stack we could then demonstrate the risk of causing a cascading series of changes to its dependencies. Not to mention which other teams are likely to be brought in. When combined with a list of design deficiencies (design level technical debts) it could prove even more illuminating.

No comments: