# Idea In the making of [[Cairn Hack for Cyberpunk Modules]], I don't actually have enough real people or time to play test this game as much as I want before releasing a first draft. To help with that, I think I can employ the use of [[Large Language Model|LLMs]] to help "smoke test" the game early on (certainly _not_ as an alternative to a real life playtest though). Whether this works is sorta unknown, but I think it will work _ok._ # Design The *Narrative Engine* is a fully incrementally computed "AI" driven and played [[Tabletop Role Playing Game|Tabletop RPG]] game engine with a primary focus on testing and reviewing game rules. It does not generate content for playing tabletop RPGs and is not intended to be played with or by humans. ## Architecture The *Narrative Engine* can be thought of as a program that is continuously invoked over a git repo's state and produces mutations to the folders in that repo and commits them. Every commit is resumable and the engine itself contains very little state itself, its primary role is to facilitate communication and constrain the actions of the "players." The game state is encoded in an application with a simple core loop that takes the place of "going around the table" during traditional tabletop RPG gameplay. The DM is a model with almost complete access and the majority of control over the state of the game world. It is responsible for narrating and decision making, as with the traditional human counterpart. Actions the DM and players can take are tightly controlled by *Narrative* via scoped tool calls. All application state is continuously persisted to a well-defined text-based filesystem hierarchy with changes tracked using the [[Git]] version control system. After every action of a player or the DM, a commit is generated tracking the result. Every commit is fully resumable by the *Narrative Engine* allowing for branching and replay-able storylines. The general flow is something like: 1. A campaign state is loaded or created 1. It should generally include files with information about NPCs, the world, and the events of the campaign 2. A session is started and corresponding folder is created 3. A scene is entered, creating a new state directory for the scene within the sessions directory 4. The DM begins narrating what is happening in the scene 5. The DM either asks all players for an action or goes around in *turn order*, asking for the actions of a specific player 6. The player(s) respond with an action 7. The DM updates the game state and narrates the responses 8. Go to #4 There's a lot that can happen between each step, but are heavily dependent to the rules of the game being played, so are out of scope of this document. Just be aware that the actions that the players and DM are allowed to take is dependent on some abstract game state. For example, if the players are not in combat, the **attack** action is unlikely to be available. ## The Repo The standard campaign structure is a templated filesystem with a well-known structure inside of a git repository. The DM and players have constrained access to read and write to the information tracked in the filesystem indirectly through *Narrative.* The initial structure looks something like this: ``` world/ npcs/ Character 1/ ABOUT.md STATS.yaml TIMELINE.yaml players/ Player 1/ ABOUT.md STATS.yaml TIMELINE.yaml events/ Event 1/ ABOUT.md story/ Story Event 1/ ABOUT.md misc/ Misc Topic 1/ ABOUT.md sessions/ session 1/ ABOUT.md 001-scene/ LOG.yaml player-1.md player-2.md SUMMARY.md SUMMARY.md SUMMARY.md current-scene next narrative-version <other state> ``` The `ABOUT.md` is a [[Markdown]] with [[YAML]] front-matter that contains the primary information for a topic. The DM has mostly unrestricted access to query and read information in the `world/` directory at any time via recall and record tool calls. Players have access to information on their own characters freely, but can only append to `TIMELINE.yaml` with new major events that happen in their life and cannot directly control their `STATS.yaml` (which contains an analog to their character sheet). As scenes and sessions are played, the DM and players can explicitly "speak" at the table by appending records to the scene's `LOG.yaml`, where the table's outward conversation is stored. At the end of a session, the log for each scene is summarized and put into the sessions's `SUMMARY.md` for future use. As a scene is playing out, the DM or player can ask questions or perform actions. At almost any point, a player and the DM can converse privately, that conversation is recorded in the `<player name>.md` file. To facilitate the stateless operation of *Narrative*, the `current-scene` file is a plain text file containing the path to the currently active scene. `next` contains the action the narrative engine will be taking next, and `narrative-version` is metadata about the code and game used up to this point in the game's history. Other files may be created by the engine during the development process. ## The Application The prototype of the *Narrative Engine* is a command-line application. It can initialize a repository with the appropriate state and begin executing the game. A major part of the applications functionality is controlling the context of the GM and agents and providing them with constrained options for actions they can take. How do I want to have the application manage context? I think a yaml file in the players world folder and a top-level file for the GM would be ok. Or perhaps we unify the current state tracking with the context for the GM.