Saturday, October 2, 2021

Tooling for 1:1 Timescale Games

I've had boring, practical questions about how to run 1:1 timescale games rolling around in the back of my head for I guess a couple months now.

  • World-design considerations.
    • Many of the games of that era seemed centered around a single city and/or megadungeon (Blackmoor, Castle Greyhawk, and the City-State of the Invincible Overlord, for example), and Jeff's Trollopulous seems to have followed a somewhat-similar pattern.  How important is having a central locus like this?
    • Is the right way to lay out a region for this style of play more radial, with wilderness increasing out away from The City, rather than a linear civilization->borderlands->wilderness gradient from a large, civilized heartland?
    • What's the right scale, so that travel is long enough to be a meaningful allocation of time-resources, but not so long that the game grinds to a halt as everyone is traveling?
  • Session structure.
    • BDubs' game seems to have a core community of players who play adventuring PCs and have a regular session, often dungeoneering, every week, plus some set of patron players doing their own thing in the background.  This seems like it doesn't scale up arbitrarily (but what does, really?).
    • Jeffro's adventurer-level players seem to play more like patrons, doing their own thing, maybe jumping an injured patron and taking his stuff, rather than partying up and having regular sessions where they go into dungeons.  
    • And then there's Gygax's example, where (purportedly) people would show up at his house unannounced and he'd run a session.
    • Under what circumstances do which of these different approaches to sessions (or lack thereof) work well?
  • Keeping the information organized.  What's the right (or at least adequate) way to keep the information about who is doing what when where (and when they'll be finished) organized?  And how do you keep (at least some of) that information secret, to let the interesting behavior emerge from patron interactions under fog of war?
    • Index cards?
    • Spreadsheets?
    • Shared google calendar?
    • Paper calendar that only the DM has access to?
    • Gantt charts (lol)?
    • Database?
  • How do you make such a style of play amenable / accessible to more casual players rather than just "elite auditor mindset" players?  (I'm bummed that I can't find either BDubs' or Jeffro's post where that phrase was invoked)

I think I have an angle of attack on one of the information organization question, at least.

The answer is databases.

This post brought to you by my assignment at work this week, auditing code that interacts heavily with databases

Why?  Because you can automate around them.

The barest, crudest sketch goes like this: have a table of ongoing operations with start dates, end dates, and descriptions.  When someone starts something, add it to the table.  Have a table of players, including their discord IDs, and a table containing (operation ID, player) pairs of "players who should be notified when this operation finishes".  Have a discord bot that runs every night at midnight, checks to see if any operations have finished on day rollover, marks them complete, and notifies players (and probably DM) by PM.

Ha, maybe run the bot at 5PM instead, right as people are getting off of work - a character's work for the day is done at that time too.  And any "orders" gotten in before 9AM the next day are completed by 5PM the next day.

But this doesn't really let you answer the question of "what is any particular character doing at the moment?"; there's no notion of character there.  So maybe we also want a table of characters (including an "owning player" column), and then a table with (operation ID, character ID) pairs indicating "this character is currently unavailable for play because they're busy with this long-running thing".

Of course, once you have a table for characters, it's very tempting to throw their stats and XP in there too...  and a table for all the unidentified magic items they're hauling around, with both the in-world description you've given and the actual identity of the item.  And how many charges that wand that they figured out the command-word for but never really properly identified has left.

It would be kinda nice to put wilderness expedition logistics information in there too and update it on nightly rollover...  but that gets a bit thorny because then we need a notion of a party, which presumably can have a set of characters (as well as a count of NPCs like mercenaries and shared equipment like wagons), and which might be busy with an ongoing operation (like overland travel).  So then we run into this: do we have a table of party/operation pairs, for parties that are busy?  Do we then query party membership to determine which characters are busy, or also still have a character/operation table and have to check both it and party membership?  Or do we just have a party/operation table, and have parties of only one character sometimes?  That might be kind of nice, for the case where you pick up friends along the way (or lose friends along the way and a party goes down to just one member).

Do we want some notion of location?  Of grid coordinates?  (I really hate programming against hex grids)  Parties having a location which is updated overnight based on their overland speed?  (But then I would need to encode their paths too, which sounds painful...  maybe this is a good argument for Arnesonian "12 miles a day regardless of terrain")  But it would be neat that if there are multiple parties in the same location in the wilderness, they might have a chance meeting.  Automatic random encounter determination, putting a pause on the travel operation until resolved?

