u/Yohan_D_Dev

Hey r/textadventures,

I've been building Maximilien for the last 7 years, a psychological horror text adventure written in Twine/SugarCube, set in Boston, October 1926, during a string of unsolved murders. You play a psychology student who starts to suspect he might be involved in the killings he's investigating. 110,000 words, 12 possible endings, written in a register closer to Huysmans or Raymond Chandler than most visual novels.

The site just got a full redesign: maximilien-game.com - with a skin directly inspired from the game.

Maximilien is entering IFComp 2026, then releasing on Steam October 26th.

Happy to talk about the game if anyone's curious...it's been a genuinely strange thing to engineer.

I started writing Maximilien in 2019. It's a French psychological horror visual novel set in Boston in 1926, built in Twine/SugarCube, releasing on Steam on October 26 for Steam Scream Fest. Somewhere around year four I stopped counting how many times I'd thrown out an architectural decision and started counting what I'd actually learned. Here are four things I'd hand to myself at year one.

TL;DR, after seven years and 1755 narrative nodes:

- I tried to carry too much alone, for too long. The project only became viable once each domain had its own person.

- None of the productivity systems I tried fit how I actually work. I had to build my own, including the part where I walk away from blocked scenes.

- Document the system as rigorously as you write the code. Future you is a stranger who will not remember why `$exor = 1000` meant anything.

- In branching fiction, no decision is local. The structure is a web, not a chain.

Some context first:

Maximilien is a long-form narrative horror project, entering IFComp 2026 in August. The original is in French. The English version is being adapted by a literary translator with an advanced academic background - not a "translation" in the convert-this-string sense, more a full literary rewrite aimed at sustaining the prose register in another language.

The team is four people, all working remote: me on writing and development, Solynk on illustrations, Larant on music, Lucia on the English adaptation, and my brother handling everything marketing-related so I don't have to think about it.

I'm an autodidact. I came to this from writing, not from programming. That shaped almost every mistake I made - and most of what I'm about to describe would never have happened to someone with a CS background. If you're in a similar position (a writer or artist building something in Twine, Ren'Py, or a custom engine), I think the lessons below transfer. If you're a trained developer, you'll mostly read this and nod at the obvious bits. That's fine. It wasn't obvious to me at the start.

One note on the toolchain, since the question always comes up. I picked Twine in 2019 because SugarCube was the tool that matched what I needed for dense interactive prose. I'd still pick it today for that specific use case. This post isn't about defending that choice, though - it's about what I had to figure out *given* that choice.

1. I tried to carry too much alone, for too long.

For the first few years I tried to handle nearly everything myself: writing, structure, technical implementation, early visual direction, even the first attempts at musical mood. Some of that was budget. Most of it was the assumption that because I had a clear vision, I could execute every part of it well enough on my own.

That assumption was wrong. Every domain I touched outside writing slowed the project down and produced output I later had to redo. The shift came when I accepted that good specialists aren't just faster - they bring a grammar of their own domain that a generalist misses entirely. Solynk doesn't just illustrate; he reads the manuscript and answers it. Larant doesn't compose to a mood board; he composes to the emotional structure of the chapter. Lucia isn't translating sentences; she's rebuilding the literary register from inside the target language.

So the lesson isn't really "delegate." It's that the wrong collaborator is worse than no collaborator, and the right one transforms the work in ways you couldn't have anticipated. Hiring slowly, and choosing for alignment rather than just craft, was probably the single highest-leverage decision I made.

2. No methodology I read about fit how I actually work.

I tried a lot of them. Agile-flavoured sprints felt absurd applied to literary writing. Strict daily word counts produced text I had to throw out. GTD systems collapsed within a month every time. After enough failed transplants I stopped looking for the right method and started building one from how I actually function.

What I landed on has two unusual features.

