Thursday, 15 July 2021

Organizing RPG rules by timescale

Over the past couple weeks I've been working on my homebrew rules (basically a combination of Whitehack plus a half dozen other OSR sources). If you've been following this blog you've likely noticed this a bit as I've posted various ideas and and impressions of rulesets that I've read and house rules of my own.

I began writing out my thoughts on the importance of danger, time, and resources in a bit of an introduction to OSR style play:

While a RPG game can have many settings, and evoke many different narratives, this ruleset seeks to evoke the importance of danger, time, and resources, as the interplay of these three things help create dramatic tension.

Danger: Let us begin with danger. It is the most obvious factor in play. Danger comes in many forms and tends to add tension and consequences to action. Real and unpredictable danger is what makes an RPG session more than just a session of improvisational drama or comedy.

Time: Time is important. Time can only ever be expended, never truly be recovered by the players. The passage of time is the Referee’s greatest tool in bringing alive the world around the players, in showing the players that their actions have consequences and creating a meaningful game.

Resources: The players have resources. These range from items to abilities to contacts in the world to knowledge about the world. Resources are used by the players to interact with the world, circumvent danger, and come up with novel solutions to problems.

These three things are not interesting by themselves, no one likes a game that's all about micromanaging your inventory. But it's because the interesting bits (narrative milieu, setting, npc characters, mysterious locations, etc.) aren't conveyed through the rules. Instead the view of this ruleset is that the rules act to structure interaction with these interesting bits. These interesting bits are built through play and a setting shared by the players and GM.


 None of this is particularly new. But it did get me thinking about things and how rules are structured. For example if you open up most RPGs and look at the table of contents:



They tend to be pretty similar regardless of the edition or game. You have a section on character creation, a section on combat, a section on magic and spells, a section on items, a section on special conditions like drowning, fire damage etc. And if you're lucky you'll have a section on other game procedures besides combat like exploring. 

Overall most RPG books tend to organize their contents by category. While this makes sense for other types of books I feel like it can end up making RPG books more confusing and dense in some ways. I think the OSR is partially a reaction to this where a lot of how the game was played traditionally isn't covered in the rules, and a lot of original OSR blogging was about different modes or styles of play that weren't covered in your standard ruleset (like hexcrawls). 

As stated above I view the rules as sets of instructions which provide a structure for the players to interact with the setting and the things they find in it. In other words, a set of procedures. This idea isn't particularly new and another big point of the OSR.

However, for any given situation in the game there are different sets of instructions (often termed mechanics) which you could use to resolve interaction. For example take a chase. You could resolve it by simply flipping a coin. Heads the players get away, tails, the enemy catches up to them. Conversely you could resolve the interaction through a play-by-play of the players and Referee taking turns describing and resolving what they do and rolling dice. Like the players attempt to topple an apple cart to block the enemies. One of the players rolls and is successful and so the apple cart is toppled. The enemies roll to jump over the cart, etc.

The difference between these two procedures to resolve the players interaction with the world is their level of abstraction. Flipping a coin is resolving things with a high degree of abstraction. Doing a play-by-play resolves things in a low level of abstraction. I think neither is inherently better than the other, it depends on what kind of game you want to play. 

However, I think it's important to note of that what is being abstracted is time. That whatever set of rules, whatever procedure you make up or choose to resolve a player interaction with the world, it is going to abstract time in a certain way. Furthermore, you are probably going to want to abstract interaction in varying degrees. A game that resolved everything with a flip of the coin probably wouldn't be very fun to play. Neither would a game that tried to resolve everything in a very complex play-by-play with tons of dice rolling for every little action.

In this manner I don't see the rules in a game as an almost abstract mathematical modeling of the world where you're attempting to come up with a set of attributes or rolls or mechanics or whatever that you can use to model everything in how an imagined world works. 

Instead I see the rules as a set of compartmentalized procedures that exist like a set of Russian nesting dolls where each describes a different level of interaction. Once I started viewing rules this way I thought, hey, instead of organizing an RPGs contents by category I think they should be organized by time abstraction essentially by timescale. It just seems much more intuitive for me.

For example, I think there are about 5 different timescales used in most OSR games:

  1. Timescale - Characters: This section has the static rules that represent the game world where time is not a factor mainly basic character creation and dice mechanics.
  2. Timescale - Encounters: In this section time is generally measured in seconds to minutes and called an encounter. In an encounter there is often an adversary that will react quickly to the players and whom they have to react quickly to. Time is of the essence. Danger is often fraught!
  3. Timescale - Exploration: In this section time is generally measured in hours. The players are most often engaged in exploring a location that is not immediately hostile, generally room by room or area by area.
  4. Timescale - Traveling: In this section, time is measured in days where the players are traveling over great distances. Most of the day is assumed to be spent in the drudgery of travel with the chance to come across something interesting, along with certain time taken up having to do important logistical tasks related to travelling.
  5. Timescale - Seasons: In this section time is generally measured in months and represented by seasons where the players have decided to spend an extended period of time in a (hopefully) safe and civilized location.
