I didn't know Twine existed, so I built my own branching story editor starting from an office experiment. Did I just waste my time?

Technical Development Development Systems
1

Hi everyone. I’ve been lurking here for a while and finally decided to share something I’ve been working on. I’m curious to hear what people who’ve been creating IF for much longer than me think about it.

How it started

It all started from a silly idea: last year at the office, a colleague got scammed by a phishing email. Everyone was talking about how they would never fall for something like that, and I wondered if that was actually true. I left mysterious web links on my coworkers’ desktops. Whoever clicked was greeted by a terminal screen, green text on black, typewriter effect, timed messages, choices with a countdown. A story about conspiracies and secret plots among colleagues inside the office. In the backend I tracked who opened what, when, and what choices they made. Basically a tracking system disguised as a game.

The problem was creating the content, because every branch, every timer, every transition was hardcoded and a nightmare to manage. So I built a visual editor: a node graph where each node is a story level and each connection is a choice. It reminded me of the gamebooks I used to read as a kid, and I tried to build tools that would let me create stories like those. From there things got a bit out of hand and I ended up with an entire platform. At some point a colleague used it to create an interactive story to propose to his partner, definitely a use case I hadn’t planned for.

The thing is, I had never heard of Twine, Ink, or ChoiceScript when I started. I only found out about them later, and by that point I had already built a lot of stuff. On one hand I probably reinvented the wheel on many things. On the other, not knowing anything about the IF ecosystem led me to make very different choices from what I would have made starting from an existing tool.

What came out of it

Since the starting point was “I want to control an experience for specific people” and not “I want to publish a story”, the tool took a direction of its own:

- Master/player model, the master creates individual players, assigns them specific stories, and controls their progress. Stories can be private, the player just receives a link and doesn’t know what’s coming. I’m not sure if anything similar exists in IF, I haven’t found anything, but maybe I’m missing something.

- Timed choices, each level can have a countdown for choices. When time runs out, the story can end (game over), pause (the master has to unlock it), or the player can retry. Time pressure was the core of the original experiment, so it was one of the first things I implemented.

- Session tracking, you can see where each player is, what they chose, how long they took. Born from the original tracking need, but it turned out to be useful for resuming the game from where it was left off too.

- Visual graph editor, web-based, nothing to install. You design the story as a flowchart with automatic layout. Probably nothing revolutionary for anyone who already knows visual tools, but for me coming from hardcoded content it was a game changer.

- JSON import/export, stories can be exported and imported as JSON. Your content is yours.

- Multiple themes, the Matrix-style terminal is still there (and yes, some people who open the link for the first time think it’s a virus and close it immediately, still working on that), but I’ve added other visual themes too.
Creating a new story in the editor

Over time I also added support for public stories, anyone can play without being created as a player and without registering (I use a cookie to save the player ID so they can resume where they left off), with a publication workflow with review. But the core remains the private master/player model.

The player experience

Multilingual and AI

The platform supports multiple languages, both the interface (Italian and English for now) and the story content itself. This means an author can write a story in Italian and make it available in English, German, Spanish and French without rewriting it from scratch. AI is integrated directly into the editor to handle translations: I select the target languages, and the system can translate all the content (narrative text, choices, responses) while preserving the tone and player placeholders. The result stays editable, so I can review and correct everything before publishing.

Beyond translations, there’s an optional AI assistant that helps draft narrative content. I describe what I want, even vaguely, and the assistant generates a preview with nodes and transitions that I can tweak, redo or discard. I’m mentioning this for transparency, I know AI is a sensitive topic. In my case I use it as a help for first drafts, for checking narrative inconsistencies, and above all for translations. The idea isn’t to replace the author’s writing, but to get the mechanical, repetitive work out of the way.

I’m Italian (and my English isn’t great), I translated the English interface with AI, let me know if something is off.

What it doesn’t do

No inventory, no variables, no state tracking, no free text input. It’s purely choice-based. For my original use case I didn’t need any of that, but I’ve realized that for creating “gamebook” style stories or “real” IF, these would be important. I have some ideas on how to implement them, but I’d rather hear what you think first.