The first is that I don't fight blocked passages anymore. If a scene resists for more than two or three sessions, I leave it and come back two or three weeks later. Nine times out of ten the obstacle that felt structural turns out to be temporary, and the scene unlocks in twenty minutes when I return with fresh eyes. The tenth time, the obstacle was real, and the gap of time gave me the distance to see what actually needed to change.

The second is that I treat intuition as a signal worth following even when I can't articulate why. On a project this long, the things you can argue for are usually the things you've already done. The real breakthroughs tend to come from a direction you can only name afterward.

Borrow shapes from others if they help. But don't try to inhabit a process designed for someone with a different temperament.

3. Document the system as rigorously as you write the code.

This is the one I'd put first if I were rewriting this post for someone just starting.

Twine doesn't give you much architectural support for long-form branching fiction, so I built my own file system by hand. A naming convention with arbitrary nesting depth: C for chapter, j for day, R for dream, numbers for the node concerned. Real passage names ended up looking like `c_1_r_2_2_1_1_1_1_1`. Each card in my external system tied its variables to their narrative context. That part saved me - up to a point.

What didn't save me was the variable naming I chose at the start. I used letters. `a = 0 to 4`, then `a1`, `a2`, and so on. Compact, abstract, and nearly unreadable six months later. I should have used `$search_perso` and `$biblio_univ` from day one. The readability cost would have been zero. The debugging cost of *not* doing it was enormous.

I made other beginner mistakes that are worth naming, because SugarCube fails quietly on most of them.

I put mixed types in the same variable. `$tele` (the telegram) sometimes held a number tied to `$day`, sometimes the string `"done"`. A comparison between an integer and a string can fail silently in SugarCube - no error thrown, just a wrong result. One variable, one type. Always.

I used arbitrary sentinel values to mean "impossible state." `$exor = 1000` meant exorcism impossible, on the assumption that the value would never collide with anything else. It did, the first time a path pushed `$exor` above 2 through legitimate gameplay. A separate `$exor_impossible` boolean would have prevented the entire class of bug.

If I were starting today I'd use Obsidian with the Dataview plugin to hold the architecture as a connected node system, and Tweego on the command line to work in separate files. Both would have saved me months. If you're starting a Twine project of any real size, look at those before you write your first passage.

The deeper version of the lesson, though.

More than 1700 narrative conditions accumulated over seven years. Ten testers worked the manuscript. Entire paths still went unwalked for years. I almost stopped at one point. What got me back to it was running AI-assisted debugging passes over the scripts, conditions, variables, and links - and discovering four major bugs that had been blocking specific narrative routes invisibly for years. Documentation alone wouldn't have caught them. But without documentation, no debugging pass, AI-assisted or otherwise, would have known where to look.

4. Architecture is a web, not a chain.

The trap in branching fiction is treating each node as a local decision. It isn't. A change at node 800 propagates to node 1200 by paths you didn't plan for, and the only protection against that is an architecture designed from the start to absorb modification. Solid and flexible at the same time, like the web of a spider, which holds load through distribution rather than rigidity.

In practice this means every passage I add now is checked against the ensemble before I commit it. Not "does this scene work in isolation," but "what does this scene change about the routes that pass through it, the variables it touches, the chapters downstream." That check takes time. Skipping it has cost me more time than performing it ever has.

So patience here isn't a virtue. It's a verification budget. Each stone laid into the architecture has to be considered in terms of its effect on the whole. The cost of placing it carefully is hours. The cost of placing it badly, and discovering the problem at node 1200, is weeks.

I'm finishing the final pass now ahead of the October 26 release and the IFComp 2026 entry due in August. Happy to answer questions in the comments - especially from anyone working on a long-form branching project in Twine or any similar tool. If you're earlier in the process than I was, and you want to ask the dumb questions I wish someone had answered for me at year one, please do.

Maximilien on Steam: https://store.steampowered.com/app/4755440/Maximilien__A_Psychological_Horror_Interactive_Novel/