anyway.

Yeah, when I read you talking about subsystems, I was thinking about mechanical weight. Giving mechanics to do a thing in a game says, "This thing here is important." A subsystem provides both emphasis and distinction for a certain set of activities.

Is this right?

IAWA has two subsystems:
1) The Oracle / Prep system (through best interests)
2) The dice conflict system

And two links:
1) The We Owe list (which is explicit and easy)
2) The Particular Strengths (which is trickier, qua RPA discussion)

Are those labels right/wrong?  Or do you throw IAWA in with unified mechanics?

1000x yes. The more unified the mechanism the worse it is at supporting any specific thing. OTOH, the less unified the mechanisms the more difficult the game is to learn.

Which is why in theory at least I think the paradigm under which I would like others to design games I'll play is hierarchal mechanics.
-One unified mechanism that's trivial to learn (e.g. when in doubt GM decides, or flip a coin, etc).
-Several narrower mechanisms that are still easy to learn for focus areas of the game (e.g. roll Diplomacy, or bloody versus, etc).
-Even more detailed resolution (which may take effort to learn) to spotlight/support a specific type of thing in the game (or even session!) (e.g. skill challenge, Fight!, etc).

Can you tell I think Burning* does this well? :)

(you can also apply the separate-mechanisms principle to charity in real life)

Thanks.

So I'm going to veer this off the rails.

You say:
I'm a big believer in what a game "calls for," by the way. When you hit upon the subject matter for a game, way back in the early conceptual stages, having done no design work at all - you're already committing, sight unseen, to its subsystems.

How do you feel about realizing, midway through a game design, that it doesn't do what you want it to do, but it does another thing, also worth doing, very well? I was coping with that recently (I reconciled myself to rewriting the rest of the game, since the thing that my game did well was, in fact, better than the thing that I wanted it to do originally.) But here you seem to be presenting a relatively continuous line of development, with a clear goal. Where's the messiness?

What you say about subsystems is, of course, true. But there's a thing. Second post.

yrs—
—Ben

So, subsystems. In your letter to a friend, you make it sound like each subsystem is a totally standalone thing. But they're not at all like that.

For instance, I had a really neat scene-setting up system in Polaris. All in all, I think it was probably one of the better possible scene-setting-up systems. It just turned out that the game didn't actually need a scene-setting-up system, at all, and that it's presence was gumming up the works of the game as a whole.

So likewise, you could have a really good physical confrontation system, and them mid-stream go "you know, this is really distracting from the rest of the game?" Chuck it.

Likewise, you could have a non-totally-awesome physical confrontation system, that makes afficianados of physical confrontation systems cringe and whine about how lame it is, but it works well with the rest of the game. In it goes!

In other words, we operate as designers in the context of the game as a whole, and all subsystems must combine in order to produce a strong experience of the game as a whole, regardless of their individual quality if you take them out and examine them separately.

You're cool with this, I imagine. But it probably needs to be said alongside this post.

There is an argument that when you remove the magnifying glass, apparently different conflicts are so similar that you can use the same abstract system. This is what was special about the Dying Earth. Having the "best six subsytems" does not necessarily mean the game will be better as an emergent property.

Also, the exception based approach gives you a global, easily understandable system which can be customised.

"Six best subsystem" games also have the negative property of requiring longer to learn and making the game more complex.

Seth: Maybe! I have a crotchety opinion about that one - providing mechanics for something certainly distinguishes it, but I don't think it necessarily emphasizes it - so let me come back to that sometime.

Ryan: I'd just call all of those subsystems.

Guy: Yeah! One of the best and most obvious ways to integrate subsystems with one another is to have them require the same thing from the players. For instance, "roll 2d6 and add the appropriate stat" might be common to half the subsystems in a game.

Ben: Messiness: Huh. I'm like "yay messiness!" in principle, but I can't think of a time that happened to me. Natch it's a hole in my pontifery.

Standalone subsystems: Oh absolutely. It does need to be said.

I don't even know what it would mean for a given subsystem to be objectively good in isolation. The only measure of a subsystem's goodness that I can attend to is its fulfillment of its place in the system at large.

