This is my first post in the Forge, so hello everyone. I have been making my own RPG systems for several years. I found John Kim’s list of free RPGs a while back and started tutoring my self from it. Eventually I even realized that there is more to that site and finally found my way here.
    Anyway I’ve been thinking of late that RPG system design could be improved by making systems more modular. To explain the idea of modular system design you have to understand the concept of a subsystem. Most “over-systems”, such as d20 or white wolf, can be looked at as a group of interconnected subsystems. Each one handles one type of information about what’s going on in the game. Examples include skill resolution, combat, damage resolution, magic, psychics, vehicle movement, character advancement, etc. Being often interconnected, different subsystems in an over-system use other subsystems to perform their own tasks. This means that a given subsystem can’t be edited, used by itself or used with another system easily.
The idea of modular system design is that subsystems should be made independent of each other. To do this, each one would hold all the information about a character and all the mechanics it needs to do its job. The subsystems would still need a basic interface with other parts of the game, but this should be kept minimal.
    This would make it so any given subsystem could be easily modified or even swapped with another subsystem that handles the same type of data. A given aspect of a game that is not liked by a Game Master could easily be changed with out any affect on the rest of the over-system. Likewise a Game Master could cobble together a custom over-system for his RPG out of the available subsystems.
    The only disadvantage of this that I can think of is a loss of unity in the over-system. For example d20 uses 1d20 + modifiers vs. Difficulty Class for a lot of its mechanics. With modular systems you could end up using that for combat, a d10 pool for skill checks, etc. On the other hand, it could be argued that many systems already lack unity or that the subsystems would be simple enough that the loss of unity wouldn’t be a problem. Furthermore, there is nothing about modular design that says an over-system can’t be composed of subsystems that use similar mechanics.
    Talk of modular systems leads to the thought of, to make up another word, mega-systems. These would be a collection of modular subsystems design to be used together. What the mega system would do is provide a universal interface for all the subsystems it contains, so that they can be made more easily into custom over-systems. It might also facilitate how advancement works when working with independent subsystems. Naturally a mega-system could be relatively loose or strict in what it dictates to the subsystems.
    I should also mention that a similar idea is used in computer programming with classes and such. I was pleasantly surprised by this when I took an intro programming course last semester.

Has anyone heard of something like this before?
Anything that I’m missing?
Does this look like it would actually help anything?
Does this even look feasible?

Hi Lewis!

Your post reminded me of this one from a while ago:

Component-based design of RPGs

Have a look and see what you think.

Graham

Interesting ideas, from a theory perspective. It would be a very ambitious undertaking though. It might suffer from being a bit too 'experimental' over being practical. The effort of learning and remembering all the vastly different modules alone might be herculean, let alone chosing the ones you think work together best.

You would have to be careful that any resultant system didnt end up being GURPS or D20-esque, losing coherancy in the name of genericness. Sometimes a tightly defined objective and a very specific, unique style of play can create a much more enjoyable game. Not to mention a tightly defined objective is able to put emphasis on the setting that a generic game is incapable of. Im relatively new to the scene myself, but it seems as if a lot of the best indie games coming out are of that fashion.

Still, whats the point if not to push the envelope? The idea certainly has a lot of interesting implications. An open-source RPG? Officially codifying what we surely all do anyway- house rules. Start a wiki and open it up to everyone to just start creating modules. Even as just an in-house development tool it could be useful.

If you're going to apply Computer Science concepts to get modularity, you should hopefully realize that this means a common interface between components. This generally ends up meaning a unified dice mechanic, or a single method of determining what a "success" is, and so on. The best analogy I can come up with is that this means using the same "language" for all of the components - when you say "check for success" in one component, it means exactly the same thing as for all other components. If a component wants to do things differently, it ends up having to have translation routines.

For your example of using a d10 dice pool system of skill checks in combination with d20, that would mean that the skill check module would have a section titled "Converting from d20 to d10" which would describe how things are translated over - for example, "Divide the DC by five to get the number of successes you need. The size of the dice pool is the numeric value of the bonus to the roll, plus four."