Now, I don't think any of these concepts or the procedures in these various sections are new. But I do think organizing and thinking about RPGs in this manner is. I don't think I've come across a rulebook or RPG that really organized itself in this way or to this degree.

I find organizing rules this way makes them much easier to understand and reference at the table. The referee just has to think, what are we doing? At what pace are things happening? If danger is present and things are happening fast, then I should probably look for rules within the Encounters section. If they're really slow with little danger present, probably in the Season section.

I find thinking about rules this way also really helps to find what level to abstract things to when making new procedures. Like take my chase example from above. Imagine a typical chase from a movie. Running through a market square. Stuff is happening pretty fast. You'll probably want to resolve things on the Encounter level of abstraction. It seems to naturally fit there. 

But also, what about more long distance chases? Like the party see's a group of enemies on the horizon and they begin to chase them? Well, that's a different level of abstracted time that seems to fit in with traveling. You may need some procedures there also. Maybe call it pursuits instead of chases as it better describes the situation. Maybe a "chase" can even lead to a "pursuit" where the Referee is able to seamlessly switch from different levels of abstraction. If the players escape the bad guys in the market square and get out of the city, they find themselves being pursued across the dusty plain. You as the Referee can switch from the one scene to the other, switch from the one set of procedures to another.

Additionally, by grouping your procedures based on the level of abstracted time, you're able to come up with some core mechanics for that level of abstracted time. For example in Encounters to me one of the core mechanics is having an initiative order. Where things are happening fast. Who goes before who and does what is really important because actions are resolved in sections. 

So if I were making chase rules for this level of abstraction I'd probably include an initiative order. Where while the party is running as a group, they all have to make some kind of attribute roll in order to outrun whomever is chasing them. If a person fails, they begin to stumble a bit and lag behind. The next person in the initiative order has a decision. Do they try and grab whomever is lagging and help them to their feet and run faster? Do they try and create a distraction by toppling that apple cart? Do they turn and fire an arrow at an enemy and hope that causes some commotion? 

Likewise, if I were to make a set of procedures for pursuits I'd probably use the the core mechanic for that level of abstracted time. Mainly, by using a hexmap for travelling and the concept of a watch. Where each watch represents eight hours. Where the players have to decide, do we try to march faster and cover more ground than we normally could in 8 hours? Do we explore the hex we're in and try to setup an ambush or just hide? Do we try to go slower but conceal our trail? Where are we going? Which route should we choose on the hexmap? What do we want to spend our 8 hour watches doing?

If you have a couple really good core mechanics or procedures for each level of abstraction, it becomes pretty easy to modify or interpret them to handle new interactions and situations in the world. Oftentimes the hardest part is picking the the level of time abstraction that feels right, a task made much easier and more intuitive if the rules themselves are arranged by order of time abstraction.

In conclusion, ever since I had this little revelation about organizing RPG rules this way I've been revising my house rules in this format. It's been a bit slow going and is tedious at times. I don't think anything that I've talked about is particularly new in the OSR scene but I have found in re-organizing my house rules like this has forced me to fill in a lot of gaps. 

As mentioned before I'm using Whitehack 3rd edition as the base for my homebrew ruleset. When I'm done writing it up I'll probably post it here on my blog for all to read. I don't think I would ever publish it or have ambitions to that end. I've stolen waaaaay to many mechanics and rules and things from various OSR systems to feel comfortable publishing it.  

3 comments:

  1. Having never read Whitehack, does it have different mechanics applicable to timescales?

    Reading this really brought to mind the UVG procedures for encounters, exploration, and travel - common mechanics (with specific implementations) applied at the relative timescale.

    ReplyDelete
  2. Kind of, Whitehack I think has some parts pertaining to hexcrawls and stuff like that.

    I tend to prefer it or use it as my base as it's similar to most OSR stuff but is a a roll-under system and has some very elegant rules for classes and abilities and other things.

    ReplyDelete
  3. Notably Pathfinder 2e is organized like you're suggesting, with the game systems materials split into three gameplay modes: encounter, exploration, and downtime. Then additional systems, game advice and so on fit into the specific modes. This isn't obvious if you look at the core rulebook though, as a lot of it is character creation material (what you're calling static rules).

    ReplyDelete