Automating Interactive Fiction Logic Generation with LLMs in Emacs
19 comments
·March 31, 2025spudlyo
C-x_C-f
How did you get started? Was it mostly plug-and-play or was some nontrivial hacking involved? I use emacs and I normally wouldn't mind shaving a yak or two, but right now I'm swamped with work and I'm kinda scared of getting sucked into a rabbit hole.
dskhatri
gptel is mostly plug-and-play. The docs offer a comprehensive overview: https://github.com/karthink/gptel
zoogeny
This is one of the most promising uses of LLMs that I have found in my own work. Many times I have an idea for a refactor or even a feature but I have this mental reluctance just due to the amount of code I would have to write. Like, I have this counter in my head on the number of key-strokes it will take to write a wrapper object in several places, and I hesitate.
Just being able to tell an LLM "rewrite all of this code using this new pattern" and then dozens of code sites are correctly updated is a huge help. It makes me consider bigger refactoring or minor features that I might normally skip because I am lazy.
IngoBlechschmid
Gwern shared an idea how to exploit the strength of current-generation LLMs, despite their weaknesses, for "create your own adventure"-style fiction. https://gwern.net/cyoa Having people vote on AI-generated potential continuations should yield better results and cut costs at the same time.
From the title I thought this was an implementation of Gwern's idea, but it's not.
ianbicking
There have been experiments in wiki-style cyoa generation (letting the public create options instead of an LLM), but they suffer the same problem as LLM-generated stories: aimless wandering and lack of consistency.
(As I think about it, an LLM generation should be thought of as a many-author situation, as each generation comes in cold)
Stories need pacing, which exists over many passages, not just at the choice level. And then the passages should all be based on a single underlying world. Both of these fall apart quickly without a guiding author.
I think this is resolvable with LLMs and appropriate prompting, but the naive approach seems cool only until you actually play out a few stories
th0ma5
How would this be resolvable ?
ianbicking
To ground the story in a consistent world: build up secret world lore behind the scenes, and provide that to the LLM as it makes choices. As the story is expanded the lore will expand. But this gets complicated as time progresses, as things that are "true" later in the story aren't earlier in the story (when some events haven't passed), and choices _should_ modify what happens so there isn't "one" truth. An LLM can handle some of that complexity natively, just by how the story is structured and allowing it to put conditionals into the lore. ("If the Snow Queen hasn't been defeated, she will sense when the hero is inside the castle")
You'll also need to keep track of context, so you can place the current passage in the lore. I doubt it will be self-evident. Some of this can probably be shown to the user as well as "metadata" of sorts (like a location name).
You could also pre-build the lore entirely, and then as the LLM expands out choices instruct it to stay within that lore. This is probably easier, but it'll seem less exciting to see it build out those passages. You'll want to include major choices in the lore itself so it can build out some of those conditional parts of the story.
The rhythm is much harder. Pre-building the entire lore will probably make this much easier. I'd probably throw a few queries at Deep Research to get ideas and terms for story structure that I'd want to apply. There's two major issues I see in incrementally created LLM generated stories: never getting to the good parts, and accelerating too fast.
The first is probably worse and more common: the LLM will build up anticipation, but it doesn't know the conclusion and will keep putting off any conclusion. It reminds me of Lost (the TV show)... you can tell the writers didn't have a plan, and only made things worse as they introduced more distractions that couldn't be made into a cohesive reveal. If you already have an outline then it should go forward. Another option is to have the LLM produce conclusions at the same time as it produces choices, and give it criteria for what a good conclusion is. These don't have to be full passages, but will be notes you pass on as the next passage is created.
Going too fast can happen too. If you just ask ChatGPT to write a CYOA story it'll probably stop abruptly when it sees the opportunity to just finish up. I don't have a clear idea here, but I'd try to think about splitting the story into acts, giving those acts clear purposes (as story structure). Then I'd aim for a certain length to each act, but let the LLM decide the exact moment one act moves to the next.
lawlessone
>Having people vote on AI-generated potential continuations should
So the story never ends?
ZeroGravitas
I've thought that an LLM wrapper that's able to turn valid moves that you haven't phrased exactly as the old parser expected into one of the acceptable versions, could be a good quality of life improvement to classic text adventures.
I thought this might be related based on the title, but it's more about refactoring code.
noufalibrahim
This is probably the most tightly specified use case of an LLM that I've come across so far.
kleiba
What strikes me as odd in the video: why would the author not fill the paragraphs?!
iLemming
Probably because then, it would make your paragraphs 'rigid', whereas if you have visual-line-mode and don't truncate lines — the text would just wrap around — you only need to adjust the width of the window. That works nicely in "distraction-free" modes like writeroom-mode.
I used to fill the paragraphs all the time, turns out — it's really better to leave them as they are, because you can never get the satisfiable number of `fill-column` — the default works in some cases, for others, you'd want it to be wider, etc.
dskhatri
writeroom-mode looks great! I typically have my Emacs frame split into 5 windows (thanks to revive.el). Instead of spawning a new frame (C-x 5 2) to write a blog post or work on the book, I'll try writeroom-mode.
bradleyy
Honestly, seeing this, I'm 1/2 tempted to revisit org-mode and retrying emacs as a dev environment.
Don't get me wrong; I use emacs all the time, I just can't seem to make it work for me when working with teams of people on large-ish software projects.
But maybe org mode is worth a revisit as a "managing my ADHD" tool; it's got to be better than Jira, haha.
spudlyo
Emacs yak shaving can lead to high dopaminergic stimulation, while it may help you mange TODO items, it's also a great way to do something fun that's tangentially related to your actual work.
For a big payoff you can combine Emacs, GPTel, mcp.el, and the Jira/Confluence MCP server[0] so LLMs can manage your tickets for you.
iLemming
> I just can't seem to make it work for me
Maybe you just don't have sufficient exposure to Elisp. Emacs Lisp is one of the best blackmagicfockery automation tools, you can do tons of interesting things. Just the other day I got sucked into a big, long-going Jira Epic, I just needed to find every single PR in my work GitHub Orgs related to specific Jira tickets. Then I wrote this - https://github.com/agzam/github-topics
Once you learn some Org-mode, you will see how awesome it is to be able to turn just about any kind of data into an outline format - I read HN and Reddit in Org-mode format, keep my notes, my Anki cards, my code experiments, my LLM musings - all in Org-mode.
anthk
I wouldn't use that for Inform6. If you can't grasp the simples OOP language ever...
Also, Inform6 allows you far more interactivity than a CYOA game. Which both are systems based on states, but a text adventure allows timers, random events, even chat simulations...
GPTel is a very powerful interface for working with LLMs in Emacs. It took me a while to understand that its real value isn't what you get with M-x gptel, which creates a dedicated chat session and buffer, but rather the ability to sling prompts, context, and LLM output around in a native Emacs way. You can add to the context from dired, from a file, from a buffer, you can select from various prescribed system prompts for different functionality, you can prompt from the minibuffer, the kill-ring, the existing buffer, a selection, you can have the responses go to the minibuffer, the kill-ring, a buffer, the echo area -- it's extremely flexible.
I have a little helper function that uses gptel-request that I use while reading Latin texts. It sets the system prompt so the LLM acts as either a Latin to English translator, or with a prefix argument it breaks down the grammatical structure and vocabulary of a sentence for me. It's very cool.