The problem with trying to achieve this kind of modularization in RPGs (and the reason why I am skeptical of so-called "universal" systems in general) is that there is a lot of translation work involved in going between modules. Let me tell you a little something about the guts of object-oriented programs:

1. When dealing with objects as variables, you are basically dealing with pointers to the object data. This is the equivalent of, in an RPG, dealing with page numbers.

2. Thus, every time you deal with changing the attribute variables of an object, you pay the cost of first going to the location in memory pointed to by the object, then doing the actual change. This is no problem if you have some expectations about what to find - if the system does not change very much, you can pre-load a lot of what you need. If the system is expected to change a lot, then this is equivalent to having to open up your book and look up the page for the section you need to read every time it comes up.

3. The same ideas as point number 2 apply to looking up "functions" of an object. Objects simply hold pointers to the real code of a function. In an RPG system, this would be equivalent to looking up what a spell or ability does, or looking up how a "success" is determined. Again, as long as you don't change things much, you can pre-load what you need (or pre-memorize the game mechanics) and things won't be too bad. If things do change quite a bit, you end up having to either pay the cost of looking up memory repeatedly, or you can put the code of the function right there in the object - which is equivalent to writing out the rules for everything your character can do, right on the character sheet. This is very costly in space.

4. This is the kicker - type coercion. This means taking an object and doing something to it so that it can be fitted into a different class or system. In an RPG system, this is equivalent to trying to do a conversion procedure between different editions of a system every time you change something that affects the meaning of data. You could simply do the required conversions "on demand," but that means paying a great cost in effort. This isn't so bad if you don't plan on changing around the modules too often, of course, since you only do the conversion a few times over the course of the campaign (but you really shouldn't have to do it at all).

Let me tell you - just because computers and RPGs are both logical systems and similar concepts can be applied to both does not mean that it's a good idea to do so. Humans can only do a few "operations" per minute while computers are blazingly fast. If you make a computer do a million additions every time it needs to do something simple, no problem - it can do that a thousand times per second! If you make a human do a million additions every time he needs to do something basic like check for a skill success, he will throw a chair at you and not come to the next game.

I believe this - even though RPG design can be likened to software design in many ways, we should not make those analogies. It is better to say that RPG design should be likened to hardware design - we are making tradeoffs between speed, bookkeeping, how much work it takes to do the most basic mechanical actions such as checking for skill success, examining which mechanical actions are done most of the time, how easy it is to compile software for it (which is equivalent to trying to figure out how much work is required to translate from a conceptual story to a concrete campaign with NPCs, environments, etc.), and all kinds of other factors.

If you are what this website calls a "Narrativist" then you probably keep the rules small enough to be able to memorize all of them anyhow.

Hi Lewis, welcome to the forge.

Do you think there are any playtesting issues? For example, with a regular game, the designers have gone through play testing and tweaked their game so it actually meets the goals they want it to. With a modular system, you don't have that foundation of development for any particular configuration. What do you think?

I've thought about this some too. If modularity, at least as I am using the term, is achieved then the need for interfaces should be minimal. I isolated the Vampire the masquerade "skill" system this morning. The way I have it working, it doesn't need any interfaces at all. If you ran an RPG with out combat, magic or, well, anything besides skills, it would be all you would need. Granted, I'm not nearly clever enough to come up with a way to do that with every sort of subsystem. If a magic subsystem deals or heals damage, it's going to need an interface with the damage subsystem. However this interface could be as simple as "This spell does moderate damage" in the magic subsystem and "moderate damage is 5" in the damage subsystem. Using the interface as markers, the composer of the over-system could even scale the one subsystem to match the other.

Point 1) If I'm reading you right, this is true for all RPGs.

Point 2&3) Once again, if I'm reading you right and your arguing for system unity, you have a good point. I've been saying for years "The perfect RPG system has one simple rule that can easily and consistently be applied to any circumstance while taking in all factures that may affect the outcome." I have yet to find any system like this.