Simon: The way I figure it, at least for the games I'm talking about, what's important is integrating your subsystems, not keeping their number down. You want them to fit together seamlessly, and you want learning one to contribute to (or outright include) learning the next.

I think Raven's spot on here: "It occurs to me that many 'subsystems' aren't delineated as such at all in indie games, despite quietly existing in actual effect..." Poison'd is an example of the kind of well-integrated "six best subsystems" game I'm talking about. It has three whole resolution systems for different kinds of conflicts, plus a variety of other subsystems. It's heavier than many other games after the Forge fashion, but it's not, like, heavy.

Whether, like, Shadowrun has the right number of subsystems or way, way, way too many, though...

I think that the fashion in the Forge-derived design circles for a single resolution mechanism is deceptive. Deceptive in that a single resolution mechanism would usually be too few for a whole game, and also deceptive in that few enough games really have only one.

The thing is, though, that you want to present your players, as Simon says, with an apparently unified and single, thus easily grasped, game. So you integrate its subsystems and do everything you can to focus your audience's attention on their flow and unity.

Looking at a game's structure, to understand its design, means looking past what it presents to its players. Alas, you'll never play a game for plain honest fun again.

So, subsystems. In your letter to a friend, you make it sound like each subsystem is a totally standalone thing. But they're not at all like that.

The design principle coming out of that advice was that you have several sets of numbers, but the way you use them is different for the different things you do. Like, you have numbers between, say, 2 and 5, and 5 is great and 2 is bad, but you do different stuff with them.

Furthermore, they can link into each other. You do something that inflicts harm on someone else? That person can take the hit and might wind up fighting back, which initiates a different system.

Or so I heard.

... from a friend.

This discussion would benefit from some common ground on what is being called a "subsystem".

Can you select a handful of games, maybe some old Forge Games, some new Forge Games, your games, not your games, older non Forge games...and identify what you are calling a subsystem.

I have thoughts...but I'm not sure I'd be talking about the same thing you are.

Vincent: You want them to fit together seamlessly, and you want learning one to contribute to (or outright include) learning the next.

I'd like to read more about this.

Listing subsystems is so boring! But okay. I'm going to just do my own games because I have them in my head, mostly.

Rock of Tahamaat, Space Tyrant has:
- 2 character creation systems
- resolution for Rock of Tahamaat (which includes scene setting rules)
- resolution for non-Rock of Tahamaat characters
- some end condition rules

In a Wicked Age has:
- drawing and reading the oracle
- rules for returning characters
- creating PCs
- creating NPCs
- creating particular strengths
- scene setting rules
- action sequences
- consequences (negotiating with a stick, including exhaust/injure)
- the owe list
- some stuff about the 3rd session and subsequent

Dogs in the Vineyard has:
- town creation
- character creation
- initiation
- 2 different NPC creation subsystems
- "how to GM"
- resolution (which we could further subdivide if we wanted)
- fallout (including reflection fallout)

Poison'd has:
- character creation
- ship & company creation
- NPC creation (including ships and fortresses and whatever)
- fights
- setup rolls
- bargains
- elections
- changing your pirate's stats
- deadly wounds
- cruel fortunes (one or two of which might qualify as their own subsystems entire)
- prizes
- leisure
- "how to GM"

Does that help? Ralph or anybody else, if you'd like to list your games' subsystems like this too, that'd be fine.

So those, plus each player's fiction-thought-bubbles, are the subsystems.

You're saying the designer needs to focus on the interactions between the different subsystems.

So for IAWA we don't care how the action rounds work on their own, we care about how they interact with
1) what Joe and Ted and I think is happening in the fiction
2) the Owe list
3) and so on

?

That helps, yes.  You're taking Subsystem down to a much finer level than I'd thought, but now I can follow along thanks.

There's a loud vocal part of my hierarchal minded brain that is insisting that many of those things are not subsystems but just subroutines inside of a subsystem...but I've kicked him into submission so as not to bore you all with my obsessive need to compartmentalize :-)

Ryan: Yes!

Complicated slightly by the fact that how subsystems interact depends upon how they work internally, so it's not like you can ignore how the action rounds work on their own. So it's more like, we care how they work on their own, but we can't stop with how they work on their own, we have to look at how they work together as well.

