Home of RPGs by Matt Snyder, including Dust Devils, Nine Worlds, 44: A Game of Automatic Fear, and The Ladykillers

A partial road map to RPG structure

When I decided to create an open game design (see the previous two posts here), I started sketching out a basic framework for the concept. I’ve been working on it in greater detail this week, and I offer it up here for review and discussion.

This chart outlines a “roadmap” of how characters and conflicts interact in games. It is not a comprehensive structure of an entire game, nor an attempt to model all RPGs. Rather, it’s just a model to show one common shape I’ve observed in games, especially the kinds of games that I think inform this project I have planned.

I intend the chart to be a reference point for design. It outlines “components” shown as boxes and arrow flows here. Each box could be swapped out with alternative mechanics, allowing individual designers to tailor their creations while still staying “on the map.”

Speaking of designers, I’m still eagerly looking for a small design team to design the core system using this chart as one of our guides.

Single Post Navigation

26 thoughts on “A partial road map to RPG structure”

I think your chart confuses two different ways of understanding mechanics: by what they represent in the story and what they represent mechanically.

For example, relationships and gear are story-groups. Motivators and special abilities are mechanic-groups. In some games, relationships are motivators, in others they’re traits. In some games, gear grants special abilities, in others it acts more like a trait.

You raise a good point. I understand very well the issues surrounding mechanics and story. I see what you mean on the chart, though I did it that way quite intentionally.

The boxes I’ve chosen could be broken down differently, without a doubt. This is just the way I chose to do it.

The “axis” you’re talking about, based on time (permanent –> tended –> temporary) is really interesting and useful. It’s partially evident in the chart, but not fully as you break it down.

The way I intended the chart, such breakdowns are possible “off” the chart as designers approach each component differently. Some may wish to make Gear permanent (a magic sword that always returns to you), tended (a wand that has only so many charges), or temporary (a table leg!). And so on.
So, the chart is a launch pad, a discussion piece to encourage others to figure out how to approach a design.

How/why are the six character elements broken into those three category(?) boxes?

Under REWARD LOOP, I think “currently” should be “currency.” Right?

Chris:

I’m completely not grokking your comment about story- v. mechanic-grouping of the character elements. It seems that each of those categories *can be* mechanically-integrated and *must be(?)* narratively-integrated. And if I’m understanding Matt, he’s just describing the kinds of things that generally go on character sheets (that point toward the conflict resolution system).

I do like thinking about the duration of the character elements as a separate axis like that, but any of the elements can land on any of the durational spaces. The various outcomes of conflict resolution can modify where an element lies along that axis, too.

Jason, I’m all for feedback across the board. The chart isn’t set in stone or anything. That said, I view suggestions through the lens of the several assumptions I spelled out in my previous blog entry, “Open game design project, Part 2.”

Hi George — I’m thinking of the prepared packages of Stunts they have in one of the later chapters of SotC.

As for games that have no attributes, yep. The column on the left explains that some games do not have all features, using Conspiracy of Shadows: Dirty Hands as an example. SotC is also an example, as is HeroQuest, and a few others.

Matt, are you thinking at all about mechanizing the way that conflicts fit into an overall story or into pacing mechanics? In a lot of “conflict resolution” games there is an art to determining the appropriate scale and scope to use when invoking the conflict resolution system, and a lot of games seem to rely on “indie games culture” to get the players to get it right rather than cooking it into the rules.

I agree with you, though. The thing you’re describing does happen, and I’m much more interested in crafting a game where this flows far more naturally. Oddly enough, one of the games I think does this best is the indie grandpa, Sorcerer. And, while that’s a big indie influencer, I think what it does procedurally is MUCH closer to traditional gaming than it may appear. There are not “stakes” or any of that formalized stuff. It’s just, stuff happens, you talk, you roll, you keep playing. More stuff happens. Etc.

Of course, the trick is communicating that in encoded rules, definitely.

