Converting Books Into Visual Novels Part ?: The Overall Process

Oct 14, 2026

Public Domain Pulp's first fourteen visuals novels — from Cup of Gold to Journey to the Center of the Earth — were all made with the same five overall steps:

  1. Have an LLM convert a book.txt file to a pulp.txt file, adding in line breaks, (n)ame identifiers, (s)peaker identifiers, and (e)xpression tags.
  2. Populate the remainder of the non-visual metdata required by pulp.txt by hand.
  3. Generate the sprite set (as determined by the prior metadata).
  4. Generate the background set (as determined by the prior metadata).
  5. Visually review and edit the final visual metadata.

The specific approach to each step varied and improved with each new visual novel (involving a mostly-increasing number of many substeps!), but at a high-level, the five-step process remained roughly constant. So the plan then was always to have a five-part "Converting Books Into Visual Novels" series documenting each step with a blog post. Easy enough.

Except that now, going into visual novel #15 (Fathers and Sons) — and with the Part 1 post being the only main-entry post so far to escape the draft phase — the five-step approach's fixedness is already starting to unravel.

Spooky Scary LLMs

LLMs' contextual intelligence has progressed terrifically in the past year. Scarily so, perhaps even. But from the perspective of book-processing, the change is all positive, since what was impossible in January is now very much possible here in October.

The reasoning (at the time) behind separating Parts 1 and 2 of the original conversion process was that AIs (at the time) were not smart enough to handle populating the full set of (pre-visual) pulp.txt metadata sufficiently correctly. Their output would include so many mistakes that a human would end up having to spend more time cleaning up those mistakes than they would have spent in the counterfactual of just populating the metadata themselves by hand.

And this was true at the time, at least from my testing, at least for most of the types of metadata required by pulp.txt. But importantly, the LLMs were still good enough at processing a limited subset of the metadata. Therefore, rather than populate all the metadata in one pass, we have two separate steps: Part 1, where the LLM does its initial limited pass; and Part 2, where the human does their complete pass, building off the LLM's work.

And those conclusions held true for all of nine months or so, but in the past month, the LLMs seem to have undergone a critical step-change towards being more contextual, more agentic, and most important: more smarter. Arrogant human that I was, I thought I could blog-document faster than the LLMs could render by blogs obsolete. But it turns out: no.

The New Process?

So if Parts 1 and 2 are now combinable, which they seem to be, the five-step process turns into something more like this:

  1. Have an LLM convert a book.txt file to a pulp.txt file, adding in line breaks and all types of tag metadata that can be set prior to the visual edit.
  2. Review and tweak the outputted pulp.txt by hand?
  3. Generate the sprite set (as determined by the prior metadata).
  4. Generate the background set (as determined by the prior metadata).
  5. Visually review and edit the final visual metadata.

…With the long-term necessity of the second step being unclear. Certainly it has been necessary so far in the ongoing conversion of Fathers and Sons, where the LLM still indeed did make many mistakes that needed fixing. But of course, this was only the first such attempt at this newer streamlined approach, and I can only see the LLMs' initial outputs getting better over time (both from being smarter and from better prompting).

Will the LLMs ever reach a state of making no mistakes? Perhaps, perhaps not. And even in that hypothetical state, there could still be benefits from having the human-driven edit pass in the loop. But it seems increasingly dubious to claim that having the separate human-driven Part 2 pass will always be a worthwhile tradeoff (in a world constrained by finite time and attention).

Still, for now, some version of the Part 2 step still seems necessary, even with its narrowing scope when compared to the original process. So, thinking in terms of what the new process looks like right now, the changes raise some documentation-related questions:

Would that technical documentation was easier such that I could teleport all the disjointed ideas and heuristics in my head into my text editor in neatly organized fashion, without loss of information (i.e., not just asking an LLM to write it up for me), I wouldn't mind having a series of semi-redundant posts: Part 1, Part 1 (v2), Part 2, Part 2 (v2), Part 1 (v3), etc. But, for the time being, process-posting is still hard and too time-consuming.