One thing I’m working on: while trying to create stories, even short ones, I kept running into narrative coherence problems between levels and paths, like a node that takes something for granted that the player might not have discovered, because they went through a different path. I realized I needed a planning mode where I can write a brief summary for each level, mark what gets revealed and what’s assumed known, and organize levels by tier. The goal is to be able to verify coherence before writing the actual prose.

Story validation and review

The real question

Did I build something that makes sense for this community, or did I just reinvent the wheel in a worse way? I’m genuinely curious, if you saw this tool with no context, what would you think? What’s missing? What’s useless?

If you want to take a look:

- Playable demo stories: https://followblackrabbit.app/play

- Studio tools section for creating stories: Create Interactive Stories - The Black Rabbit Studio

- https://followblackrabbit.app

The demo stories you’ll find are still fairly simple, I built them more to test the mechanics than for narrative quality. If anyone wanted to try creating something of their own, you’d be doing me a huge favor.

If you register and hit any limits on the number of content you can create, just message me, I’ll unlock everything. I care about feedback more than anything else.

The documentation is still incomplete, there’s a guide inside the studio section (after registering) but it’s a work in progress.

Thanks to anyone who reads this far and wants to give me some suggestions.

2 Likes
2

I can’t say you’ve “wasted your time.” It sounds like you had fun making these, which is what really counts.

I think it would be an enormous effort to get this into a place where anyone non-you would use it to develop IF, especially since a lot of people have come to the forum with new IF development systems this year. https://intfiction.org/c/technical-development/development-systems/56

Developing a work of choice-based IF is often a novice programmer’s second program, literally right after “hello world.” It’s one of the recommended projects in JavaScript for Kids for Dummies. (Chapter 16: Choose Your Own Adventure)

So, the hard part isn’t getting something working, it’s getting someone non-you to use a new system.

Most people choose an IF platform by playing a great game and saying, “I really like this game, and I would like to make another game just like it. How did the author(s) make it?”

So, when IF platforms successfully take off, they require an admirable story (not just a technology demo) to attract new authors. Historically, the first “admirable” story for each now-successful IF platform was typically either written by the platform authors themselves, or directly funded by them. (Twine’s first admirable story by Anna Anthropy is the only exception I’m aware of.) Admirers don’t seem to directly care about any of the details of the system, except that if it’s too hard for them to learn the system and finish a game, that’s a major factor in achieving true popularity.

I think you’ll either need to write something great or hire a great writer (preferably paid in advance) to launch a new platform effectively.

10 Likes
3

A good question to ask yourself is what features does your system have that would cause people to choose it over existing well-established systems. A side-by-side comparison chart would be good for marketing, too.

4

@Ijinx IFWiki is pretty much the hub for all IF reference material.
→ https://www.ifwiki.org

If you are curious about other choice-based IF engines, check out this link.
→ https://www.ifwiki.org/Authoring_systems_for_choice-based_IF
There’s not too much to go through, but there are several clever authoring strategies to explore.

Personally, I’m not a fan of GUI authoring systems (too many clicks to achieve things, I find). However, if you want people to try your system on a whim, I suggest not requiring a login. Just keep a local storage session alive and let them muck around to provide feedback.

5

I’d just like to underscore this sentence in particular. Often people write IF because they enjoy the experience of writing IF. People design systems for the same reason.

12 Likes
6

Complimenti !!

not a wasted time, looks like a solid alternative to Twine, worth to continued development & improvement !

I don’t hide that I raised an eyebrow on the rather improbable, by US/UK workplace environment’s low standards, origin of your CYOA engine, until reading that you are a Compatriot, giving sense to the origins

(for non-Italians: there’s many workplaces, esp. in the public sector, where firing/laying off is basically impossible…)

anyway, I’ll test this engine ASAP, but I warmly recommend an offline editor/creator, as HAL9000 noted.

Best regards from Italy,
dott. Piergiorgio.

7

Building something rather than consuming is never a waste of time.

It looks very sexy!!

2 Likes
8

The timed text is the most annoying for me. There’s a little button at the top to bypass, but it rolls out the whole text and you have to scroll back and manually find your original place.

Perhaps, either have a timed text option, or when it pasted the remaining text, it doesn’t scroll to the end?

9