Yes, development components could develop socially. It’s simply off this particular chart. Do you mean like, “Hey, it’d be even more cool if your guy was actually once married to her!” “Yeah, Ok! Let’s do that (scribbles note, spends points). Ok! Now he is!” ???

Yes, they’re all resources, I agree. But, I’m not sure why you don’t want discriminate among resources. That is, it strikes me as a matter of priority — what’s your aim in NOT discriminating (maybe because you assume designers will just figure that out regardless, so there’s no need delineating here) vs. what’s your purpose in discriminating (maybe the resources are quite mechanically distinct, and you want to segregate them so the “map” helps people avoid goofy distortions in play). Here, I’m saying “well, look, we can chop up resources in geeky-but-interesting ways, and let designers tinker with each kind.” Also, it’s not to say that these are components are exhaustive. I imagine there are other resource components I haven’t included with these six.

No, certainly not all outcomes are predicated on conflict. Suppose a Motivator awards points for being resolved. And, during play, everyone agrees, “Hey, you know what? After the rock concert, We all just basically agreed that Joe just exacted revenge on his ex without a roll! Weird.” Well, ok, so Joe gets his Motivator points. I suppose I’d want to ensure that such resolutions without conflict tension don’t become so “normal” that the game seems to wander as players tend to avoid the fruitful pressure of conflicts. (And, I’m sure there are other variations on the idea.)

I can’t figure out how conflicts happen without intent. But, that said, I think it’s actually pretty murky. What’s “intent” mean? And, whose intent are we talking about? I’m saying players encounter game situations and they (mostly intuitively) realize they want “what happens next” to go differently than what they sense (or are being told) just now. Conflict! And, it decides what happens next. I just like that is also creates mechanical pressure that allows other things to resolve as well. My design style has always worked that way.

I think this makes it easier to say: Circles in Burning Wheel is a relationship skill. In other words, it acts like a skill and involves relationships. The ‘Nifty Jetpack’ aspect is a gear motivator and skill. The Strength ability score is an attribute trait while the Athletics skill is a discipline.

I think on the macro scale you are better off atomizing things only as far as is necessary. So a box for “resources” makes more sense to me than four boxes all labeled “a special kind of resource” It’s an issue of taxonomy and clarity. Those special flavors deserve their own breakdown elsewhere.

I suspect that my tastes run too far toward structured freeform to be particularly useful when discussing conflict and intent for this project. You can effortlessly divide the two in Fiasco, for example. It is perfectly acceptable to stumble into scenes without an agenda, and there’s a sharp distinction between conflict (optional, sometimes emerging organically, sometimes a goal) and scene (the thing that gets resolved through the resource of procedural privilege). I don’t think it is where you are going with this, although it is a lovely place you should totally visit.

Hey Matt, how familiar are you with Object Oriented Programming? I ask because it’s a way of thinking about computer programming where (vast oversimplification) different components (“objects”) all interact in specific ways (“methods”). The upswing is that, once the methods between objects is set up, you can swap out individual objects as long as the new object has the same input/output methods. So there might be many “clock” objects, as long as each one outputs the time when queried by other objects.

It seems to me like you could turn all the arrows in your chart into methods, and all the blocks of text into objects. So the resolution object takes inputs of traits and gives outputs of success/fail and maybe magnitude of success/fail. Then you could design modular bits of game mechanics that fit that specification. Whether it uses cards or dice pools or spinning around until you fall over, as long as it takes inputs of traits and gives outputs of success/fail, it will work with the other game mechanic “objects.”

I think a lot of things go in that layer. We have spent the first half of our gaming lives focused on the first part and the biggest part of our “post discovered the Forge” part on the second. We need to discover all of the things which interface the two areas.

Any of these objects (boxes) could be split into sub-objects (as the character creation / character development boxes could be one object) as long as that set of sub-objects answered and received the same methods as the “parent” object would have.

I think this is about the minimal requirements for a functioning game. Anything beyond what’s here can be understood as a set of sub-objects filling the role of the parent. I think. 😉