Pressing buttons on the character sheet
There's a standing complaint against the mindset of seeing the contents of a character sheet as a set of UI buttons with hard-coded effects and specific appropriate contexts for use for a player to press to create effects ingame.
The mindset is artificially confining, turning an infinitely open-ended activity into an analog computer game that also forces you to be in a room for 4 hours with other people arguing semantics. Sometimes fun if the argument is stupid enough but we should aim higher.
The thing that pains me the most is the the TTRPG genre flows from following the golden rule: "that anything may be attempted". Of course, the sticky bit is being able to actually adjudicate what happens generally. I judge systems on whether they provide efficient and flexible tools for resolving the most common gameplay situations satisfactorily and how well they equip you to step beyond them.
People run/play games adhering strictly to RAW for multiple reasons:
- the game is functionally a contest, which must be fair
- players must be able to move between different tables and get consistent rulings
- the GM, the players, and the system designers aren't operating on the same fundamental assumptions on how the game works, and possibly are all aiming to play different games
- sometimes the different game that they're trying to play is "win at system mastery so I will be the Alpha Nerd"
- the system breaks catastrophically or leaves you with no useful tools if you don't keep to the safe processes it provides
- habitual thought; GMs and players are trained to expect that things will just go badly and awkwardly if they step outside the safety of the clear printed rule. Happens a lot when people enter the hobby from reading game theorycrafting online.
Attempting to overturn this framework is one of the big banners that the OSR rallies under. But you can't just "remove" a habit (including a way of habitual way of thinking); you must replace it.
Alternatives to the button-based mindset (which can be combined in varying amounts):
- roll for skills as they are attempted - repeated successes "reveals" (permanently) that you "have" the skill and don't need to keep rolling. Repeated failures proves the opposite. (Tim Kask described this in one of his videos but I'm sure I muddled it.)
- rule of cool (I hate it)
- total loosey-goosey; whatever makes sense for the character, which is defined only in relation to several (hopefully shared) cultural touchstones. Requires a firm grip on the ideas in question and a good memory to resolve things quickly and consistently. My memory sucks, I usually play with really creative people who are trying to push the limits of the system, and I like to chew on problems, so this doesn't work for me.
- The tag is the definition: if you have the word on your sheet you Have The Thing (to a useful, consistent degree). A short step from loosey-goosey. Glog does this kind of thing.
- No- or few-keyword definitions: phrase abilities in natural language with abstract phrases that may be fitted to the game fiction and as few keywords as is necessary to make it meaningful. Glog does this for most class features, and it's my current go-to.
- (Special) Take a -2: Player wants to do something clearly related (but different) to their printed ability. DM tells them to use their normal rules with a -2 penalty. I remember seeing this frequently playing PF1, it seems practically universal. Works fine to extend rules-heavy high-granularity systems while preserving meaningful character building choices.
My current Glog-descended WIP hack, Strange Moons, is based on using "tag as definition" for skills, and classes provide "no- or few-keyword definitions". The class bit is fine, but actually using open-ended skills in a game needs a bit of structure; GMs need clear intuitions and processes that can accept them, players need to be taught how they can use them.
Firstly, do not name skills as a verb (e.g. "fishing") but from origin ("swamp fisherman"). The term is effectively a pin connecting backstory (or played history) to a sphere of implied skills; you know your way around a boat in calm conditions, you know how to maintain and use normal fishing gear, you know how to navigate a swamp. We can assume that a character will simply succeed at those things under normal and unhurried conditions (that framing is important).
If you are what you repeatedly do, you can repeatedly do what you are!
My mental model is to not see the elements of your sheet as "buttons" but as "levers". You're still ultimately looking at your sheet for things to use but now you're thinking about how to creatively and appropriately apply them to the situation - approach must be specified and gives the GM information for resolving things. "I want to do X thing, using my skills from Y."
Like a real physical lever, it lets you apply your energy more efficiently and effectively to the situation than if you lacked it (often making the difference as to whether you can do the task at all). It can be more or less appropriate for the job at hand. You can combine multiple levers (multiple different semi-appropriate skills) on the same job, but there are limits - you can't lift a truck with a crowbar, and having 20 crowbars doesn't help much.
Prepped materials and game processes that are compatible with that mindset
You make playable material with reusable components and maintain a library of those components that is optimised for quick access - and preferably committed to memory.
Locked Door toy example (untested).
- The "locked door" idea is decomposed into two different tables; the door and the lock, since you can have many ways of securing a door that aren't locks, and you can have locks on many things and different ways of putting locks on them. This makes each table more reusable.
- The door doesn't have a row for "open unlocked door" or "knock on door politely" or "cast disintegrate"; the lock doesn't have a row for "use key". The tables are for both preparing and running material when the component presents an obstacle and how it responds to obvious approaches. If the door is unlocked or the players have the key, it's not an obstacle and you don't need the table!
- Obstacle == risk or resource cost (usually time) and some kind of meaningful choice between options. Free options shouldn't be listed unless you're likely to forget they are possible, and there should never be an option that is 100% better than another.
- to assist in prep (including sneaky-during-the-game prep), add flavour text, links to inspiring material, other tools, perchance rollers, hp-vs-break-time-vs-material-vs-size calculators, whatever
- to assist in running the game ongoing, they need to accept game notes to evolve with you over time. Include blank rows. In-game annotations are simulated with italics here. Include links to critical rules. Ensure that what you're writing is compatible with those. If you foresee that you'll be referring to multiple different pages regularly, try to combine them into a single quick lookup / flowchart document.
- The reusable component table suggests defaults, but specific examples always override these. You could say that the goblin hideout is filled with 10-second doors, secured with random rotting crossbars that contain biting grubs.
Door
Doors! They promise passage through the wall and block you from simply doing it. They may be locked or not, barred, barricaded, stuck, secret, big or small, trapped, squeaky or quiet, and perhaps talkative.
Listed values represent a strong door intended to slow down an attacker.
| Approach |
During |
Then |
Notes |
| Schmuck (bash, targeting lock) |
6DR, 24HP / 5 minutes
Noisy! |
Flesh vs. fatigue |
Groups don't reduce time but do eliminate fatigue breaking down the whole door (no identifiable weakpoint) takes twice the effort |
| Massive damage: Breach, battering ram/explosion |
as action |
Noisy! |
|
| Bypass security / reach the unlocked side |
5 minutes to make tool, 1 minute per blind attempt, Hard |
|
wrong guesses about the other side make this Fruitless |
| normal door |
3DR, 12HP, 1 minute |
no fatigue |
HEEERE'S JOHNNY! |
|
|
|
|
In trying to make this I realised that I had made a silent assumption (that the door is strong) and that there was a lot of variation there. My personal solution was to add that fact to the top clearly, and then force an additional door type as its own row since it almost the entire rest of the table was reusable as-is. You could make multiple tables, multi-level tables, pull that information into a header block.... this one seemed good enough.
Now here's another problem I've created for myself: I've asserted that with these concrete (high-granularity) DR and HP values it will take the average adventurer to break through (good for quick resolution), but I have no actual rules to substantiate that.
The DR and HP is the part that I don't know, and the expected time is the part I do know; the times have been left in place, and the DR/HP model for them can be added back in when I'm able to do the math.
In fact, it's possible to draw a direct link between expected time needed, a default weapon, and a specific DR and HP. That can be its own general-purpose chart!
Lock
Every lock was made with its keys. The gods have thus far kept the secrets of perfect security all to themselves, via self-explanatory means.
| Approach |
During |
Then |
Notes |
| Rogue, pick lock |
3x (finesse vs. DC 10), 1 turn per attempt |
- |
|
| Strike off (padlock) |
1 Action, flesh, DC 10 |
|
|
| Break out of object |
object's normal destroy time |
|
This is the normal way |
|
|
|
|
Writing this one forced me to re-examine how doors break and being distinct about whether an attacker is chopping the lock out of a door, or if they're breaking the whole thing down (e.g. in the case that it has a couple of bars securing it).
Finally, seeing this all in action
Player, faced with obstacle, suggests some plan for getting through it.
GM asks themselves:
"What's the expected skillset for solving this problem in this way?" (the prepared material might tell me)
"How much of the appropriate skillset is overlapped by what is being used?"
Finally, decide:
- pick a row on the table and use it directly
- pick a row and adjust it to be better or worse (consider annotating that line in the notes)
- create a new row and write it in
- interpolate between two existing rows
Then you just do that. You resolved the situation consistently and flexibly and retained information to keep doing that consistently. Mission complete.
Q: Where's the post introducing this obstacle-table thing properly?
A: It doesn't exist. I invented it and then refined it on the fly while writing this post. This is where it it is introduced. The top-level doctrine, the process for how it is carried out, and a material implementation of that process are too connected - they must be explained together and in relation to each other to be meaningful and useful.
Q: What's your stats and resolution system?
A: I'll tell you when I know :)
Q: Are you meant to do this with electronic or paper notes?
A: You actually run games?
