Golden Core 1: JIT plot compilation
This will be a first post in a sequence of posts talking about the techniques I consider to be core to the GMing toolkit. I’ll start with Just In Time plot compilation.
As usual, if you are confused about any terms, make sure to check out the glossary, and if you are looking for other posts, check out the blog map.
Just In Time is a concept from manufacturing and engineering. The idea is that whenever you have one thing - manufacturing process, execution of the program, etc - that depends on another thing - some part being delivered, compilation of the executable code - you can sometimes put off dealing with the dependency until the last possible moment. This has some desirable properties:
You do not have to front-load all work related to dependencies: if you need to do several things that each have their own dependencies, you will initially only do the work related to dependencies of the first thing, saving you time.
Costs related to various forms of storage - physical for items, computer memory for computational work, mental for things you have to think about - are reduced, because you only have to store results you will need immediately, throwing them out immediately afterwards.
If for whatever reason you end up not needing to do one of the primary things you expected you would need, no work is wasted, because you never did the precursory work in the first place.
In a way, you act like a very lazy student who needs to write a paper: you put off work related to writing it until the last possible moment. If ten classes give you ten papers to write on the same day, then you are not swamped with trying to write ten papers that same day: instead, you write them just before their respective deadlines. If you need to do research for them, you don’t have to hold ten different threads of research in your head in parallel. And if some professor drops the requirement for the paper, well, you haven’t done any work anyways.
The idea behind Just In Time Plot Compilation is to apply the same concept to GMing. Before I explain how this is done, let’s look at what goes into GM work. Imagine that your players are hunting a vampire in a town, and you are preparing for a session. Your thinking may go something like this:
Vampire lives in a castle, and players may decide to assault it. This means I need a map of the castle, and stats for some guards.
But what if they try to sneak in? I should try to figure out how well-guarded the territory around it is, and how easy it is to climb or pierce the walls.
What if they try to catch the vampire outside the castle? I’ll need to figure out where he goes in the city…
What if they go away from the city, find some enemies of the vampire, and try to get them in on the fight? Ugh, where is my political flowchart...
Every step here involves some very clear prep work: finding maps, designing stat blocks, making time tables, etc. Similar sort of thinking works on the scale of a campaign: GMs have to think of plot arcs, villain movements, design essential locations, and so on.
But the only reason GM has to do large amounts of all this work is that GM doesn’t know what players will do and what they will like. This type of uncertainty increases the amount of required prep time exponentially.
This is where Just In Time Plot Compilation comes in. The idea is to simply not do any work up until the last possible moment.
I mean “last possible moment” extremely literally. In this model, the ideal time to think of a design of a dungeon is at the same time as you are drawing it, and the ideal time to think of a larger campaign plot is when your players ask about it.
The benefits of doing this are obvious. If your players have 12 different choices in front of them (10 of which you thought of, and 2 of which you didn’t because they came up with them themselves), then ordinarily you would have to design 10 different consequences of those choices. You could of course not prep for some of the choices, and risk players choosing it anyways. On the other hand, with JIT, you only do work for the one choice players actually use: 1/10 of the work. Furthermore, your position remains largely the same even if players do something unpredictable: if you never try to predict anything, everything is equally unpredictable.
You may say that this is madness: the entire reason people plan things in advance is that they can’t improvise them on the spot. This is also why GMs stereotypically dislike players doing things they didn’t expect: this forces them to improvise from an unprepared position.
In my opinion, this is not substantiated by evidence, or rather, there are other hypotheses that fit the evidence equally well. Yes, it is possible that the reason people plan things is that perfect improvisation is outright impossible. However, it is also possible that they are simply untrained in it.
For example, take roundabouts. They are not common in the US, while being fairly common in Europe. One of the reasons is simply that US citizens are not trained how to behave when going through one, and thus get scared. This doesn’t mean that going through a roundabout is impossible, and likewise, it doesn’t mean that improvisation is impossible: just that most GMs don’t acquire the skills for it.
Of course, because most GMs do not have the skills to do complete improvisation, they also get scared to try it, and that leads to a slow growth in skill.
This isn’t just some yarn I am spinning here: over the past half year, I have ran two campaigns. In one of them I mixed planning and improvisation about 50/50. In another one, I skipped structured planning altogether. My prep time before sessions of the second campaign was exactly zero seconds. Nonetheless, campaigns were quite successful (first one is now complete; second one is still in progress).
I did not have any prior experience at improvisation. At first, my improvisational abilities were naturally lacking, but now they have improved. I believe that practically any GM should be able to do this.
Naturally, JIT has its weaknesses as well: for example, certain styles of play, based on a large degree of simulationism, are not going to be entirely suited to it. Making a complicated intrigue fit together is likewise difficult by improvising it on the spot. But the point of JIT is not to use it as the only technique (unless you are doing it as a stunt). The point is to be way more willing to improvise and thus save on unnecessary prep time. In fact, by using JIT your long form plotting will improve, because you could focus your energies entirely on the aspects that can’t be handled by JIT.
So how do you do JIT specifically? Well, let me walk you through my thought process during the latest session of my campaign.
Before the session: the players are located in a town, working for an adventuring guild. Previously, they were told a location of an unlooted dungeon in the vicinity. They are also trying to locate a hidden cult hideout in the forest. I suspected they may head to the dungeon or to the hideout; I already had a map of the hideout from a previous session when I thought it likely players would head there. I did no additional preparation for the session.
I described where the players were, caught up one of the players that skipped a previous session, and asked them what they were going to do.
Players told me they would head to the adventuring guild and ask them if they had any new jobs. I didn’t expect this, but this matters not: JIT means that I can easily handle any such pivot. On the spot, I decided they’d get an escort mission with a researcher who was heading to the same dungeon they already knew about.
Creating NPC descriptions and names myself is difficult; I use an NPC generator for that. Many GMs do, but usually they only resort to it for throwaway NPCs. My advice is to use it for everything.
Once the players got hooked on the idea of going to the dungeon, I needed several things. I needed a map for the dungeon, a reason for it to be there, a reason for the researcher to go there, and a reason for why it wasn’t looted yet. I had previously come up with a precursor orc civilization that was located in these parts: the dungeon then naturally becomes some kind of structure for them. The simplest reason why nobody bothered to go and loot it is that it didn’t have any money or valuables in it. It can’t be a temple: it would have been looted for magic knowledge. On a whim, I decided that it would have been a granary: I had been reading about grain storage in medieval times some time before. All these decisions took maybe a dozen seconds as the researcher was introducing himself.
As the party was riding towards the location, they asked the researcher why he was interested in the dungeon. Since I already had a reason for the dungeon to be there, the researcher spun a story about trying to find out more about the types of food that was grown in the past. As I was telling it, it linked naturally with the themes of wild nature encroaching on civilization and difficulties of sustaining regular farms.
At the same time I was drawing the dungeon. We were playing on roll20, so I could do it in another map tab without the party seeing. I drew an irregular line for the cliff face, with a recess for the main door of the dungeon. Then I started drawing straight corridors that split into five large rooms where grain would have previously been stored. I added “airlocks” before the grain rooms on a whim.
Obviously the dungeon needed some enemies. I opened the bestiary for appropriate CR and saw something-spider. Bam: now the dungeon is filled with spiders. As the players were poking at the door of the dungeon, I added them to one of the rooms, and found a bigger token for boss spider.
Having only spiders would be boring. I added an air elemental to one room, with the idea that he’d be the “cleaner” of the dungeon. Over time his powers weakened, and he wasn’t able to chase the spiders out of the other rooms. He’d speak ancient orcish, which the researcher also would speak, and would show up if players entered the requisite room.
From this point I was done working on the dungeon and led the players through it. They fought the spiders and won.
After this dungeon ended, I based the rewards on what the party achieved: getting the scientist in, clearing out the spiders, and talking to the elemental. Spiders gave the party some poison, and the rest was in gold.
I hope this makes the method clear: you base all decisions on things you have already decided about the setting or campaign, the things you are well read on, and things that make sense in the moment. After a little practice, the process becomes natural and flows well.
I hope that this technique may help you achieve better result in your own GMing. Meanwhile, if you enjoy what I write, you can subscribe to receive updates by email: