The Rhythm of Procedure

I've been thinking about how to structure the rhythm and progression of the game lately, so my apologies for the scattered and incomplete character of some of these reflections. I think part of keeping a good pace going in the game involves careful management of the rhythm of procedures that constitute it.

There are, in my mind,  five basic types of procedures by which one can play the majority of any adventure game. These procedures are all loops - you iterate and reiterate them over and over again while the PCs do something, shifting between them based on which is the most appropriate for the PCs' current actions. I mainly want to talk about the first three in this post, since they're the ones that are the best defined and that vary the most from game to game.

Encounters (Combat, socialising, and some types of urgent problem solving)

Site Exploration (Marching around, mapping, searching areas, etc.)

Overland Travel (Travelling from hex to hex or landmark to landmark, searching hexes, etc.)

Recuperation (Spell recovery, healing, dealing with long term status effects, etc.)

Downtime / Projects (Pursuing personal projects, the domain game, creating magical items, etc.)

The turn, the round, and other abstract measures of time are all durations that exist to regulate the rhythm of the procedural loops that form gameplay. The actual time they measure (10 minutes, 6 seconds, whatever) is secondary to this more important function.

The value of rounds, turns, and watches is that each one allows you to synchronise all of the decisions, rolls, and consequences of a particular iteration of a procedure in a way that prevents the formation of a lot of asynchronous cycles that are demanding to track. I use the following rubric:

The round - One iteration of the encounter procedure
The turn - One iteration of the site exploration procedure
The watch - One iteration of the overland travel procedure

NB: The "watch" or "shift" is designed to serve the same function as the round and the turn do but for overland encounters. If you are running overland games, I suggest using it, pegged to either six or eight hours, depending on how often you want the PCs to have to make decisions while travelling.

The actual length of these units of time is strictly secondary to their value laying out the rhythm of play and its progression. That's why you can have a combat round be anywhere from six seconds to a minute without affecting play, but the moment one combat round doesn't represent a complete set of decisions, rolls and consequences, you get chaos.

For the purposes of game-play, the second, the minute and the hour as units of time are inferior to the round, turn, and watch because they lack any connection to a procedural loop. You can turn them into ersatz rounds and turns, pegging the durations of effects and procedures to them, but I think this tends to create procedural loops that are too short for the tasks we want them to handle - the second is too short for combat, the minute too short for dungeon exploration, the hour too short for wilderness exploration (or resting).

By too short, I mean that the ideal length of a loop is long enough to contain the decisions, the rolls, and the determination of their consequences within it. Having to remember decisions made more than one iteration of the loop previously tends to tax people's memories, and it destroys the effectiveness of the loop iterations as counters.

e.g In combat, you want to declare that you're going to hit someone, roll to hit, and then resolve the hit if it's successful. You don't want to declare one round that you're going to hit, wait another round to roll, and then a third round to resolve it.

People confuse having a common unit of time (an hour, say) with having a synchronised procedure, even though the opposite tends to be the case. Using this sort of actual time measurement (in particular, hours) encourages desynchronised cycles that test one's ability to keep track of them.

e.g I've played in many games where a task takes eight hours and another task takes six hours, and what ends up happening most of the time is that the referee just abstracts out to the scope of a full day, everyone counts up the rolls they need to make, and then they do them en masse (three for the first person, four for the second person, etc.).

If the rolls fail, then the referee has to back-calculate to when this failure occurred, and discuss what happens at that point with the player, and it just turns from a smooth forward progression of time into a more zig-zagging movement that jams up much more easily.

The more you can synchronise all of this procedurally, the easier it is to run. That synchronisation helps both you and the players keep track of the progress made during play.

Beyond this point, I have a few scattered reflections to tack on here at the end:

1) Historically, the turn as a unit of measurement has been deprecated as site exploration procedures have become less and less formalised, while the combat round, the clearest and most robust procedure in the game, tends to be the one people default to when the other procedures aren't as clearly laid out, both as designers and as players of the game. That's why when you're dungeon-crawling in lots of new school games, you do it round by round instead of turn by turn. The firmer your site exploration procedure is, the more you need something like the turn to handle it.

