System Structure

This is my first blog post, and as I swore repeatedly that I would never have a blog, it's pretty humiliating. Whatever. This blog isn't about me, it's about games.

Systems have akways fascinated me. I came into RPGs from wargames in 1978, where kit-bashing and rolling your own were common activities. I carried that over into roleplaying. I have little use for innovation in gaming. Innovation, in my opinion, should only be used when tried and true methods are not working properly. That said, it's due to innovation that there are any tried and true methods.I admit that. My position generally is let someone else do the innovating. Innovation generally invokes failure. Messy, catastrophic failure. I like to avoid that if possible.

Now innovation does not equate to creativity. I have lots of use for creativity! Applying tried and true methods creatively is what I strive for. To me, designing RPGs is not an art, but a craft - first of all is usefulness. Anything else is secondary. I'm trying to build a nice chest of drawers here, not sculpt a stunning piece of art. Unfortunately, like Herodotus, I tend to digress. Let's get back on track.

A game system is an assembly of rules and supporting structures which enable a game to be played. I know of four structural models for creating systems:

Accretive - This is the way the first RPGs were created. Rules are added ad hoc to the existing rules as problems are encountered. Each problem has a separate but equal solution, and exceptions are handled via judgement calls. Rules inter-relate in strange and unpredictable ways. There is a lot of flavor inherent to this model - quirky, messy, and interesting.

Disappearing - This model emphasizes one central mechanic which is applied throughout. Problems encountered are resolved by application of this mechanic, with exceptions resolved by non-mechanical means via a combination of consensus and judgement calls. This model yields games which are simple to learn and easy to internalize, so that the rules tend to become background noise.

Thematic - This model emphasises a set of related co-dependent mechanics which are generally applied by the players directly rather than through the medium of the characters. Problems encountered are resolved by applying these mechanics to change the nature of the problem on a metagame level until the problem essentially resolves itself, reducing or eliminating the need for exception handling. This model works best when applied to sharply circumscribed initial value sets, due to less effort being needed to shape the problems encountered so as to fit the ruleset.

Framework - This model is a set of abstract interfaces, to which modular sub-systems can be attached if they have matching interfaces. Sub-systems return a value which can be handled by the framework. Problems are resolved by application of a sub-system, with exceptions handled by other sub-systems added as needed. This model necessitates a high degree of abstraction, due to the need to standardize interfaces, but is extremely flexible - both in application and in design.

All these structural models have advantages and disadvantages which are inherent to the nature of their structures. None are inherently bad or good, as their value is entirely in their application. Structures may be appropriate or inappropriate depending on what the designer wants to do. Structure strongly influences game flavor, and appreciation of game flavor is extremely subjective.

More later!

-clash