We may earn money or products from the companies mentioned in this post.
The first step in solving a problem is identifying the problem. For some problems, like being on fire, that’s not very hard to do. For other problems, like being addicted to meth, (or having an irrational dedication to a particular die type) the big step is recognizing and admitting to the problem. For more complex problems, it’s not always quite so straightforward. Sometimes, for example, you think you’ve identified the problem but it turns out just to be a symptom or side-effect of a different or more fundamental problem. In the work I’ve done on Cinemechanix this week, I think I’ve hit on one of the latter.
One distinction I’ve tried to make between an “adaptable” game system (which is what I’m shooting for) and a generic game system is that a generic game system tries to find a one-size-fits-all solution and an adaptable game tries to provide the tools to let you find the solution that actually fits in your game. The problem I’ve run into a couple of times, and have been trying to solve with the current draft of the rules, is that stating that distinction doesn’t quite get the point across. I’ve run into several instances where players have been annoyed by rules that I thought were pretty obviously take-it-or-leave-it ideas that could easily be ignored. Despite the repeated reminders that everything is optional, the fact that these easily-skipped rules weren’t explicitly marked as optional made the playtesters feel like they had to use them.
Trying to find a way to short-circuit the impulse of assuming that anything not clearly marked as non-essential is essential got me thinking about the difference between a game system and game concepts or mechanics. The word “system,” implies a certain level of interconnectedness, so it makes sense for people to assume that everything is necessary unless specifically identified as non-vital. The truth is that for most game systems only some of the rules and concepts are interdependent and necessary. There are a lot of sub-systems and add-ons that you only need occasionally and may not need at all for some games. This got me re-working the text to make it more obvious which rules concepts were central to the system and which ones were part of the “toolbox” that could be used to build the sub-systems you need for the particular game you’re playing.
From there, I realized that I needed to move from the specific to the general on a lot of things. I’d provided some sub-systems in the early drafts of the rules for things like investigation and persuasion and specific combat mechanics I thought would be cool. Several of these were among the things playtesters didn’t like or thought were unnecessary. Like the sub-systems in most games, these relied on some basic mechanical concepts, but they were concepts that built upon the ideas in the core rules rather than directly using the core rules. In some cases, these concepts were already introduced in as generic concepts in other parts of the rules. The trick was to stop doing a little of both and get rid of the sub-systems in favor of the mechanical concepts, then to organize it in a way that separated the mechanics you use for building the rules for your specific game (the “toolbox”) from the rules that you’re probably going to need for every game (the system).
That’s when I realized the difference between a generic system and what I’m calling an “adaptable” system: generic systems don’t give you the toolbox. If the system is well-designed enough that the sub-systems are coherent with the core rules, you can usually figure out the underlying concepts on you own, but the game designer isn’t going to tell you. Most generic systems are, it turns out, adaptable systems, but the tools for creating that adaptability are proprietary. You might be able to run a wizard in GURPS* with just the basic rules, but it’s going to take a lot of work on your part and Steve Jackson isn’t going to give you any pointers. You’re going to have to buy a copy of GURPS Magic, and even that’s just going to let you run a generic wizard that’s sort of a gestalt of wizard archetypes and fantasy fiction. If you want to play anything that doesn’t fit the standard paradigm, like wizard in the Harry Potter Universe, you’re going to have to wait for GURPS Harry Potter to happen. Chances are both of those books will rely on a number of ideas that show up in a lot of GURPS books but aren’t spelled out as generic mechanical ideas anywhere in the main rulebook.
Why keep these rules concepts a secret? Part of it’s convention, some of it’s probably ego, but the big reason is obvious from the example: the game designer wants to sell you more books. Despite the conventional wisdom that people don’t buy games because of the system, most game companies seem to think that filling in system holes is what sells game supplements. In my opinion, the conventional wisdom is ripe for a change in this case. Most people aren’t going to buy GURPS Harry Potter to find out the stat adjustments for half-giants or whether Parseltongue is an advantage or a skill, they’re going to buy it because they know the designer has mined the source material for gamable ideas and has probably come up with some ideas they wouldn’t have thought of themselves. Giving the players guidelines for building the game-specific stuff isn’t going to stop them from buying the supplements the company releases. They’re still going to buy supplements for the research, new ideas, and convenience of having someone else do the boring, tedious work for them and put it all in one convenient package. Telling them how to do the boring part themselves just makes it easier for them to come up with their own Harry Potter rules without having to wait for Rowling to give up a license. It also helps them come up with rules for their own original game that the company will never write a supplement for.
So once again, the root of my problem is “it’s the way things are done.” And because that’s the way things are done, readers are going to assume that’s the way I’m doing it. Fixing the problem requires making it clearer where I’m departing from the standard operating procedure.
*I’ll use GURPS here because from the few interactions I’ve had with him, Steve Jackson doesn’t seem like he’s got an easily-bruised ego. Besides, he’s too busy counting Munchkin money to read this anyway.
I don’t have Munchkin money, so I have to panhandle on Patreon.