2) The reason "the encounter" as a duration in some new school games confuses lots of people is that it's neither a real unit of time nor a single loop of a procedure. Instead, it's the worst of both options - a unit of time without clear boundaries, both within the fictive world and within the procedures of the game itself. This illustrates for me what happens when you screw up the rhythm of the game (thinking of it as a series of encounters and rests suspended in a non-time of exploration or travel like lumps of marshmallow suspended in jello).

I would just allow a "per encounter" power to continuously remain in effect until the procedure type you're playing changes. So a power invoked during site exploration remains in effect until you shift to overland travel or dealing with some encounter, and so on. This sounds weird, but works well in my experience. I mostly avoid this problem by changing "per encounter" powers and the like to some other duration.

3) The recuperation procedure tends to iterate each day. You might want to append "The day - One iteration of the recuperation procedure" as a fourth statement above. I didn't because I have recuperation as an option during the overland travel procedure so it occurs each watch, but I think for most people it's a daily procedure.

Good questions for a referee to get straight in their own head are:

a) When in the day the recuperation happens (Do healing and spell recovery happen at dawn, midnight, etc.)?

b) When the wandering monster or other interruptions occur, do those happen before or after the recuperation?

One nice effect of linking it to watches was to eliminate the 15 minute adventuring day. Once you pick the watch action of "searching a site" you're committed for the next six hours and can't invoke the recuperation procedure until the next watch. Blame it on adrenaline, paranoia, and traumatic flashbacks - you're too keyed up to rest until enough time has gone by.

4) I think downtime's ideal unit is either the week, the month, or the season, and have seen all three used successfully. Seasons are good in games where the main downtime activity is domain management, months work well in games focused on expeditions or that require training to improve characters' powers, and weeks work well in games mostly driven by narrative urgency, where the PCs will almost never have a month or three in between the villains coming up with some plot.

Summarising Key Elements

One of the skills I have that makes me a good referee is a particular style in my games whereby I summarise and restate the most salient and relevant aspects of a problem or situation immediately before asking players to figure out a solution, and then I do this again several times throughout the problem-solving process that they engage in.

It's not particularly difficult or challenging or insightful to do so - as the referee I can reference, remember, generate, and / or adjudicate which elements or aspects of the problem are the ones that must be overcome in order for a solution to be acceptable. But it's also surprisingly uncommon for referees to do this. I don't think there's any good reason not to, so I assume it's mainly due to referees either forgetting about doing this or never having learnt this for some reason. Therefore, this post is a simple exhortation to remember to do this.

There are three additional techniques of restatement that I think can improve one's practice of doing this even if one already is. The first is simply to pair proposed solutions with the aspect of the problem they purport to resolve during the restatement. This demonstrates progression and prevents constant relitigation of things which the players have already developed a successful solution for. It also highlights when a purported solution is inadequate to the task.

I often grade these slightly, mentioning whether a proposed solution completely trivialises the aspect such that no roll or expenditure is required, or if it merely allows a roll or expenditure that would otherwise be impossible, or if it represents an opportunity for an ordinary roll or resource use.

The second is to prefer to present the aspects in a flat and clear way. Sometimes referees want to keep some aspects of the problem hidden until the player characters are part-way through the task. This can be done, but it has to be done accepting that it will cause the player characters to pause and deliberate mid-task, and it must be done in a way where there is one cannot simply stop the solution, return to the initial state, and then start over from scratch. If the latter is possible, then the referee has simply wasted everyone's time through their lack of foresight.

By contrast, presenting all obvious and even some inobvious elements of the problem during the initial framing of the problem, and then including them in restatements and summaries of the problem allows the players to accommodate them meaningfully in their planning. It also encourages avoiding wasting time where the players ask questions the referee knows are meaningless and irrelevant. These aren't always bad, but en masse across the course of a session, they represent lots of wasted time, indecision, and inaction.

The basis of the game is making decisions, and while being tricked and fooled can be interesting for players, a referee should employ them sparingly in ways that emphasise the quality of surprise instead of merely keeping them as a tedious valence of ordinary moments of play.

The third technique is to use the question answer-question pattern with summaries and restatements. Once again, this helps deliberation progress, by providing a way of refocusing consideration on remaining elements of the problem. Using questions like "What information do you need to make the decision here?" helps avoid players getting bogged down in irrelevant side-issues.

Anyhow, if you already do all of this regularly, know that as a player I appreciate it greatly when referees do it, and if you don't, I would suggest experimenting with these techniques and adopting them if you find them successful.