Ralph: Cool. (I kind of figured.)

I like how you talk about games "calling for" mechanics.  There's this thing that happens when I'm designing a game, and it happened especially strongly during writing "On Mighty Thews", where I can just kind of "see" the shape of the game in my head, and writing it down is the easy part.  There's just one way that the game has to be in order for it to work, and you've just got to get it down and you're done.  Sometimes different parts are harder to see than others, but usually when you see them you're like "Oh, of course it has to go like this", and then it's easy again.

That's the fun, easy, early part of design.  The hard part is the later part where you're faced with all kinds of decisions like "do you get five traits, or six?" and there's an answer that's objectively better, but you won't know until you've played half a dozen times.  Or worse, you find out that bits that in abstract seemed just right in practice conflict with each other, and you've got to make hard choices where the answers aren't obvious.

I'm good at the first part of game design, but because I'm lazy I really struggle with the second part.

Ok, stupid question maybe but would you say that Ceremony in Dogs is its own subsystem or a part of the resolution?

Usually when folks push for unified mechanics, what they're really wanting is mechanics which are easy to remember and easy to implement.

For a lot of people, this is an attempt to get something with which they can make "principled decisions with".  For some, that's because they're used to ignoring the rules of the games they've been playing with, so having a single set of mechanic steps on top of the usual GM/player roles they're used to works, for others, it's from seeing a game with a prominent system and imagining that it's the cause of it's success w/o considering the other subsystems.

Of course, the road to intuitive mechanics is usually building on currently existing skill sets for people.  Or introducing the basic skill set/principles and applying them throughout the various subsystems in a clear way.

I think there's a danger of confounding the idea of subsystems with the idea of unified mechanics (or non-unified as the case may be).  From the list of subsystems Vincent provided as examples...they clearly seem to be pretty apples and oranges issues that may or may well not ever overlap in any given design.

The common useage of Unified Mechanic, typically refers to the specific technique of rolling dice to do stuff...regardless of what that stuff actually is.

I don't really see how having different rules for Character Creation than you have for NPC Creation connects with whether or not your game has unified mechanics.  Those subsystems aren't what people (anyone I know anyway) are talking about when they talk about unified mechanics.

Dog's mechanics are completely unified.  Unified to the extent that you can have "just talking" dice and "blowin' your fool head off" dice in the same die pool and not even care about which is which.

IAWA age mechanics are completely unified.  The dice work the same whether you're drawing upon eldritch wizardries to avoid demonic possession, or saying no to an over zealous suitor.

Poison'd adds a few bells and whistles to knife fights vs ship fights with cannon.  But basically the core dice and Xs mechanics works the same whether you're engaging the British Fleet or trying to avoid beint Buttsecksed by Dirty Pete's peg leg.

I think it is certainly an interesting conversation to see whether the technique of rolling dice to perform first aid and triage should be different than the technique of rolling dice to survive a fire fight in a game about Marine Hospital Corpmen.  But I think that's an entirely different conversation from how Character Creation subsystems and Scenario Creation subsystems interact(except in so far as they intersect with each other).

Poison'd is, of those of mine, the clearest example of a game that needs more than one resolution subsystem. It has three: one for fights, one for physical conflicts that aren't fights yet, and one for conflicts that aren't even physical yet. The real escalation in the game happens between those subsystems, not within any of them.

I don't see any pressing reason why all subsystems should have similar looking mechanical bits, other than aesthetics, which is distinctly personal.

There's a learning curve issue, but it cuts both ways: similarity makes it easier to learn, but also easier to get the system confused. If you can imagine a game where the talking system uses dice and the fighting system uses cards, people are less likely to (out of confusion or ignorance) try to use their fighting abilities while talking.

yrs—
—Ben

There's also the coverage concern, which "6 perfect subsystem" games tend to simply decide against—if it can't be described by one of the six subsystems, you can't do it.

Perhaps because I play with a lot of tech geeks, but the problem of "You want to do something that's not covered in the rules, even a little bit, but would logically have potent effect son the other subsystems.  OK, is there a general resolution system somewhere, or something I can adapt as an analogy?"