Thank you Dan for your feedback. You’re absolutely right that I had fun building it, building things in general is what I enjoy most, especially when others end up finding them useful too.

I’m not much of a writer. The demo stories I published are very basic and short, I built them more to test the mechanics than for narrative quality. Some friends found them entertaining, but that’s a pretty low bar.

That’s actually a big reason why I’m posting here. I’m hoping that someone who is a better and more experienced writer than me might want to try the tool and tell me what works, what doesn’t, and what’s missing.

10

That’s a good idea but I’d struggle to do it honestly since I still don’t know the other tools well enough to make a fair comparison.

What I can say is that from what I’ve seen, none of the existing IF editors seem to be built around a master/player model. They’re all designed for “author publishes, reader plays.”
As far as I can tell, no other tool lets you create private players, assign them specific stories via a personal link, track their sessions in real time, or control their progress manually.

That was the original core of my project, and it seems to be a genuinely different approach. If anyone here knows otherwise, I’d be curious to hear about it.

11

Thanks for the IFWiki link, I’ll check it out!

I’m curious about your workflow though. When you work without a GUI, how do you keep track of all the paths and branches? Before I built the graph editor I was losing track of the story flow completely, even with relatively short stories. What other tools or method do you use for visualizing the structure?

About the login requirement, I hear you. The system was originally built around tracking specific players and their progress through stories, so it relies heavily on a database for everything. Removing the login to allow local-only exploration would be a significant architectural change at this point. It’s something I can think about for the future, but right now it’s not a quick fix. I tried to keep the registration process as simple as possible though, just email and password.

1 Like
12

Since these systems are so easy to make, I think it’s unlikely that you’ll get a useful review of your system if you’re not prepared to invest in writing your own admirable story in it.

For someone to invest their own time in exploring your system and writing something in it (instead of in a more popular platform), you’d need to prove that it’s worth their time to do that.

I think the question you’re asking is, “Is this anything?” and the answer is “Right now, it’s only anything to you.”

If your goal is to contribute to the IF community at large (which need not be your goal!) I’d say you’d be better off starting by analyzing Twine and finding areas to contribute there. (It doesn’t make sense to ask someone to do that analysis for you, since it’s a process of teaching yourself what Twine does/doesn’t do.)

If, after thorough analysis (remembering “Chesterton’s fence”), you conclude that the best way to improve upon Twine would be to develop a new system from scratch, then you’d do it, and you’d know exactly why you were doing it, so you could say “This system is better than Twine because Twine doesn’t do X, Y, Z, and that’s why I created my thing.”

But maybe you’d just add session tracking and manual progress control to Twine, instead. (FWIW, I don’t think anyone’s clamoring for those features.)

If your goal is to have other people writing in an IF platform that feels like it belongs to you, that’s harder, but also straightforward: you’d develop a bunch of IF in your platform, and you’ll attract some followers that way. If you’re “not much of a writer,” maybe you’d pay a writer to develop it for you, or start writing anyway, get practice, and learn to become a better writer, which is rewarding in its own right.

3 Likes
13

My game Turandot is a mid-sized game in ChoiceScript. (It’s not, interestingly, a mid-sized ChoiceScript game, because that platform is often used for very large games!)

The story is pretty linear, and so the source consists of one file per scene. Easy to keep track of if you can remember the order of your scenes, which should be doable! But even if you write a branching story with a clear forward flow, the same non-system will usually work: branch 7, scene 2. Sure.

Visual story editors become far more useful in a game with lots of loops and backtracking.

14

Grazie!
I’m actually the IT guy at our office and it’s a pretty young team, so I can get away with these kinds of pranks without too much trouble. :sweat_smile:

I’m curious about the offline editor suggestion though. Could you tell me more about why that would be important to you? Right now stories can be exported and imported as JSON files, so your content is never locked into the platform. In theory someone could build an offline tool that works directly on the JSON, but I’m wondering what the actual need would be, is it about working without an internet connection, data ownership, or something else?

1 Like
15

I’m on the record as being opposed to visual GUIs for visualizing branching structure.

Have you ever used a visual tool to analyze code in other programming languages? They really don’t work well, in my experience. Often newbie programmers wish for some way to automatically visualize complex programs in a way that would make them comprehensible, but that’s just… not a thing that can exist, and not because nobody’s tried.

