A dawning

30 Nov, 2024

The purpose of this blog is to record my process creating Heist on Cloud Keep, my thesis for college and first foray into ttRPG publishing.

The purpose of this post is to give an overview of where I’ve come from, where I want to go, and how I’m approaching it. I have a few formal goals for the project:

1. It must be a playable OSR adventure.
2. It must have kick-ass illustrations.

The following weeks will illustrate the scale of my hubris, dear reader.
But if you’ve come to follow along the journey, let’s set some foundations.

(The) Heist on (a) Cloud Keep

Three and a half years ago, the summer before I went to college, I drew a picture of a castle made of clouds.

Later in the day, for we were at a family reunion, my cousins and I sat on a worn log table swatting mosquitos from our thighs. It was no decision at all to play some D&D, but what about? I volunteered the idea that maybe we could rob my giant’s keep.

Two four-hour sessions later, the giants had trapped all but one of the players (who had fled earlier) in a stone barrack, and probably best they did. If memory serves, I had little notion of what they sought to rob the giants of besides “a golden egg which, when rubbed, granted its user a single wish.” The castle’s secrets would remain, like it, immaterial.
But whether because the session never really resolved, or my latent interest in meteorology kept it warm, the idea settled down in my skull
and slept comfortably.

Now in the present, nearing the end of my post-secondary education and tasked with developing my thesis, it’s woken up to make the most peculiar keening noise. It’s much bigger, now, and of an altogether different shape.
I learned more over (a careful) breakfast:

Where I’m trying to go

The adventure seeks to simulate a heist for old-school renaissance¹ systems, leveraging their conservative inventory and challenge-resolution mechanics to support that genre’s exhaustive planning and tense execution. I haven’t seen this done before. I will also augment this using my premise’s own traits:

1. Giants are large, and their architecture reflects this. Traversing a giant’s keep will inevitably feature the employ of climbing pitons to conquer the furniture.²
2. Clouds’ ever-changing shapes³ confound would-be invaders, as rooms built within them might constantly re-order themselves. They’re also located in the sky.

Knowing these, we can begin to sketch out what our precocious adventure might look like fully grown.

The party begins with a patron or a fence giving them a map of the keep, annotated with its movements and inhabitants. Their goal is the golden goose (not sure if it’s literal, yet) in its vault. Then, they’re left to plan with full purses and access to their city’s markets. Planning their route should take a long time, possibly more than half of session, and should include contingencies in case things don’t play to their favor. Some of their tactics will inevitably rely on the keep’s features: for example, the boiler room may be accessed to speed or delay the movement of the keep’s rooms. Some of their tactics may require splitting the party, either to distract the giants or to prepare for time-sensitive steps in the process. Either way, once they have a route and give the go-ahead, they enter the keep.

During this time, meta discussion of the plan and players’ part in it is verboten. OSR’s strict timekeeping also becomes important.
A communication problem ensues: the party must execute on their complicated plan without error and under time pressure. Accessing and traversing the keep without alerting the giants, retrieving the goose, and escaping with it is very possible—but, whenever a mistake is made, the keep chugs along, forcing the players to adapt their plan, their path to success literally moving further away from them each turn that passes.

Isn’t that terribly mean?

Yes. In this case, I’ve designed the premise in such a way as to best emulate the experience of planning and executing a heist. This differs from the approaches of other ttRPG heist games, such as Blades in the Dark. BitD attempts to reconcile the improvisational nature of most ttRPG challenges with the difficulty of winging a heist by giving Ocean’s 11 style flash-backs to the party, enabling them to plan for those challenges ad-hoc.

HoCK will do no such thing. Rather, I intend to embrace the error-intolerant nature of heists, and also therefore their demand for precise, clever planning. My design philosophy is built on a framework established by earlier conversations I’ve had with my friends, but I’ll try and bring you (dear reader) up to speed as I go. For a start:

In seeking to make a game about something, one with a theme, there are two broad approaches I often see used in different circumstances.

1. Using metaphor, as in Celeste, Braid, or Stanley Parable.
2. Using structure, as in Sid Meier’s Civilization, Flight Simulator,
   or Outer Wilds.

Even if you’re unfamiliar with the games I’ve listed here, the difference in approach is simple. Let me try and explain.

1. Celeste is a game about overcoming anxiety and depression through self-forgiveness. Its gameplay features 2D platforming up a mountain.
2. Microsoft Flight Simulator is a game about flying airplanes. Its gameplay places its player in the cockpit of a modern aircraft, including all its real controls, and makes them fly using those controls.

Celeste does not attempt to induce anxiety or depression in its players through its gameplay. Rather, it seeks to give them an understanding of anxiety and depression using its mountain and platforming protagonist in an analogy about them. Microsoft Flight Simulator’s theme is identical to its gameplay: it cuts as few corners as possible in giving players exactly the experience of an airplane pilot, to the extent that it can be used to train real-life airplane pilots. Sid Meier’s Civilization and other more macro-simulation games like Cities: Skylines or RollerCoaster Tycoon cannot possibly give players the granular experience of managing an actual civilization, city, or rollercoaster park, but their gameplay abstracts those activities rather than using metaphor to describe them.

In writing HoCK, I want to use mechanics to give the players an authentic feeling of running a heist, including its more complex and punishing aspects. This is, I think, essential in making my player's experience feel valuable, their choices meaningful, and their outcome earned. I’d just like to add to my heist a sense of fantastic adventure as in other beloved OSR activities, like dungeon-delving. I’ve chosen a premise which features those fantasy elements in a way that mirrors or emphasizes the genre’s tropes: guards become giants, even more untouchable, to be avoided; a bank becomes a keep, inaccessible, high in the sky; and the treasure becomes a golden goose, the fairy-tale’s infinite money glitch.

Noontide already

If you’ve come this far, thank you. I’ll be trying to post on this blog weekly, and making progress enough to justify that schedule. As I bring up my adolescent adventure, I remind myself that I’m working in dire constraints:

1. My thesis is due come next April. I have less than half a year.
2. My thesis’ focus is on its illustration, not its gameplay. I’m trying to optimize for two things at once.

My next milestone is a prototype. I’d like to have run a functional playtest in 2 weeks, by the 14th of December, or failing that, have that session scheduled. Before I do that, I need to drafts done for the castle’s movement, its giant inhabitants and structures, and have a functional procedure for preparations. This is what I’ll be working on in the meantime.

If you’d like to correspond with me, ask questions, give advice or just send best wishes, I have a discord account called Wormod, and a server called Estival. I hope you enjoyed this overview of Cloud Keep: whence it came, whither it goes, and how I seek to take it there.

I also hope the skies stay pretty above you, dear reader.