Poison'd avoids this—there's only one way to prepare for things: get Xs.  For people immersed in tech geek (clearly, if we hang the sails this way, the benefits would be...) it may grate a little against suspension of disbelief, but it does help establish the feel of the setting.

But perhaps people being able to use fighting abilities while talking is actually a design goal. Unifying the mechanical basis is one of the ways of getting sub-systems to interact, and it gives them long borders, because rather than attaching at specific points; "activate fight, swirly graphics", they plug into each other in a variety of situations. An example might be someone trying to break up a fight, with social mechanics interacting with combat ones. The "automatic" escalation of Dog's provides another example.

This suggests to me that the idea of a unified mechanic should actually be a way of considering at a deep level the differences in different kinds of interaction, and using one dice system (or whatever) to express those differences.

This can cause headaches, like when I tried to combine my "lifting heavy weights" subgame with my combat subgame, which mashed up the dice in a horrible way and forced me to shift the numbers for everything, but when it works it means that it's really hard for people to play the interactions of subsystems wrong, or at least makes it obvious that they are doing it, and so locks the game together.

Is each subsystem an arrow in the Fruitful Void sketch ?

Conversely, should each arrow be implemented as a subsystem ?

Ben: Naturally.

Zebediah: Storming the Wizard's Tower, for instance, has several dedicated subsystems, plus a general subsystem to fall back on. No prob.

Josh: Sure, makes sense to me.

Mathieu: I don't think so. The arrows on the fruitful void sketch arise from the game's subsystems, but needn't be them.

(The fruitful void sketch, by the way.)

Vincent:  ah—I see the point I was trying to make was too obvious, and everybody had it already.  My bad ::grin::

I came to RP first through 1-shot larps—specifically, though the Assassin's Guild, which is known for insanely customized mechanics: if you don't know the herbalism, or computer hacking, mechanics, you don't get to use them.  And if there isn't a mechanic for it, it falls into one or two catagories:

Impress the GM: if you can convince a GM you should be able to do something, they'll come back the next day and give you a sketch of how to do it.

Kludgite: things made of kludgite are "impervious to player cleverness."  Yes, you can write programs to interact with nodes, but the in-game bank's computer system is made of kludgite.  You can't use your computer skills to manipulate finances, no matter what clever plan you concoct.

This occasionally leads to that old chestnut about disbelief: it is not merely suspended, but hung from the neck until dead.  But some level is vital for game balance in a gamist system, to distinguish a "fair" win from an "unfair" one.

Which I think was a lot of words mostly to explain where I was coming from.

Toward Mathieu:

My my larp experience, I'd define a subsystem thusly:

A subsystem is a set of procedures and information used to resolve some portion of a game, with very limited reference to the other subsystems of the game.

Important to the notion of a subsystem is that you don't need to know the other subsystems in order to resolve this one—that information is prelude or postlude, or very rarely, runs in parallel with a simple "bonuses from one system can be passed to another."  If two subsystems run off the same resources and pass each other bonuses while they run in parallel most of the time, you're probably looking at one complex subsystem.

There is usually some level of unification, in that there's some description of the relevant details of a situation that subsystems change, and that then that subsystem or another one can be used to affect the new situation.

The "very limited" is the part that's most ambiguous.  In a larp, or the equivalent, there may not be any connection between the systems other than the fact that the same player is using them, and if his character has been killed with the combat system, he's not allowed to use the research system anymore.  In Feng Shui (or D&D, or....), the same stat-block gets interpreted in different ways in different venues by the different subsystems.

In Burning Wheel, there's actually a very complex morass of which skills are useful in which mechanics, combined with various "pick three options from this list" choice mechanics, which assemble into most of the submechanics of the game.  But those sets of choices, and what is tracked, does a very good job of giving the feel of combat, debate, etc.

Which is, going back to the top of the page, an important aspect of having subsystems—they're there to give you the flavor of doing something that you're not actually going to do (because it's illegal, immoral, dangerous, impossible in general, impossible for the player, or depends on interacting with details that we aren't going to bother to establish)

Vincent—thank you so much for the fruitful void model.  It crystalizes a lot of things I hadn't quite managed to grasp in my own pet game design.