Designing a Solo Engine: Closed Loops and Forward Motion

Exploring closed-loop design for the Adventurous solo rules

Why Solo Rules Are Hard (And Why I Care About Getting Them Right)

I’m currently working on the solo rules for Adventurous, and while doing so I had a bit of a revelation: if these rules are going to work the way I want them to, they need to form a closed-loop system.

The most challenging aspect of designing good solo rules is the fact that there is no GM to push the game forward. That might sound self-explanatory, that is the whole point of solo play, but it’s easy to forget just how critical the GM is to making a game worth playing.

The GM is the one who presents interesting opportunities, introduces danger, escalates situations, and forces hard choices. Without that pressure, a game quickly becomes flat.

I realized that if the solo rules can’t deliver on that, I won’t enjoy playing them. And if I don’t enjoy my own game, then what’s the point?

I thought about this a lot. I tried approaching the problem from different angles, read just about every solo ruleset I could find, and it wasn’t until I accidentally ran into the old solo board game Barbarian Prince that things clicked. That game doesn’t wait for you to invent motivation, it pushes you forward.

That’s when I realized the direction I wanted to take: a closed-loop system.

The Missing Engine in Solo Play

In group play, the GM is the engine.

They introduce problems, react to player choices, interpret outcomes, and keep the fiction moving. Even when the rules are vague, the GM fills the gaps.

In solo play, that engine is gone.

That means the game itself must take over that role. Not just as a ruleset, but as a Solo Engine, a system that continuously generates momentum, context, and direction.

If the engine stalls, the game stalls.

This is the lens I’m using while designing the solo rules for Adventurous.

The Core Problem in Solo Play

Most solo systems struggle with the same issue:

You’re often left asking,
“Okay… what do I do now?”

Not because there are no options, but because there’s no clear next step. The rules generate situations, but they don’t always tell you how to act on them.

In GM-led play, the GM fills that gap naturally.
In solo play, the system has to do that job.

That’s where I think closed-loop design becomes critical.

Definition:
A closed-loop system is one where outcomes feed back into the system itself, creating new pressure, new situations, and clear next steps without requiring external direction.

The goal is a solo engine that never let’s the game stall, one that creates forward momentum through the combination of procedures and moves.

Closed-Loop Design (How the System Pushes Back)

A Solo Engine needs more than random tables or oracles. It needs internal momentum.

What I’ve realized, and what I’m actively designing toward, is that closed-loop design might be the right way to get there. Not as a rigid solution, but as a guiding principle.

By closed-loop design, I mean a system where moves and procedures work together to continuously push play forward, without the player having to invent momentum on their own.

The game doesn’t just respond, it directs.

That, to me, feels like the keystone of a good solo system: the engine pushes you forward whether you feel like it or not.

A Highly Simplified Example Loop

This is a deliberately simplified example, but it illustrates the idea clearly.

You start your campaign in a village.

From the outset, the procedures apply pressure:

• Each day consumes Food

• Safe rest and food costs coin

• Running out of either leads to consequences

You can rest and resupply at the village tavern, but coin is limited.

So you make the Explore a Settlement move to look for work or useful NPCs.

That move introduces a rumor about a nearby ruin and the promise of treasure.

You leave the village and make the Travel the Lands move.

You reach the ruin and Delve it. Inside, you defeat a wight, but leave cursed.

Now the procedures apply pressure again.

Curses can’t be ignored, and curing one requires a temple, which only exists in cities.

There is no temple in the village.

So you travel again, make your way across the land, and eventually reach a city.

In the city, you find a temple, spend coin to lift the curse, rest safely, and resupply.

You’ve completed “the loop”, but you haven’t returned to the same place.

You started in a village.
You end in a city.

Along the way, you’ve explored the world (and procedurally generated it as you went), discovered new locations, met new people, and experienced new dangers. The loop doesn’t keep you in place, it expands the map, adds detail to the world, and creates real adventure.

Once the immediate problem is solved, the procedures apply pressure again.

You need coin.
So you explore the city.

And the engine keeps turning.

Just to clarify:
It’s not about moving from settlement to settlement, that’s not what I mean with “loop”. It’s about how one action creates a chain of consequences that keeps the game moving forward without reaching a dead end.

It’s Not Just Moves, It’s Moves and Procedures

One important clarification: this design does not rely on every move explicitly pointing to the next move.

That would feel forced. Artificial. Gamey.

Instead, momentum comes from the interaction between clear procedures and move outcomes.

The daily structure is predictable.
Resources are always ticking down.
Certain problems require specific places or services to solve.

Moves resolve uncertainty.
Procedures apply pressure.

Together, they create forward motion without dictating player intent.

Clear procedures are critical here. Without them, the system would stall. With too many forced transitions, it would feel mechanical. The balance is what makes the loop work.

---

So far, this might sound like any other Moves-based solo engine, but there’s a key difference, and it requires significant effort in the design process.

Moves will always have clear, explicit outcomes.

No more “introduce an obstacle” or “add a complication.”
That’s too vague. It doesn’t help the GM, especially when the GM is also the player. It just creates extra interpretation work and fuzzy constraints. I don’t like it.

In the Adventurous solo rules, every move resolves into specific consequences. You’ll never have to invent fallout on the spot.

That matters, because this is where fairness breaks down in solo play.
What is a fair complication when you’re playing alone?

The game answers that for you.
It will hand you clear outcomes, whether you like them or not. I do like that.

I wanted to create a system that made the GM’s life as easy as possible, this is true both for Adventurous and the upcoming solo rules

Why This Fits Adventurous Specifically

When I designed Adventurous, one of my core goals was to make a system that did everything it could to help the GM run a better game.

With the solo rules, I need to stick to that same goal, but now the player is the GM. That adds some extra pressure on my end.

How do you support the GM when the GM and player are the same person?

This is where I think closed-loop design really shines.

The combination of procedures and moves constantly pushes the game forward without the player having to come up with everything themselves. Whether you like it or not, you are propelled into adventure.

That’s important to me, because these solo rules are meant to support a game-game, not a creative writing exercise (that’s also a valid solo play format, but it’s not the one I’m trying to design for)

A solo game where you don’t know what dangers lurk around the corner.
Where you don’t know if the cult leader will negotiate, or try to boil you alive.
Where traps, curses, and bad decisions can end your story abruptly.

The rules need to be clear, firm, and sometimes unforgiving, but always fair.

Final Thought

Good solo play isn’t about simulating a GM perfectly.

It’s about building a system that never lets the game stall.

In solo play, the system is the engine.
Closed-loop design, whatever the “correct” term may be, is how I’m trying to keep it running.

If the engine doesn’t keep turning, the game stops.