This is the second part in a series of design journals about constructing my own small RPG. It’s all open-source, licensed under a CC BY-SA 3.0 license; I will compile everything into a finished product at the end and make it available to those who want to try it out.
My local group is starting a new Dungeons and Dragons campaign (3.5), and thus, the past week or so I have been tossing ideas around for my new character. We’re going to be evil, rapacious pirates, so I’ve known that I wanted to take this chance to delve into the dark arts of necromancy, or perhaps dish out some fear-based effects.
So I designed a character who could do some of both of those things. Then I worked on a backstory, incorporating elements of a previously-conceptualized character I never got to play, and individualizing it for the group. After submitting the character backstory (a few thousand words) to my gaming group, I got a bit of cold feet on my build. I wanted to streamline my levels and feats, and instead of have a more gamey character (3 different classes in my 4 levels), I just wanted a smooth, simple character. Unfortunately, I had already written my backstory and had it approved (and worked into the plot).
I realized that my experience designing this character is a microcosm of the way that game-makers design games. I’m not breaking any new ground here; what I’m talking about is top-down vs. bottom-up design.
In building my character, I started with a bottom-up design. I built my character, piece-by-piece, and then described it at the end based on the finished product. Then, looking at the story, I decided that I wanted a different approach to building the character, so I let the story decisions inform the design aspects. Thus I switched, in the middle, from one approach to another. Neither of these was better than the other, and I found that using them in concert was actually very helpful in crafting a character that is flavorful and interesting.
Bringing Design Elements into the Game
I realized that it would be important for me to take a stance on whether I would use top-down design or bottom-up design when creating Inside.
A top-down design:
A top-down approach (also known as stepwise design) is essentially the breaking down of a system to gain insight into its compositional sub-systems. In a top-down approach an overview of the system is formulated, specifying but not detailing any first-level subsystems. Each subsystem is then refined in yet greater detail, sometimes in many additional subsystem levels, until the entire specification is reduced to base elements. A top-down model is often specified with the assistance of “black boxes”, these make it easier to manipulate. However, black boxes may fail to elucidate elementary mechanisms or be detailed enough to realistically validate the model. (from Wikipedia)
From a gaming perspective, top-down is the approach most commonly used by the indie developers. You can make a whole game based of a concept, such as werewolf cowboys in the old west (we’ll call it Lone Wolves) or something, and have each element of the overall idea inspire and inform your various mechanical elements. However, you run the risk of not having your pieces (the aforementioned elementary mechanisms) really work all that well (since they are married to a particular idea) or you might have mechanics that don’t really work well but seem forced in there to satisfy a pre-conceived plot element.
A bottom-up design:
A bottom-up approach is the piecing together of systems to give rise to grander systems, thus making the original systems sub-systems of the emergent system. Bottom-up processing is a type of information processing based on incoming data from the environment to form a perception. Information enters the eyes in one direction (input), and is then turned into an image by the brain that can be interpreted and recognized as a perception (output). In a bottom-up approach the individual base elements of the system are first specified in great detail. These elements are then linked together to form larger subsystems, which then in turn are linked, sometimes in many levels, until a complete top-level system is formed. This strategy often resembles a “seed” model, whereby the beginnings are small but eventually grow in complexity and completeness. However, “organic strategies” may result in a tangle of elements and subsystems, developed in isolation and subject to local optimization as opposed to meeting a global purpose. (from Wikipedia)
Bottom-up design would be a good way to describe the mechanics-based systems out there, the more simulationist games whose systems can be adapted to multiple situations. The goal is to make a strong infrastructure based off key core elements (say, rolling a d20), and then build outward from there. However, again, the pitfall is that you can spiral out of control and have too many elements and mechanics that work well in one situation and not in another.
I think it’s clear that I favor the top-down approach when it comes to designing Inside. I want to capture the flavor and feel of a noirish prison investigation, and I’m willing to sacrifice a little lower-order optimization in terms of mechanics (they don’t need to be infinitely adaptable because they won’t be adapted infinitely) to make the mechanics more closely meet my expectations for what elements one should encounter in a typical Inside scenario.
Next time: actually identifying what those elements are, and possibly trying to turn them into mechanics.
And since I don’t want to bury the top post, please click HERE to find out how to vote for Troll ITC for RPG site of the year. If you like the content we try to bring you, sidle on over to that voting page and cast your ballot.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License
Now, of course, the backstory can and will easily be modified to suit this particular character.