Goals for my gamebook<\/h2>\r\n\r\n\r\n\r\n
I was curious whether generating a gamebook with artificial intelligence could be fully automated. I\u2019m mainly interested in feasibility. Is it possible, and in what quality would such a generated book be? For my gamebook generation software I set the following requirements:<\/p>\r\n\r\n\r\n\r\n
- \r\n
- Everything should run completely automatically. I want to specify a setting and the main character. I want to define the number of chapters and the number of sections per chapter. Everything else should be generated automatically: the title, the content, the structure. I don\u2019t want to do any work there. A few inputs, one click, wait, and at the end the finished book should come out as a Word file.<\/li>\r\n\r\n\r\n\r\n
- Besides the text I obviously want nice illustrations. Those, too, should be generated automatically by AI. The cover should of course also be generated by an AI.<\/li>\r\n\r\n\r\n\r\n
- It should have the style of the books from the 80s. That means the illustrations should be kept in a simple black-and-white style. The cover should show the main characters in heroic poses\u2014a bit over the top, the way it often was 30 years ago. Think of the covers of the first rulebooks for The Dark Eye<\/em> editions.<\/li>\r\n\r\n\r\n\r\n
- My software should have a nice interface so I can watch the book being generated and always have full insight into the gamebook. A graph should visualize the structure, and dialogs should guide me comfortably through the generation process. No crusty command-line stuff or unit-test prototypes.<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n
So, a proper list and maximal requirements. Here\u2019s a screenshot of the final application.<\/p>\r\n\r\n\r\n\r\n
![\"Gamebook](\"https:\/\/www.lesestunden.de\/wp-content\/uploads\/2025\/08\/gamebook_screenshot1-scaled.png\")
<\/a><\/figure>\r\n\r\n\r\n\r\nIn individual screens you can edit all details. The following image shows the dialog for defining the story. You fill in the setting and main character manually; one click on \u201cGenerate story\u201d then creates the title and the content for the chapters.<\/p>\r\n\r\n\r\n\r\n
![\"Gamebook](\"https:\/\/www.lesestunden.de\/wp-content\/uploads\/2025\/08\/gamebook_screenshot3-scaled.png\")
<\/a><\/figure>\r\n\r\n\r\n\r\nTechnical foundation<\/h2>\r\n\r\n\r\n\r\n
Since OpenAI made ChatGPT widely accessible two and a half years ago, many billions of dollars\u2014and with that, developer hours\u2014have flowed into implementing and researching artificial intelligence. And you can really feel that when you dive into the topic. GPT is now at version 5, Google has caught up with Gemini, Facebook also offers its own model, there are several AIs for image generation, and the Chinese are in the game with DeepSeek, a not-so-bad budget variant. There are also numerous models you can run on a laptop at home, provided it has a bit of power. And it\u2019s very easy to use these models as cloud services. There are several platforms that provide a unified interface for accessing language models. For a software developer, that\u2019s extremely convenient.<\/p>\r\n\r\n\r\n\r\n
I primarily experimented with GPT 4.1. I quickly discarded the models that run locally on one\u2019s own machine. One variant of DeepSeek runs quite well and even offers reasoning (it \u201cthinks\u201d before it answers), but the results were far too poor. The performance of a language model heavily depends on the number of parameters used, and the more you have, the more memory and compute you need. If you pick models that are too large, you\u2019ll crash your own system\u2014something that happened to me quite often. It was also really slow, so I quickly moved to cloud services. OpenRouter<\/a> or CometAPI<\/a> offer unified access to various models, and I ended up using the latter. For an experienced software developer, the integration is pretty simple (it\u2019s a straightforward REST API).<\/p>\r\n\r\n\r\n\r\n
I implemented my software as an Angular application. For saving the book and for accessing CometAPI I used a very small PHP script that simply proxied requests, running in a Docker container. So everything stayed nice and lean.<\/p>\r\n\r\n\r\n\r\n
My decision to use Angular also had a very pragmatic reason: it\u2019s widespread. That means the language models know it very well. I also used AI extensively to develop my software. Large parts of the code were written by language models. If you rely blindly on AI, you\u2019re soon stranded\u2014you do have to step in yourself again and again, especially to keep the architecture lean and maintainable. But user interfaces with Angular and Material are very familiar to all language models and save a lot of implementation effort. I also tried all kinds of services and pretty much exhausted every free quota I could get: starting with GitHub Copilot, then of course the Gemini CLI, Cursor AI (which works well but is quite expensive), I tested Kilo Code (which sounds good at first because you only pay for the compute you use for the language model, but it gets super expensive because it adds up), copy\u2013paste into Microsoft Copilot and Google Gemini also works quite well, and I had lots of discussions with Copilot and Gemini about how to solve things and which models are suitable. I gave Copilot examples of my prompt and asked how to optimize it. Then I had Copilot generate a good sample prompt and had Gemini optimize it. I then built that into my application. Gemini implemented the D3.js graph visualization for me. The export to Word (docx) was done with GitHub Copilot, while the Gemini CLI then placed the cover inside it.<\/p>\r\n\r\n\r\n\r\n
Challenges<\/h2>\r\n\r\n\r\n\r\n
My first attempt was to leave everything to the AI. So I started with a request to come up with a story for a gamebook. That worked without any issues. I then sent that plot along with each request to generate a new section. I simply stuffed all previously generated sections into the prompt each time. I\u2019d call that the simplest \u201csledgehammer\u201d method of implementation\u2014which is also maximally expensive, since the entire book is sent in the prompt every time. My expectations were low, and of course it didn\u2019t work. A language model simply can\u2019t manage structures and certainly not a gamebook with several hundred options. The decision tree generated by the AI kept branching further and further without ever reaching an end.<\/p>\r\n\r\n\r\n\r\n
So I reversed the order and first created the structure for the gamebook. It\u2019s a directed graph without backward connections (I always hated it in gamebooks when you got stuck in a loop), with a few nodes that don\u2019t continue (sections where the player dies or the story ends prematurely and the reader \u201closes\u201d), that branches but still retains a certain linear structure. Here is an image of the result (corners marked in red have an illustration).<\/p>\r\n\r\n\r\n\r\n
![\"Gamebook](\"https:\/\/www.lesestunden.de\/wp-content\/uploads\/2025\/08\/gamebook_screenshot2-scaled.png\")
<\/a><\/figure>\r\n\r\n\r\n\r\nThis directed graph, whose vertices are the sections of the gamebook, is then filled with life piece by piece. Each vertex is visited once (when all its predecessors have been generated). A prompt is created for it, and the AI is to write that section. It should also produce the possible options, with the number dictated by the graph. It also gets the different backstories (histories) passed in, although I only go back two steps here and, for each path at the second level, pass in just a single predecessor.<\/p>\r\n\r\n\r\n\r\n
However, this approach has a problem: if there are many options and one option leads to a section that is also reachable from another branch, those two partial branches can differ so much that you can no longer merge them. Then the section makes sense for one branch but not for the other. Not even the best language model can solve that because, for example, a character might exist in one branch but not in the other. What are you supposed to do then? Even a human couldn\u2019t reconcile that anymore. So I changed the process to also go backward again. The section is created (as well as the AI can manage). Then the AI looks at all the preceding sections and optimizes them again so that the newly generated section makes sense. That solution only helped to a limited extent. Sometimes the branches were so different that the AI failed even with this approach.<\/p>\r\n\r\n\r\n\r\n
I then came up with a different graph structure: a fixed structure that is assembled repeatedly and optimized for a gamebook. When reading the book, you wouldn\u2019t perceive this fixed structure because the options are shuffled. It\u2019s also complex enough to provide sufficient freedom of choice, while being optimized to bring the story into a consistent form. Even then, though, I still had ill-fitting jumps in the story that shouldn\u2019t occur. Especially in the last chapter, the story also loses a lot of structure and no longer follows a straight plot.<\/p>\r\n\r\n\r\n\r\n
On top of that, the AI invents various supporting characters. These supporting characters are introduced, but the context only goes back two levels; otherwise the number of possibilities becomes too large. This leads to supporting characters changing. Mirja suddenly turns from a thief into a warrior and then disappears entirely. Fennik turns from a gnome into a dwarf, and later even loses his name and is just \u201cthe dwarf.\u201d You could probably solve this by having the AI generate supporting characters and keep them in a roster, passing them back into the prompt each time. Or by trying to include more of the different backstories.<\/p>\r\n\r\n\r\n\r\n
What I describe above I tried with GPT 4.1, and the results were actually quite good. Using an identical foundation, I tried the same with DeepSeek V3 (versions from March 2025 and August 2025). It didn\u2019t work there at all. Even simple connections from one section to the next didn\u2019t fit together. The language model lumped the chapter content and individual sections together and didn\u2019t differentiate. Sometimes the options were just complete nonsense. Gemini 2.5 Pro also performed surprisingly poorly, which really surprised me. I didn\u2019t try much more, as GPT 4.1 is considered one of the heavyweights in the language-model market. Claude would have been interesting as well, since it\u2019s said to be very good at writing, but it\u2019s also one of the more expensive models.<\/p>\r\n\r\n\r\n\r\n
Illustrations<\/h2>\r\n\r\n\r\n\r\n
Of course I wanted nice illustrations in the style of gamebooks. After all, the eye reads too. For that I installed Automatic1111<\/a> with Stable Diffusion locally. It\u2019s an AI for generating images. It also exposes an interface, which I then used for image generation. It took me some time to find the optimal prompt for exactly the style I wanted. Thanks to Copilot and Gemini I found it. I implemented it so that GPT 4.1 generates the prompt for Stable Diffusion\u2014that is, one AI generates the request for the other AI.<\/p>\r\n\r\n\r\n\r\n
There are numerous models for Stable Diffusion, and it took me a while to find a good one here. The Stable Diffusion 3.5 model<\/a> didn\u2019t run well on my machine anymore\u2014my compute power just wasn\u2019t enough. The images I generated online with it also didn\u2019t convince me. The popular Flux1.dev by Black Forest Labs<\/a> isn\u2019t compatible with Automatic1111 and didn\u2019t yield good results for this simple drawing style either (it\u2019s optimized for the opposite). In the end I used Juggernaut XL<\/a>, which has the classic weaknesses: hands aren\u2019t generated cleanly, there are odd artifacts, and the motifs are often skewed or completely off. But you can also get very nice illustrations if you try often enough. Here\u2019s an example of a successful illustration.<\/p>\r\n\r\n\r\n\r\n
![\"Gamebook](\"https:\/\/www.lesestunden.de\/wp-content\/uploads\/2025\/08\/gamebook_illustration-1.png\")
<\/a><\/figure>\r\n\r\n\r\n\r\nOverall, though, you have to say that AI illustrations almost never depict exactly the subject you want. It\u2019s like telling a stubborn but very talented child what motif you want drawn\u2014and you get something that\u2019s kind of right and kind of not. You can minimize this by making multiple attempts, but the images are seldom truly on point. Here I had to deviate strongly from my premise that everything should run automatically. You have to look at the images and check whether the AI didn\u2019t deliver complete garbage or something looks bizarre. I\u2019d say most of the time went in here: filtering out the unsuitable images, generating a new batch, then reviewing and culling again. In the end I was really satisfied with only a few illustrations.<\/p>\r\n\r\n\r\n\r\n
The most beautiful images are generated by OpenAI\u2019s DALL\u00b7E 3\u2014at least for my specific case, i.e., simple black-and-white drawings. But those cost 5 cents per image, which isn\u2019t exactly cheap. In addition, DALL\u00b7E 3 has trouble with portrait orientation and very often produces images with the wrong orientation or borders. You can compensate a bit with the prompt, but it still leads to unnecessary generations. And even with DALL\u00b7E 3 you often get images that don\u2019t really fit the scene. So I used Stable Diffusion exclusively and passed on DALL\u00b7E 3.<\/p>\r\n\r\n\r\n\r\n
AI-generated images generally have rather low resolution and aren\u2019t suitable for print. You have to upscale them first, which is also possible with AI. Automatic1111 already ships with several models for this that you can conveniently use via the interface. After generating the illustrations, I upscaled them again.<\/p>\r\n\r\n\r\n\r\n
Costs<\/h2>\r\n\r\n\r\n\r\n
Another topic is cost. If you get a flat-rate ChatGPT subscription or use the free Microsoft Copilot, it\u2019s actually quite inexpensive. But the costly training of the models and the compute to run them need to be paid for somehow. If you use the programming APIs, you\u2019ll be charged based on usage. And that\u2019s not exactly cheap. It adds up quickly\u2014after all, I feed a lot of prose into the AI for the gamebook and get long texts back. Billing is by tokens (usually about three characters per token).<\/p>\r\n\r\n\r\n\r\n
For a book with 180 sections, you end up with just under 800,000 tokens. Most are input tokens (a bit cheaper), about 10% are cached tokens (significantly cheaper), but even so, with GPT 4.1 it comes to about \u20ac2.50 per generated book. If you want to create images with DALL\u00b7E 3\u2014which I didn\u2019t do\u2014and include around 30 illustrations plus a cover, that\u2019s at least another \u20ac1.55.<\/p>\r\n\r\n\r\n\r\n
That said, 180 sections isn\u2019t that much. I\u2019d say they have more text than is typical in gamebooks, and my sample book comes to about 200 pages without illustrations (assuming 1,800 characters per page) plus 30 pages with illustrations, so 230 pages. About half a gamebook.<\/p>\r\n\r\n\r\n\r\n
When it comes to cost, you have to differentiate. From a reader\u2019s perspective it\u2019s probably a middling deal. You can get used gamebooks for just a few euros, lovingly written. From a publisher\u2019s or author\u2019s perspective, it\u2019s a bargain. Even if you have to revise the book more thoroughly, you save many, many hours of work this way, which significantly increases the margin.<\/p>\r\n\r\n\r\n\r\n
Generating a gamebook with 180 sections took 30 minutes\u2014the back-and-forth between my software and the AI. Creating the images takes considerably more time in total, since a single image with upscaling takes about 2.5 minutes on my machine. I had multiple images generated, deleted the unsuitable ones, generated more, until I had about 30 images. All told, the machine worked for several hours. Of course, runtime isn\u2019t a problem\u2014the program just chugs along in the background and doesn\u2019t load the computer too much.<\/p>\r\n\r\n\r\n\r\n
Possible extensions<\/h2>\r\n\r\n\r\n\r\n
There are numerous ways to optimize. What I implemented is only the beginning. You could introduce combat relatively easily since it\u2019s isolated within a section. The AI could decide on its own whether there\u2019s a fight and how strong an enemy is. That would be a simple extension.<\/p>\r\n\r\n\r\n\r\n
Items that can be found and later used could be implemented via a list. The AI can decide what exactly an item is and when it can be found and used. That should work quite well\u2014similar to supporting characters, which you could maintain as a roster and repeatedly pass into the prompt.<\/p>\r\n\r\n\r\n\r\n
Random decisions with dice would be just as easy to implement. The AI decides the options itself. Puzzles, however, are a different story. I think that\u2019s harder\u2014especially if the answer to the puzzle is the section number.<\/p>\r\n\r\n\r\n\r\n
From my perspective, all of these extensions are feasible without major problems. But then again, maybe not\u2014AI behavior is often unpredictable. At least these elements wouldn\u2019t be very complex to implement.<\/p>\r\n\r\n\r\n\r\n
Result and conclusion<\/h2>\r\n\r\n\r\n\r\n
What can be generated with artificial intelligence is truly impressive. Generating a gamebook already works quite well. But there are also some problems: jumps in the story; characters that aren\u2019t consistent or suddenly disappear; ill-fitting transitions when different branches converge; and by the end the story loses itself and only vaguely follows a plot. As in other areas, the AI simply makes mistakes. Writing a gamebook is a very hard task because of the many possibilities and branches. It\u2019s not a linear, normal book where an AI with a huge context window can just keep appending words according to its system. Merging several different branches in a sensible way, outputting them in a structured manner, and telling a consistent story across many plotlines requires a deep understanding of the content.<\/p>\r\n\r\n\r\n\r\n
Of course I could have invested many more hours in the project, refining prompts and algorithms. But that would have been too much work to go even deeper. I already experimented a lot, and each further attempt to improve the course of the story would have required significantly more development work. It\u2019s not a business model either, so it didn\u2019t make sense for me to dive deeper\u2014even if it\u2019s an interesting and tempting problem. It\u2019s fun to experiment and probe AI\u2019s limits, but there\u2019s still plenty of room for improvement that I haven\u2019t tapped.<\/p>\r\n\r\n\r\n\r\n
The quality of the text, however, is very good. The sections are excitingly written, fast-paced, and atmospheric. The characters are also nicely fleshed out. Yes, they aren\u2019t complex figures; it\u2019s not comparable to a sophisticated story or even the coherent, many-part world that Joe Dever<\/a> created. But it can definitely keep up with simpler gamebooks for children. It reads well and is entertaining.<\/p>\r\n\r\n\r\n\r\n
If you wanted to turn it into a complete book, you\u2019d definitely have to step in again: optimize the layout, fix branches that don\u2019t quite fit, revise and tighten the story, rework supporting characters, review the illustrations and possibly recreate them, and polish everything in detail. For my book project I also accepted illustrations that didn\u2019t fully match the scene\u2014leeway you couldn\u2019t allow yourself in a publication.<\/p>\r\n\r\n\r\n\r\n
Getting a finished book at the click of a mouse\u2014I still consider that unrealistic at the moment. Intensive manual post-processing is always necessary. But if you consider how much the workload for an author of such a gamebook is reduced, and how much content you already get, that\u2019s already a very big part of the way. It must also be said that this is a very simple gamebook; if you really want something ambitious, you won\u2019t get far with AI alone. You certainly won\u2019t get a fully automated Rider of the Black Sun<\/a>. But the generated book can be the foundation. The result matches my expectations and my experience from many other areas where AI is used: it makes authors faster and significantly simplifies the writing process. You get a template here, a well-developed framework that could probably be expanded into a complete gamebook with a fraction of the effort. The result is certainly not error-free, and the generated book is far from finished.<\/p>\r\n\r\n\r\n\r\n
What did I learn from this little project? The requirement that everything must happen fully automatically is too strict. AI can\u2019t (yet) do that. A far more sensible solution is not a generator that does everything automatically, but a tool that supports the gamebook author with AI functionality. That could look like this: the author has the graph view and, based on that, has an AI generate a new section for an option. You get the text and options, and there\u2019s an input field to have the AI further refine the section with your own prompt. Or you take over parts of the writing yourself to rein in the story\u2014and with it the AI. You review the generated options and adjust them if necessary. In this way, the AI writes the story, but not fully automatically\u2014rather, under the author\u2019s supervision and with immediate review. If you can also influence the options section by section, you can define the graph and its branches yourself. This way you can flesh out a much more complex story while always keeping an overview of the gamebook\u2014and still get most of the work done for you. In addition, I would maintain tables for items and characters that are automatically extended when the AI or the author introduces a new character or item. You can\u2019t avoid manual effort, so you need to keep it as low as possible while fully leveraging AI\u2019s power.<\/p>\r\n\r\n\r\n\r\n
The book for download<\/h2>\r\n\r\n\r\n\r\n
I generated a classic fantasy story as a gamebook\u2014just like the solo adventures from the 80s and 90s for The Dark Eye<\/em>. A simple plot: the protagonist is young and inexperienced, gets swept up in a maelstrom of events, and has to save the world. The classic hero\u2019s journey, with elves, orcs, fairies, and a well-worn fantasy setting. For me it was obvious to try it with such a setting\u2014it\u2019s very common and classic.<\/p>\r\n\r\n\r\n\r\n
I didn\u2019t further process the gamebook. The cover, the illustrations, the text\u2014nothing was adjusted. The content is exactly as generated by AI. I deliberately didn\u2019t change anything so everyone can form their own opinion. I only converted the docx file to a PDF; otherwise the file would have been too large.<\/p>\r\n\r\n\r\n\r\n
Das_Herz_der_Silberelfe<\/a>Download<\/a><\/div>\r\n\r\n\r\n\r\nHave you, as an author, already worked with artificial intelligence? What are your experiences? Is it devil\u2019s work to you or already an everyday tool? Books and stories by AI\u2014would you want to read something like that? Share your thoughts and experiences; I\u2019m very interested.<\/strong><\/p>\r\n\r\n","protected":false},"excerpt":{"rendered":"
Years ago, I toyed with the idea of writing a gamebook. I loved and devoured those books in my youth. These days I rarely reach for that kind of book. Still, I find it fascinating what\u2019s possible with the medium of the book. Back then, I considered writing my own software that would let me … <\/p>\n
- My software should have a nice interface so I can watch the book being generated and always have full insight into the gamebook. A graph should visualize the structure, and dialogs should guide me comfortably through the generation process. No crusty command-line stuff or unit-test prototypes.<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n