Slackful Thoughts

26 July, 2004: Game Design from the Bottom Up

Last week, I wrote about the two major processes of game development: the top-down approach where the theme dictates the mechanics of the game and guides the entire development process and the bottom-up approach, where a central game mechanic is selected first and the game grows organically from there. I gave the example of Prussia's Glory, a serious wargame, as an example of the top-down approach. This week, I'll write about Ascension at Firepeak as an example of the bottom-up process.

When Cory originally began the design of Ascension, he got the original idea from computer science. He's a software developer, and got to thinking about how data structures might look like when transported into a game context. He chose to look at a binary tree and see how he could transform a binary tree into a game. Thinking further on the issue, he decided that a tree constructed using strict rules, such as specific sorting rules and adjacency rules, might be an interesting problem to tackle. Armed with that central game mechanic, constructing a binary tree-like structure with specific construction rules, he created a prototype that was simply called "Pyramid".

In this prototype, he had a limited set of actions and only a few different types of cards. It worked, more or less, but it wasn't terribly interesting. It didn't have enough flavor. The central mechanic showed promise, but there needed to be more to it. At this point in the process, Cory began to think about possible themes. One possibility was a mafia theme. Another was a corporation. At the same time, he began to search for ways to make the game more interesting and dynamic, since the early prototypes had a very static feel to them.

Cory returned to his original inspiration, data structures, for the next element of the design. He added a stack to be used in tandem with the tree. Now, you had a couple of central mechanics to manage, and the game started to take on more texture and interest. It started playing less like a pure abstract and more like the more dynamic game that he wanted. It wasn't long after adding the stack that a theme finally suggested itself, that of dueling wizards controlling creatures. This not only gave the components of the pyramid faces, but it also suggested what the stack should represent (dungeons) and also suggested a third central mechanic, spells.

Adding the spells turned out to be the final piece of the puzzle. The additional chaos and hidden information that the spells added turned Pyramid into a dynamic, free-wheeling game rather than the somewhat stodgy abstract it was in earlier iterations. The theme, in this case, merely served to inspire possible additions to the set of mechanics in the game. It didn't dictate any aspects of the design, and didn't serve as a touchstone for further development. Instead, the focus remained squarely on the mechanics and how they interacted. As development moved forward through multiple rounds of playtesting, we were concerned solely with how the major game mechanics worked or didn't work. Changes were made in isolation more or less, with the only overarching concern being with how different elements interacted and game balance concerns. If we needed to add a new spell or remove a spell, we didn't have to worry how it fit into the overarching theme. We just made the change. The base of the game was what was important, the play, the balance and the smoothness and fun of the mechanics themselves.

Of course, the game design process doesn't have to be solely one direction or the other. Perhaps a game starts with a theme, starting as a top-down process, and it is discovered that the mechanics thus suggested don't work very well, but with a change in the theme, they might work extremely well. There can be push and pull between the mechanics and theme that can push a game towards where it needs to go. The game design process is a very iterative one, and it doesn't always follow a neat pattern, like any creative endeavor.

~ Joshua Buergel