Point 4) You realize that the sort of mega-system that I'm suggesting isn't really a system that you play with but rather a tool for making systems. So you would be using the same set of modules for a whole campaign, unless problems with the rules arose. I really don't understand the rest of this point.

I like your analogy to hardware design though. Let me explain what I'm thinking of this way: It might be better to work with a bunch of simple calculators with maybe a wire or two connecting them than to work with a messy tangle of wires of a super computer.

Callan wrote:
Do you think there are any playtesting issues? For example, with a regular game, the designers have gone through play testing and tweaked their game so it actually meets the goals they want it to. With a modular system, you don't have that foundation of development for any particular configuration. What do you think?

Funny the first part of that post got cut off. Probably me and my copy pasting. There's the first part:

Graham wrote:
Component-based design of RPGs

Have a look and see what you think.

Oscar wrote:
It would be a very ambitious undertaking though. It might suffer from being a bit too 'experimental' over being practical. The effort of learning and remembering all the vastly different modules alone might be herculean, let alone chosing the ones you think work together best.

ssfsx17 wrote:
If you're going to apply Computer Science concepts to get modularity, you should hopefully realize that this means a common interface between components.

I don't see an edit button either.

I think I understand what you want, now, and it is definitely more sane than my previous understanding. I'll tell you right now that the messy tangles of wires inside supercomputers are not for doing the actual work - rather, it's all for making the different components hold together and agree with each other, as well as to maintain proper logical flow. The devillish details are precisely in the work required to combine the different components into a cohesive system, which is why I think of this as hardware rather than software.

I'm not saying that I disagree with trying to come up with isolated versions of various system rules, thus creating a codex of RPG logic. After all, hardware has a rather standardized set of components. In fact, I don't know why we don't have such a thing for RPGs already. I think what you're trying to do is help out those people who are simply not aware of certain systems - I know many who have never seen a dice pool - or who have trouble thinking of the logic for a subsystem, since they do not enjoy staring at it all day long and making it work. If that is the case, we should accept that the best we can pre-make for someone is about 25% or 30% of the work involved in designing an RPG.

That does explain it a lot better! I think the Hardware analogy is a perfect one. It could get VERY theoretical very quickly. But thats okay, half this site seems to be about theory.

To make a truly comprehensive system, starting with theory and working down would probably be best. Especially if we are exploring the options a designer can have when creating a game rather than trying to make some sort of all encompassing uber-system. Dealing with the broad differences between types of goals, conflict resolution, rewards, punishments, etc etc defining them and offering the most basic example of each alternative, then expanding from there. There are enough theoretical concepts buzzing around the forge that you would have a very solid base to begin doing this. Click 'Articles' at the top there for just a small sampling.

A comprehensively mapped system showing all these alternatives, the options within them, and the options within them (Ad infinitum) and their possible relationships could be of immense help to designers. Reverse engineering the individual components of a system as you are currently doing could also be an interesting process, but you will probably quickly find that they reduce down to a few 'core' concepts. Linking those core concepts together and describing their interactions at the most basic level would probably be the first step.

RPG design patterns might be of use. Also, this RPG.net thread might have something interesting in it.

As far as a general index of the mechanics used in RPGs, this is pretty good.

I'm going to continue to modularize subsystems and see if I can run a game based off of the Wheel of Time series by Robert Jordan. I think the Vampire skill subsystem, that I already did, would work well with a few changes. I have a modular subsystem for channeling (magic) which I came up with about two years ago, which was one of the things that got me thinking along these lines. The d20 carrying capacity subsystem will be good because I know nobles and Aes Sedi (mages) will try to make the other character's carry their stuff and that will make the other character's feel it. I'll also use the d20 damage subsystem since most of the time in the books characters are ether up or down. Now, I just need to find a combat system. It should be moderately light, since combat is a focus of the stories, but not the focus. Also combat in the books is described to be like dancing with moves and counter moves, so the subsystem will have to handle that. I think I remember a system called Last Stand that might work. If anyone knows of a combat system that sounds like this, let me know. (I wrote this up in hopes of giving a better idea of what I'm thinking.)

Try the Fireborn system.
Possibly the one in Secret of Zir'An?