I recently ran one of my patented Jank Homebrew Oneshot TTRPG games for some friends during a weekend of oneshot RPGs and I thought I would write a bit about the design process - both because it might be interesting to the players to peek behind the curtain and for my own future reference.

Prior Art and Design Goals

I’ve run a decent number of oneshots, with varying levels of Jank Homebrew. A big input into the design of this game was a game I ran somewhat recently in which the players did not do any character creation (or pick prefilled characters), but instead built the characters through play, making choices about their characters as they came up in the game. I was fairly happy without that went but there’s always room to improve.

I think that there’s a (possibly unsolveable) problem with starting a onshot. If you do character creation then you have to do rules explanation and lore introduction up front, without interaction, in order to prime the players with enough information to create their characters and make meaningful choices. On the other hand if you present them with pre-generated characters, they don’t get to have input into who they are playing and also have a bunch of information they need to internalise to play the character.

My newest attempt at cutting this knot was to have most of the concrete mechanical information hidden from players when they pick (pre-generated) characters. The specifics are then revealed through play, which drip-feeds it at a digestible pace. I kept the character descriptions very light on detail, trying to encourage players to fill in the gaps. The idea really came together with the concept of using sticky notes to conceal the information in a way that could then be peeled away, creating an intriguing and satisfying experience (hopefully).

Setting and Prep

I spun the wheel of stock adventure settings in my head and landed on Wild West, always a good one. I had the idea to set it on a train to create a somewhat constrained environment that the players would explore and “conquer” gaining more freedom - initially they are locked in one car, break out and explore the train, and learn their way around it. That said I always intended to be very open to unconventional ideas about how to traverse the train - rooftop climbing springs to mind and did happen in the game.

I wanted to add some more fantastical elements so the idea that it was all a simulation all along as a “twist” came pretty easily. I also made the train staff robotic in order to add more fantasy on the surface.

In terms of prep, I subscribe very strongly to the Don’t Prep Plots school. I came up with the opening “cutscene” which was pretty much set in stone to give the players a basic introduction and motivation. I then had a general idea of the layout of the train, some things in it that would probably create obstacles, and the main “puzzle” they had to solve leading to final confrontation. I had one idea for an outside intervention that would shake things up at an appropriate time (bandit attack) which I deployed when I felt the time was right.

One thing I did not plan at all which ended up happening was PCs falling off the train and being stuck in the desert landscape outside. I had the general idea that the train was travelling through a kind of cartoon looping background scenery, and when it came up that someone was going to fall off I ended up realising how well it worked for them to do so and have to figure out how to get back on the train when it looped around again.

One thing I try hard to stick to is “plan problems, not solutions”. Because the PCs will inevitably think of a solution you never would have in a million years, and then you’re stuck trying to figure out how to resolve that. It’s better if you don’t have any solutions you thought of ahead of time that you’re too attached to. I did have the main “puzzle door” which served to motivate the PCs to have to go away and put in some proper effort to unlock which I couldn’t budge on, but I at least had a few different possibilities in mind (and could have been flexible if someone had come up with a suitably unhinged alternate idea).

Mechanical Design

I didn’t want to use a Powered By the Apocalypse ripoff, often my go-to system, as I knew another game in the weekend was already doing that. So I came up with a very simple original system. The core of this was just “roll a d20” and get under your skill number. I did it this way round as I wanted “high number on sheet == good”. This meant that, somewhat counterintuitively, rolling low is a good and “natural 1” is the best result. There’s a tension there that you can’t really fix without introducing more math like D&D skill modifiers, which I didn’t want.

Outside of that I wanted to encourage players to reveal new skills, and not spam their revealed good skills too much over the course of the game. I was worried someone would find a high number in “shoot” and then just shoot every problem for the entire game. To do this, I gave (d&d style) advantage when using a new skill for the first time, and capped the number of times you could use a revealed skill normally before it started to give you disadvantage. Getting the cap right was both important and tricky to judge, but I think I actually managed to nail it for the length that the game ended up running.

Apart from just assigning numbers, I gave each character one unique ability. I think this is about right - it makes characters unique but doesn’t overload the players with a bunch of things to remember for the oneshot. Design notes on individual characters:

GOOD KARMA

You can use a luck point to reroll any roll. Describe what lucky event happens to change the result. You have this many luck points: ☐ ☐ ☐ ☐ ☐

A pretty conservative one, but I think adding the requirement to describe the lucky event saved it as that created some nice roleplay opportunities. May have been too generous with the point allowance.

TWINS IN SYNC (x2)

When Benjamin/William is attempting a roll, you can assist with one of your revealed skills, with justification. Benjamin/William gains (possibly stacking) advantage. Costs a ☒ in that skill.

One of my observations of past games is that players love to help each other with important roles. My intent here was to create a built-in help mechanic that encouraged a specific pair of players to stick together, to see what would happen. In practice on the day we were down a player and one person volunteered to play both twins at once. This could have gone wrong but the player in question was more committed to the “bit” of playing twins rather than trying to break the game so it worked out.

There was some confusion about this ability and how it worked, and it is counterintuitive that you are incentivised to “help” with your worst skills since helping doesn’t involve a roll. I think I should have delayed having the player reveal this skill until it was actually relevant and then made sure they understood it.

THAT’S DOCTOR VACATION TO YOU

If you can justify how being a doctor helps with a roll, gain (possibly stacking) advantage. Cannot be used on consecutive rolls.

This was almost an in-joke based on the tendency in a group that involved some of the players to try and justify unlikely connections to get bonuses on rolls. The idea was that the player would use it on every roll possible and the “Cannot be used on consecutive rolls” clause was a built-in regulator to keep it in check.

However on the day the character went to someone I hadn’t played with before and they didn’t end up using it as much as I anticipated. I think I should have encouraged them more, and explicitly told them I was expecting them to use it constantly.

WILDCARD

Your skills don’t have numbers prefilled. Instead, when revealing a skill roll 3d6 to generate the value. If you roll below an 8, add an additional ☐ . If you roll above a 14, cross one off instead.

This was always a big risk since it hinges so much on the rolls to generate the skills affecting how it plays out. However when I thought of the idea I couldn’t not put it in, because the concept was so fun to me.

On the day the player who got this character rolled kind of badly on a lot of their skills so it ended up feeling weak. I don’t think I got the balance right on this one, but there are a lot of ways it could have been tweaked and pushed in different directions. Not sure what the best fix would have been.

How It Played Out

I’m not going to recap the whole thing in detail, but the short version is: pretty well. I think the pacing and length where about right for where we were in a weekend of oneshot RPGs and it seemed like everyone had fun.

There was one thing that I wish I could take more credit for planning ahead of time which worked really well. The players ended up going up to the engine to figure out what they needed to do, and realised they needed to go all the way to the back of the train. On the way up they… acted like PCs: robbed, murdered, stole, caused general chaos. This meant that on the way back I got to confront them with the consequences of their actions, which was very fun for me personally.

Overall pretty happy with this. I probably can’t run the same system again but I’m probably going to keep iterating towards my mythical “perfect oneshot system”.