Visual aids can only really represent a few dozen things before they become as complicated as the thing you were trying to understand in the first place.

And when analyzing messy node diagrams, it’s not just the nodes we’re trying to visualize, but the lines connecting the nodes (the “edges”). We can only visualize a few dozen of those, and that typically means we can visualize only a handful of nodes at a time.

Visualization only works in trivial examples where you don’t need it; it fails in complex environments where you need it the most.

An example I’ve given in the past is a “visualization” of a maze. If you have a large maze on paper, you already have a visualization of that maze. It’s the maze itself. The maze is already visual. Being visual wasn’t the problem. The problem was the complexity!

Instead, like all code, if you want some tooling, you want some automated tests. Perhaps you’d want a test that proves that any given node is reachable. (That’s a provably undecidable problem when the system has state variables, but there are partial solutions, given constraints.)

You can also write your code in a way that narrows complexity. Instead of “any node can link to any node in the system,” you can give your nodes a scope/zone, e.g. scoping them to the current file of source code. You’ll presumably want some way of traveling from scope to scope (from zone to zone), but if you do that sparingly, there won’t be as much to visualize.

As Victor pointed out, most ChoiceScript authors write files in a linear series of chapters. (ChoiceScript has state variables, like a D&D character sheet, so choices in earlier chapters aren’t completely forgotten as you go from chapter to chapter.) Visualizing the chapters is trivial/pointless… chapter 1 links to the start of chapter 2, which links to the start of chapter 3. Within each chapter, you just need to make sure you’ve implemented all of the branches you intended to implement. (And you can use subroutines, subchapters, with nodes scoped to the subchapter.)

2 Likes
16

Thank you, that’s really useful feedback! You’re right, when you hit the skip button it should stay at your current scroll position instead of jumping to the end. That looks like an easy fix, I’ll work on it.

The typewriter effect was originally meant to give the impression that someone is typing on the other side, like when Neo sees messages appearing on his terminal in The Matrix. :smiling_face_with_sunglasses: That was the whole vibe of the original “experiment”…

That said, authors have full control over it in the story settings: they can adjust the speed, disable it entirely by setting it to 0, or even hide the skip button altogether. So if the effect doesn’t fit a particular story, it’s easy to turn it off.

17

There’s a long history of online-only IF platforms going down and taking their games with them, the most recent of which is StoryNexus (if you want to look them up). Having an exportable JSON file is a great start but game preservation would still be contingent on someone reverse-engineering an offline viewer. If you provide that from the start then there’s less risk that anyone’s hard work will vanish into the void.

6 Likes
18

You make fair points, and I appreciate the directness.

I’ll be honest, it wasn’t exactly easy for me personally. I’m not a programmer by trade, I’m the IT guy at a small studio, so I had to learn a lot of things from scratch along the way.

You’re absolutely right that from an IF author’s point of view, session tracking and manual progress control aren’t exciting features. But the tool was born with the master in mind, not the reader. Someone who creates an experience for specific people and wants to see how they go through it.

For example, I’ve been thinking about how the same system could work for a teacher creating a quiz or a branching assessment, where they could then see exactly where each student went wrong and what path they took. Or for someone designing an interactive experience for an event.

At the end of the day, a talented writer will create something great regardless of the tool. What my system tries to add is everything around the writing, managing who plays, when, and how they experience it.

You’re probably right that this community isn’t the primary audience for what I built.
I’m still glad I posted here though, the feedback is really useful and it’s helping me see things from a perspective I wouldn’t have on my own.

1 Like
19

That’s a really valid concern, I wasn’t aware of StoryNexus. Game preservation is something I should definitely think about more seriously.

Right now stories can be exported as JSON, which preserves all the content and structure. But you’re right that without a viewer it’s just raw data. :sweat_smile:

What if the export also generated one or more HTML files that you could open locally in any browser with no server needed, and customize with your own CSS? That’s actually what Twine does, exporting a single playable HTML file. In my case it would be much simpler and more limited since there are no variables or scripting, but it should be enough to preserve the story and keep it playable offline. Would that address the concern, or would you need something more?

21

I think it would go a long way, yeah!