RPG Design Handbook: Chapter 3 (parts 2 & 3)
Posted by Nathan P. on January 12, 2008
(previous posts collected here)
Chapter 3: Methods & Conceptual Frameworks
Part 2: The Lumpley Principle
If you are an experienced RPG player, you’ve probably run into the idea that an RPG consists of two parts, the “Setting” and the “System.” For now, I’m going to stay agnostic as to whether that divide has any meaning outside that of a set of easily comprehensible labels for talking about different components of a game. However, I’m going to be using the term “System” a lot throughout this part of the text, so this section is about defining what I mean.
The Lumpley Principle is one such definition.
The Lumpley Principle:
“System (including but not limited to ‘the rules’) is defined as the means by which the group agrees to imagined events during play.” (formulated by D. Vincent Baker. Definition taken from the Provisional Glossary at The Forge)
So, System includes not only the formal rules out of the textbook, but any “house rules,” group-agreed-upon behaviors, and the often non-articulated agreements on what “counts” in play that each individual group has. This is a more expansive definition that I think is typically meant when people say “System,” but I think it’s a clear articulation of the fact that the rules that you write effect the behavior of the players of your game.
A main criticism of the Lumpley Principle is that it’s overinclusive and vague to the point of being meaningless. This is best articulated by Malcolm Sheppard here, where he also states that:
Rules are game text which directly inform game play.
A game text is written for the purpose of informing play, as opposed to other texts which still inform play, but are not intended to.
I think that’s simple and clear enough that it doesn’t require unpacking. He has more to say on the subject, but that’s the most directly applicable to where I want to go next. “Rules” and “System” do not map one-to-one, and they are not interchangeable when talking about design.
So, we have the concepts of System and Rules. I’ll drop the annoying caps, but when I use the word “system” I’m talking about Lumpley Principle, and when I use the word “rules” I’m talking about Sheppard’s Rules. Which leads us right to…
Part 3: System Does Matter vs System Doesn’t Matter
Design Does Matter is a design philosophy articulated and championed by Ron Edwards, and is the context for many of the independently published games that were developed at the Forge. While it has been extensively debated and refined, the basics of the theory are expressed in a 2004 (? best date I can find) essay by the same title. One note: when Ron says “all three outlooks” he’s talking about the three “Creative Agendas” from the Big Model, another way of thinking about play. For our purposes, I would read “all three outlooks” as “any potential goal for play.”
System Does Matter
One of the biggest problems I observe in RPG systems is that they often try to satisfy all three outlooks at once. The result, sadly, is a guarantee that almost any player will be irritated by some aspect of the system during play. GMs’ time is then devoted, as in the Herbie example, to throwing out the aspects that don’t accord for a particular group. A “good” GM becomes defined as someone who can do this well – but why not eliminate this laborious step and permit a (for example) Gamist GM to use a Gamist game, getting straight to the point? I suggest that building the system specifically to accord with one of these outlooks is the first priority of RPG design. (from the article posted here)
System Does Matter is saying that the system of the game can and should be focused right at the designers goals for play, and that by not doing so you are creating a higher barrier for your potential players to get over if they want to enjoy the game in the way you intended it. This makes the corollary claim that it does not require a certain set of honed skills in order to enjoy a game to the fullest, and that a well-designed game can be enjoyed by groups of people that do not have a lot of play experience together.
So, what’s System Doesn’t Matter? Usually understood as a negative concept (i.e., the opposite of System Does Matter), it’s a shorthand for the widespread opinion that you can enjoy a “bad” game with a “good” group, and that a bad group can destroy even the best game. This is a philosophy that puts the social adhesion of the group playing the game above the intentions and effects of the rules system that they use.
To recast this divide with the language from Part 2 (system does not equal rules!), I would recap thusly:
System Does Matter: Designing rules that aim squarely at your design goals makes it easy for a given group to engage in systems that result in your desired play experience.
System Doesn’t Matter: The rules of a given game will always be trumped by the non-rules systems that a given group already has in place.
I think that System Does Matter is a natural viewpoint for aspiring designers, and it’s the basis of most modern focused design, to various extents. However, when looking at the two statements I’ve made above, they are not mutually exclusive. That is, even if the rules of your game are trumped by the social systems already in place, you can lower the barriers to enjoyment with both focused rule design, and a conscious attention in your game text to articulating the play experience you are aiming for, in order to allow a prospective group to decide whether your game is right for them.