Hi all.
With Claude at my side, I’m working on the “LLM as a Master for RPGs” project with two different architectures.
Both architectures have one thing in common: the AI is given the ability to “record events” in the engine, where “event” is anything that changes the character’s state or the environnement state… changes in hit points, fatigue points, number of coins, number of arrows, statuses linked to various effects are all examples of events.
So the AI doesn’t have to remember: it simply records events in the engine, which will remind it, each turn, of the current state of the game world.
I’m testing two architectures:
LLM Narrated RPG
LLM Mediated Multi User Dungeon
The first features single-player adventures with a very specific focus: a goal to be achieved, upon completion, the adventure ends. All the narration (including NPC interpretation) is handled by the AI.
The completion rate is 90%, and by mid February, I want to be online for the public.
In the second game, players are presented with a text-based open world for multiplayer. Here, too, the NPCs are all interpreted by the AI. No fixed adventures, but free exploration and interaction with other PCs and NPCs.
The completion rate here is lower: it’s a project I’ll finish after the first.
I’ll add: it’s a lot of fun to see how the AI interprets the NPCs. The results are realistic to the point of often being surprising. Forget the usual sycophancy. An orc prison guard used swear words, insults, and various threats: all extremely appropriate. I had fun responding in kind, and obviously it ended in a fight, even though the combat system wasn’t fully developed yet! 
I’m looking for testers for the English version of the games: no API keys required, no money required (of course) …. just play and give feedback please.
ARCHITECTURE OF LLM MEDIATED MUD:
In LLM Mediated Multi User Dungeon, AI is used in three distinct ways.
Parser: Converts the player’s single action or pool of actions into a json file to pass to the engine.
Example: “I drink all my healing potions, draw my sword, and rush toward the north door.” Each action is a dictionary: the resulting json file will have one dictionary for consuming all the healing potions in the player’s inventory (a single action with the ‘all’ modifier), one dictionary for equipping the sword, and one dictionary for the ‘fast’ movement action.
Hallucination Impact: That pool of actions is misinterpreted. In the tests I’ve done (and there are MANY, all automatic), this has NEVER happened: Gemini 2.0 (the cheapest of Google’s models) is very good at pattern matching.
Narrator: Converts the essential narrative elements passed to him by the engine, along with modifiers related to the character’s status and the environment, into elegant, easy-to-read prose.
Example: The character is walking along an old mule track. The resulting prose will vary depending on various factors: is it daytime? Is it the dead of night? Is it raining or hailing? Is the character drunk, dazed, deafened, or blinded? All of this will influence the narrator’s words.
Hallucination Impact: A single description goes awry. This has NEVER happened. Consequence on gameplay: zero.
The flow is therefore:
Input from the player → Parser → Engine → Narrator → Output to the player
Interpreter: This is an AI that controls an NPC with the same interface as the human player. To keep costs down, two constraints are applied.
Each NPC deactivates if the character is far away.
Each NPC has an anchor from which it never strays too far. The anchor can be fixed: the farmer who never leaves his farm, the innkeeper who never leaves his inn, the craftsman who never leaves his shop. The anchor can also be the character: the mercenary who follows you on your adventures and covers your back or acts as your bodyguard.
Another important optimization is this: the Interpreter talk directly to the game engine. So the flow is:
Input from Interpreter → Engine → Output to the Interpreter
Hallucination impact: As happens in the products of large software houses, it’s possible for a “joking” user to force the AI out of its role and ask a medieval fantasy farmer to advise them on the best PC model to buy or how to make excellent pasta alla carbonara… and what do I care? If they want to ruin the gaming experience by forcing the AI, that’s none of my business: everyone has their own fun. The important thing is that the AI doesn’t spontaneously abandon its character, and this is very easy to ensure, even if the theoretical possibility of hallucinations can never be reduced to zero.
Here’s the thing: this architecture lends itself well to open worlds. It can be used for a single-player game, for a game where a small group gathers in a private cloud to play, or even, without modification, for a true massively multiplayer MUD.
Possible evolution: if the game becomes a massively multiplayer MUD, the restrictions on NPCs could be loosened and you could have fully autonomous NPCs without anchors and without automatic deactivation when no characters are present. It’s like having a geek with strong acting skills (AIs, when they’re up to it, are excellent actors), connected to your server 24/7, playing their character.
ARCHITECTURE OF LLM NARRATED RPG:
Here the engine work as a Man in The Middle between the player and the LLM.
So the flow is:
Player ←→ Engine ←→ LLM
When the player send a message to the LLM the engine attach to the message an invisibile payload with the instruction for the LLM about how to handle the game and the game state.
When the LLM send a response to the player it can include a json in the response with command that modify the game state. The json itself is not shown to the player.
Example:
“You enter the tunnel. Is dark and creepy.“ {“MOVE“: “dark_tunnel“}
I would like to start the tests for LLM Narrated RPG on mid January and for LLM Mediated MUD on end January! (please respond here if you are interested)