Run a Long RPG Campaign With ChatGPT as Game Master

ChatGPT makes a better game master than it has any right to. It improvises, it plays a nervous innkeeper convincingly, it takes the stupid thing you decided to do and builds the next hour out of it.

Then, a few sessions in, the smith you murdered in an alley greets you warmly by name.

Usually nothing broke. A long conversation can outgrow what the model reliably holds, and the early part of the campaign stops being in view. Everything the story was built on is still true in your head and no longer anywhere the model can see. This is the same failure a long chat always has, just in a setting where it is unusually painful, because a campaign is nothing except continuity.

Kamil, who plays solo, got tired of this and built something for it: twenty-one pages of rules for how a game master should remember a world. He emailed us about it unprompted, then sent the whole thing and let us write it up.

He is careful about how it was made, and it is worth repeating in his words. He is not a professional programmer. The system came out of a long back and forth with ChatGPT, where he brought the requirements, the problems from actual play and the decisions about how he wanted the game to behave, and the model helped turn those into rules, compare approaches and find the weak points. That is not a footnote about credit. It is the most interesting thing here, because what came out is a memory architecture designed by someone whose programming knowledge, in his words, is fairly basic.

Twelve notes, not four hundred

The obvious structure is a note per NPC, a note per location, a note per quest. His does the opposite. Twelve notes, each one holding sections inside it:

• GM_RULES the full rules of how to run the game. Read first, every turn.
• CAMPAIGN_META setting, tone, pacing, difficulty, the agreed configuration.
• CURRENT_STATE where we are, right now, this scene.
• PLAYER_CHARACTER the character's persistent state, skills and what they actually carry.
• NPC everyone who matters, with what they know, want and owe.
• LOCATIONS places, and what is currently true about them.
• ITEMS who owns a thing, who is holding it, where it is, whether the player can reach it.
• THREADS open quests, mysteries, obligations, threats, consequences.
• FACTIONS organisations, their goals and their relationships.
• WORLD_STATE what is happening off screen while the player is elsewhere.
• GM_SECRETS the hidden truth, and who has worked out how much of it.
• CHRONICLE compressed history. Outcomes that still matter, not a transcript.

Two reasons for aggregating. One is a limit: he built this on the free plan, which allows twenty-five notes, and a note per NPC would run into that limit quickly. The other is better. A game master with four hundred notes has to go looking before it can think. With twelve, it knows where everything lives, so before a turn it reads the rules and the current state, then only the notes the scene actually touches.

The scene, and everything that outlives it

CURRENT_STATE is the scene. Location, time, who is present, the player's condition, immediate threats, what the next turn needs. When the scene moves, old values are replaced rather than piled up. It is not an archive, and it stays small on purpose.

The other notes hold what has to survive the scene. That split is the whole design, and it forces the question that makes the system work: when something happens, what part of it needs to outlive the room it happened in?

Four verbs and one test

His answer is four operations:

REPLACE when the old value has no meaning of its own. The character's location, health, mood, who is holding the sword. Nobody needs the itinerary of every room they walked through.

KEEP when it can still change the future. Debts, promises, a grudge, a reputation, an injury that will not heal, what an NPC saw.

COMPRESS when the outcome matters and the detail does not. His own example: a missing merchant, a witness, tracks to a mill, bandits, a rescue. All of it collapses to one line in the NPC note. The merchant is grateful to you and offers free lodging. The working history goes, the thing that can still change a later scene stays.

DELETE when it is finished and inert.

And a single question decides which: could losing this plausibly change a decision the world makes later? If yes, some trace of it stays. If no, it goes.

That test is doing more work than it looks. It is not asking whether something was important, or dramatic, or a nice moment. Plenty of dramatic scenes leave nothing behind, and a throwaway line from a guard can decide a trial nine sessions later. The final rule in his GM_RULES says it better than any summary: do not remember everything, remember everything that still matters.

An NPC saying it does not make it true

This is the part worth stealing even if you never roll a die.

Every fact in the campaign carries a marker for how it is known: [FACT], [NPC CLAIM], [HYPOTHESIS], [UNESTABLISHED], [GM SECRET], [RETCON].

A drunk in a tavern tells you the baron ordered the murder. That is not true yet. It is a thing a drunk said, which may be a lie, a mistake, or the plot. It gets stored as [NPC CLAIM], and the rules forbid promoting a claim to a fact without grounds, most strictly during compression.

Without the markers, he says, he found it too easy for rumours, lies and mistakes to become facts later, after compression. That is the specific danger. Summarise a few sessions carelessly and hedged reporting quietly turns into world truth: the rumour becomes the answer, the mystery you were running is solved by a filing error, and the model will defend it, because as far as it can see it has always been true.

Which is a knowledge base problem wearing a cloak. Meeting notes, research, customer interviews, anything a model summarises for you later: a claim recorded as a fact is worse than not recording it, because the confident version is the one that gets read.

He tried databases first

Before this he experimented with MongoDB, Supabase and Neon. They all worked. He moved anyway, and his reason is not the usual complaint about setup:

For my particular use case, using a general-purpose database as long-term memory for ChatGPT felt more complex than I wanted. I was looking for something simpler that I could understand, inspect and maintain directly without having to think too much about the technical layer behind it.

Which comes down to one requirement:

I wanted ChatGPT to be able to use the memory, but I also wanted to be able to inspect and correct it myself.

He is not a professional programmer, and did not want the state of his campaign to become something he could only reach through the model that was also editing it. Twelve notes with obvious names can be opened by a human on a Tuesday. He can read THREADS, see the model has quietly mangled something, and fix it in place, which is not a debugging session, it is just editing a note.

What to take from it

Even if the closest you get to a dungeon is a Jira board, the shape generalises:

1. Aggregate, do not shard. A note per thing is a search problem you inflicted on yourself. Group by kind, section inside.
2. Separate the working state from the lasting state. One place for now. Everywhere else is for what survives now.
3. Decide what gets dropped, not just what gets kept. A memory that only ever grows stops being memory and becomes an archive nobody reads, the model included.
4. Keep the certainty. Fact, claim, guess, unknown. The distinction is easy to write down and expensive to lose.

None of this needs anything clever underneath. It needs somewhere both of you can write, and rules that travel with the notes rather than depending on you to paste them.

Running it yourself

His original is a ChatGPT Project, a block of project instructions and twelve notes. We turned it into a template so you do not have to assemble it: RPG Campaign Memory sets up eleven notes and condenses his rules into the folder's instructions, in place of a separate GM_RULES note. Kept in the folder, the rules come along whenever the model reads a campaign note, in ChatGPT and Claude alike.

To start a new campaign:

1. Connect Hjarni to ChatGPT or Claude.
2. Paste the template's URL into a chat and let it install. It creates eleven notes, so on the free plan check that you have room.
3. Say: start a new campaign.

It then asks, one step at a time, what kind of world this is: setting, tone, pacing, how deadly, how much mystery, who you are. Only once you approve does the first scene begin.

After that you play. There is no save command. The one piece of upkeep is a periodic audit, roughly every twenty to thirty meaningful turns or after a big chapter ends, where the model checks the notes for contradictions and compresses what has gone stale.

Two honest limits. The rules only reach the model when it reads a campaign note, so a turn where it skips its notes gets none of them. If you play inside a ChatGPT or Claude Project, Kamil's own bootstrap in the project instructions closes most of that gap:

Before every game turn, read CURRENTSTATE from the current campaign folder before responding. In a new chat, read CAMPAIGNMETA first. If the correct campaign folder cannot be identified unambiguously, do not guess.

And all of it is instruction rather than guarantee, which is exactly why the audit exists.