If we're already considering notifying players in response to stuff in the world, we could extend that for information flow and intelligence.  Maybe having a spy in a location adds you to the notification list for start and completion of operations in that location.  Maybe operations should have secret vs common-knowledge descriptions, with spies having some chance to uncover the secret descriptions and town gossips yielding the common-knowledge ones.  Spies might dispatch messengers in response to some operations beginning or ending, creating operations in their turn for the messengers to travel to their destination.  Some notion of queuing news at a place (to be received on your return) might be necessary.  Automatic weekly collation of common-knowledge events in (say) a central city into a "News in Kezmarok" style digest sent to all players could be neat, and a good way for players to advertise "looking for group" or patrons to advertise "looking for temporary, deniable help".

Finally, NPC actions.  If you have all this tooling for keeping track of what PCs are up to, it seems natural to extend it to also keeping track of what NPCs are up to.  Clocks on steroids; give "orcish warlord gathers horde" a concrete end-date and set it up to notify just you, the DM, when it finishes.  And if players interfere, move the end date around accordingly.  Likewise, if you want to send an NPC party on a wilderness/trade expedition, make a series of operations, one to travel there, one to buy and sell goods for a week or two, and one to travel back.  NPC party raids a dungeon?  Make a single die roll to see how they did, make an operation where they take a week of bedrest and recruiting, and then put them out of your mind.  They're in motion, you don't need to worry about them for a week.  But your players might hear about them automatically.

This starts to look a lot more like a living world.   And the table of operations starts to look like a log of all the stuff that happened outside of combat, which would be a pretty neat artifact of a campaign (much like player-produced maps are a neat artifact). 

It also seems like it would be pretty easy to keep it game-system-agnostic.  Character stats seem like the most likely place to break this, and I'm not even sure I really want them.


  1. How does dungeon crawling work in this? If they are 8 levels down do they just get out. The party can't stay in it? That confuses me.

    1. This is sort of a persistent problem in open-table dungeoneering games, noted by Rients back in '08 ( ), and not particular to 1:1 timescale. I believe I have read that there was a norm at Gygax's table that you didn't end a session in the dungeon, but I don't know how exactly it was handled (penalties for staying over, or just not calling it a night until you made it out, or...?)

    2. I run a game in a similar fashion, and I've set it up so the players tend to run out of resources in about the same amount of time that we want to stop. That's the key.

  2. We run a 1:1 wilderness campaign with no more civilization than a trading post to come back to. (5e with lots of homebrew and house-rule sidegames; new blog at

    For travel during a session, we use a bunch of homebrew charts and the caller picks up one of every die type and rolls them all together once per 4-hour watch or once per 6-mile hex - my charts are designed so that it starts on a d10 roll and branches out from there, but that includes the chances of an encounter, signs of an encounter, weather changes, resource challenges, non-combat encounters, flora/fauna, and a bunch of other stuff. Happy to share those if anyone needs them for inspiration. It makes travel interesting and takes session-time to accomplish but isn't overbearing.

    For between-session downtime we use a Slack instance with a #bluebooking channel, which is useful in a couple of ways: it allows 'active downtime players' to accomplish their downtime in a central place, and it allows me to keep track of who's where when by using Slack's /remind function to notify future me that something has occurred. So if someone is at the trading post and undertakes a downtime action that will take 5 days, I just say '/remind me "Caradoc finishes smelting ore" in 5 days' and 5 days later Slack will remind me of that and I can post in our #bluebook channel that Caradoc is done and that he's available for new downtime. Or I can set the reminder directly to Caradoc's player instead. Not sure if discord has the same /remind capability but this has made the calendaring aspect pretty seamless for us. I typically post a quick summary in the #bluebook channel each morning of who's where. I also use /remind to help me keep track of off-screen monster movements and patron player agent actions.

    Players can undertake travel between locations during downtime but it's not risk-free - they still roll on the same charts as a caller would in play and encounters can happen; when they do we typically use a simplified combat roll and interpolate consequences from it. I probably wouldn't kill a player on a downtime combat roll gone wrong but if it goes poorly enough they could end up captured, lose gear, mounts, or NPCs, or could end up badly wounded and unavailable for the next session as they recover.

    I also have 4-5 long-distance patron players controlling factions spread through the wilderness, who I also interact with on Slack or by email - they get a monthly sitrep from their majordomo and a list of domain action options, they chooses some projects to pursue and dice are rolled to see how that will go over the course of the month. So far, player interaction with these factions has been low, but there have been intersections.

    My GM notebook is a physical notebook, but anything the players need and some of my session notes and location notes live on a Notion instance ( so that the players can see the house rule subsystems and so I can cut and paste things from the internet that I want to keep track of. Works pretty well and allows low-maintenance basic databases in the form of charts that expand into pages.

    So I don't think you necessarily need a whole huge programming project to make it work, but I do agree that a 1:1 campaign benefits from some digital tools to make the GM's life much easier. For me those are Slack (and its /remind feature) and Notion, but I'm sure there are many other ways to make it all sing.