In previous articles I have touched on Situation and Setting. Today I’m going to tackle another key component of RPGs: System. First off, you should know that I do subscribe to the “lumpley principle.” So if you have serious issues with that, then I’m afraid that this article won’t help you very much.
But anyway, the lumpley principle states: “System (including but not limited to 'the rules') is defined as the means by which the group agrees to imagined events during play.” The first time I read that I went, “Huh?!?!?” Then, through the years, I read a lot of explanations to it and the definition finally clicked.
Basically, System is big. Real big. In fact, we should really write it in all caps like this: SYSTEM instead of just capitalizing the first letter. Writing it like that, I think, might clear up a lot of confusion, because when someone (especially if they are new to RPG theory or design) sees “System”, they might think of something like the D20 System and say, “Well the whole system is just the SRD, right?” Well, not exactly.
To really help me understand what SYSTEM (the lumpley principle) meant, I had to brake it up into two parts: Rules and Procedures. For my purposes, Rules are the games text. They are the printed words on the page, unmodified in any way by the participants. Rules are the author’s expression of the game objectively observed in black and white on the page. Everything in the book, from cover to cover, is Rules. Anything that is not in the book that affects play is Procedures.
EXAMPLE OF A RULE (A): “Roll three d6 seven times to generate the seven stats for your character. Arrange them any way you like on your character sheet.”
EXAMPLE OF A RULE (B): “Choose one of eight races included in this book for your character. This will be his/her heritage and background.
Procedures can include modified Rules (often called “House Rules”), dialogue between participants, deciding who the “leader” of the party will be, who gets to roll dice first, narration of events/actions by characters, negotiating conflicts between players and/or characters in a fashion not provided for in the Rules, and so on. Procedures are essentially the talking around the table and the actions/agreements made by the participants that are unique to the group. It’s anything the participants agree to do or establish that affects the in-game events. Sometimes Procedures are based off Rules; sometimes they are not.
EXAMPLE OF A PROCEDURE (A): “Hey guys, instead of rolling 3d6 for your character’s stats, roll 4d6 instead and drop the lowest one. Arrange them in any order you like.”
EXAMPLE OF A PROCEDURE (B): “Guys, there are no elves left alive in this world we’re going to play in. So when you choose a race, you can’t choose to be an elf.”
So if you look at it like that, you can see that SYSTEM really is big. It includes everything that goes on at the table no matter how closely or loosely it adheres to the written rules of the game. It even includes stuff that people term as “meta-game.” Anything that affects the in-game events is part of SYSTEM.
So what does that mean for a designer? A designer must be aware that the SYSTEM of his game will, no matter what, include two parts: The Rules and The Procedures. It’s been said that the only part of SYSTEM a designer really has control over is The Rules- the words he writes in his game. But this isn’t entirely true. A designer can encourage players to develop Procedures for the game. In fact, many games are enhanced by players making up the bulk of SYSTEM and only referring to the Rules when there is a dispute. A designer must signal to the players (using the text) when it’s probably okay to use a Procedure to handle something and when it is advisable to use a Rule instead. You have to decide, will your game be Rules Strict (i.e. encouraging players to play as closely to the rules as much as possible) or Rules Relaxed (i.e. encouraging players to improvise and customize the rules as much as needed)?
This is quite important. No group will ever play the game strictly by the Rules as written. Human communication and understanding is far too limited to allow for that as a possibility. However, no group will ever completely toss out the Rules either. People sit down to play a game because the game text inspires and intrigues them. Therefore it is vital that the Rules give the participants guidance, explicit and thorough guidance. A designer must ask himself these two questions constantly as he writes his game:
“When do I want them to use my Rules as written to help advance play?”
“When is it okay for them to take ownership of the game and use Procedures of their own?”