So, as stopgap, I think the best approach (for now) is just to quickly write up at a high level, without getting lost in difficult things like details, what the current (for now) process looks like. (Without guarantees that this is what it will continue to look like!)

1. The LLM Creates pulp.txt

The previous version of this step (documented as Converting Books Into Visual Novels Part 1: The First Edit — Creating the Starter pulp.txt) involved breaking a book into chapters, feeding each chapter individually into Gemini 3.1 Pro, having it create its limited subset of the metadata, then rebuilding the chapter parts all back into one file, fixing up the many compiler errors created from Gemini's various goofs.

The updated process is conceptually simpler: we can feed the entire book all at once to GPT-6 Astra via Codex, where it can invoke the Pulpifier compiler directly to iteratively build the entire pulp.txt file, where it can handle populating a much larger subset of the metadata, including previously un-automated tags like (b)ackgrounds and (a)ages and e(x)tras and so on.

The full prompt given to Astra is pulp-prompt.txt, which contains much of the same explanations, heuristics, and examples that would go into a Part 2 blog post, if ever written. The catch being that pulp-prompt.txt is written for an LLM audience, not a human one, and so it's rather less readable than one might want. Still, the main ideas are in there, just not with trivial formatting flair like paragraph breaks.

2. The Human Edits pulp.txt

The previous version of this step also involved re-reading through the book via pulp.txt, except that now, instead of having to assign all the backgrounds and sprite modifiers and so forth, the human (me!) can just review what the LLM put down, making tweaks and metadata edits as-needed. And currently, numerous editing fixes still are very much needed:

The full set of heuristics the human (me!) has in his head (my head!) is still imperfectly communicated in pulp-prompt.txt, and so even though current-gen LLMs already seem strictly more intelligent than current-gen humans (e.g., me!), they still end up constrained by the stupid human's inability (my inability!) to fully formulate thoughts into instructions.

But in the future? Who knows. If the LLMs could learn to mind-read, that would help matters tremendously.

3. Generate The Sprite Set

This previously had two substeps: first creating the image prompts, and then running the prompts against a prompt generator (and iterating). But even this has also changed from the recent LLM intelligence improvements:

Instead of going [human-written prompt -> AI-generated images], the process has become, roughly: [human-written vibes -> LLM-written prompts -> AI-generated images]. This makes the process more convoluted, but still somehow better in practice. The reasoning behind why it's better would require writing up the full Part 3 documentation blog post, so I'll just it leave it at linking the current image-prompting–prompting prompt c-prompts-prompt.txt. (Not the prompt that generates images, but the prompt that generates image prompts.)

Having the LLM generate the prompts used by the other AI to generate the images still doesn't yet obviate the need for a lot of prompt tweaking and re-rolling from the human. But, the heuristics for all that will have to wait. (If not made obsolete prior to being written.)

4. Generate The Background Set

Similar to the sprite-generation step: Here we want backgrounds, and we need the image generator to create them, and we need prompts to feed to the image generator, and it ultimately ends up easier and better to have the LLM write the prompts based off of human-written vibes than to human-write the prompts themselves. See the corresponding LLM instructions in b-prompts-prompt.txt.

Backgrounds are a gigantic pain, and this step is a gigantic pain, and the reasons why it's all so painful are at least partially already explained in the Text and Image Contradictions blog post. But again: there's no time to get into the weeds of the dozens and dozens of iterations that can comprise a single background.

5. Visually Edit the Visual Novel

Of the five steps, this is the one that has changed least from the recent LLM intelligence improvements. Fundamentally, the human still needs to read/play through the visual novel and check that it looks good, from a human perspective, making visual edits as-needed. This step seems the least likely to ever be fully automatable via an AI, which means it will probably take only 20 months to automate instead of 10.

In any case, there's a lot of heuristics that go into this final visual edit, and none of them are written up yet, and they also kind of require first documenting all previous processes' heuristics, so except the full Part 5 blog post sometime next decade.

The End!

And that's it — converting any book into a visual novel is a simple as following the above five poorly explained steps.

For more details, consider inventing a device to freeze technological progress for long enough such that a coherent process could be documented in full.