DEV Community: Choice Story Studio

Building a visual novel's menu in layers, and placing every choice by hand - Devlog #5

Choice Story Studio — Sun, 07 Jun 2026 01:00:53 +0000

Hey again. Before a player makes a choice, watches a scene, or even starts a story, they see the menu. That's what this devlog's about.

For a long time the menus in ChoiceStory were something you filled in. There was a main menu, you set a title, picked a background, dropped in a few buttons, and that was about it. The work since then went into turning all of that into something you design instead. You grab a button and drag it where you want. You stack backgrounds. You put the choice buttons that show up over a video exactly where they should sit. What you see in the editor is what the player gets.

Three pieces came out of it.

The first is layered backgrounds for the main menu. Instead of one image or one colour behind your menu, you can stack up to five layers, images or a video, and move each one on its own. Think of it like layers in Photoshop: a still backdrop at the bottom, a slow video over it, a logo or a bit of foreground art on top, each one dragged and sized on its own. The bottom layer also sets the letterbox colour, the band that frames the menu, and that band is the contrast that keeps your title and buttons readable no matter how busy the art behind them gets.

i.imgur.com

Watch how the layers stack, and how each one drags and resizes on its own without dragging the others with it.

While we were in there we rebuilt the menu property panel into collapsible sections, because once you can do this much to a menu, a flat wall of controls stops being usable. We also pinned the editor to a fixed 16:9 stage. Sounds small, but it fixed a real problem: the surface used to stretch to fill whatever space it had, so resizing the window made your carefully placed elements drift. Now the stage holds its shape and what you place stays put.

The second piece is the pause menu, which now runs on the same system as the main menu. Layered backgrounds, drag-and-drop, the same panel, all of it. Both menus sit on one shared engine underneath, so a change to one shows up in the other instead of us building it twice. That shared base is also why the third piece almost came along for free.

The third piece is the choice screen editor, the buttons that come up over a video when the player has to decide something, Late Shift style. These used to be stuck to a layout we'd hardcoded. Now you design them by hand, and you can lay out each case on its own, whether a choice has two options or five. Drag the buttons where you want them, save, and every choice of that shape in your story follows the layout you set. The text scales to fit, so the same design holds up on a small laptop and a big monitor without you touching it.

i.imgur.com

Pick how many options the choice has, drag each button into place, then hit play to see it land over the live scene.

Now the honest part.

The layered background didn't go in cleanly. The first build of it shipped a crash. Drag the background colour control and the whole menu would flash white and freeze, with the app throwing a "maximum update depth exceeded." Turned out it was a single colour input box talking to itself: every value we wrote back into it kicked off another change, which wrote another value, in a loop that never settled. We reset back to the last solid version, kept the broken attempt on a side branch so we could pick it apart, and rebuilt the feature in small slices instead of one big drop, with the colour input rewritten so it can't re-enter itself like that.

That mess also pushed us into a call we'd been circling for a while. We dropped solid-colour menu backgrounds for good. They were behind half the trouble. A white background quietly turned the white menu text invisible, and the hidden "colour mode" was the thing stopping people from just uploading an image. Backgrounds are images and video now, with the letterbox doing the job the flat colour used to. Less to set up, and a lot harder to end up with a menu you can't read.

None of this is the flashy half of the tool. But the menu is the first thing anyone sees when they open a story, and the choice screen is the moment the whole "you decide" idea either lands or it doesn't, so it was worth getting the authoring right instead of leaving it baked in.

Same ask as always. We're building this in the open and heading into alpha because we want the people who'll actually make stories with it to tell us what's wrong with it. If a menu workflow feels backwards, or there's something you'd need that isn't here, come say so. On X, in the Discord, or by email. The harsh stuff especially.

More soon...

A real bug you can't see - and one that fixed itself (Devlog #4)

Choice Story Studio — Mon, 01 Jun 2026 21:40:45 +0000

Hey. No new feature this time - just a pass through the corners before the next one.

We had a list of nine bugs we'd written down and kept walking past. Most were small. One wasn't, and it was hiding behind a button.

When you import a file the studio already has - same bytes - we ask whether to share the existing file or make an independent copy you can edit on its own. Pick "independent copy" and you expect exactly that: your own file, safe to change or delete without touching anything else.

It mostly worked. But the new copy's internal name was built from how many copies already existed - copy 2, copy 3, and so on. The problem shows up after a delete. Say you had three, removed the middle one, then made another. The new one counted "two exist, so I'm number three" - but number three was already taken. The studio saw the clash, quietly kept the old file, and pointed your new scene at it. You thought you'd made a clean copy; you were sharing the original, and the real copy you just made was orphaned on disk with nothing
pointing at it. Edit "your" copy later and you'd be editing the original too.

Nothing crashed. Nothing warned you. That's the worst kind.

The fix: stop counting, and instead look at which names are actually taken and pick the first free one - so a copy made after a delete always gets its own identity. We also made the studio shout in the logs if two files ever collide again, instead of silently dropping one. Better a loud bug than a quiet one.

The rest were smaller. A menu element could jump for a single frame when you grabbed it (the drag started from where the element was saved, not where it was shown). A countdown number sat blank for one frame before popping in. And the end screen had a leftover timing delay we fixed - which you'll never see, because that screen is solid black either way. Real bug, just invisible.

The one we'd marked most important? We went to fix it and found a rebuild from two weeks ago had already solved it. We checked three ways before believing it. Crossing something off because it's genuinely gone feels almost as good as fixing it.

None of this is the glamorous part of building a tool. But it's most of what "does this actually work" comes down to, and we'd rather spend a week on the foundation than stack features on a floor with holes in it.

Next: back to the part that makes the stories. If you hit something that feels wrong - especially the quiet, hard-to-pin kind - tell us on X, in the Discord, or by email. More soon.

Comparison pages that say where the competition wins Devlog #3

Choice Story Studio — Sun, 31 May 2026 14:24:50 +0000

Hey. Different kind of update this time.

The last stretch of work wasn't on the editor, it was on the website, and I went back and forth on whether that belongs in a devlog at all. I decided it does, because the choices we made writing it say more about how we want to do this than another feature would.

We filled in the parts of the site that were still empty: a roadmap, a pricing page, an about page, and a set of pages comparing us to the tools people already use. The comparison pages are the ones worth talking about, because they were the most uncomfortable to write.

The Comparison Pages
The easy version of an "alternative to X" page is the dishonest one. You list your strengths, hide the other tool's, and quietly crown yourself. We did not want to do that, partly because it is gross and partly because the people we are building for can smell it from a mile off. So we wrote them the other way. We praise the tools we are measured against, quote their own words, and say plainly where they beat us.

On the Ren'Py page we say Ren'Py is free, open source, and runs on more platforms than we do, because it is and it does. On the Twine page we did not claim "no code" as our advantage, because Twine is no-code too for a simple story, by its own description. On the articy:draft page we point out that it has a free tier and that it is the deeper tool if you are a studio with a real engine behind you. Every comparison table on those pages has rows where the other tool wins, and we left every one of them in.

Best Narrative Design Tools Guide
The tempting move there is to put yourself at number one. We are pre-alpha. We have not earned the top of anyone's list. So the guide groups tools by what you are actually making, opens by telling you that we publish it and one of the tools is ours, and says outright that if you are writing a text adventure or shipping with a studio team, something else on the list will serve you better.

The Pricing Page
The pricing page was the other one that mattered, because we put the promise in writing. Free use is free forever, and you can share what you make anywhere at no cost. We will never charge hobbyists, people who are learning, or educational work made outside a company. If you sell your story one day, we ask for a small one-time Pro, never a subscription.

That is not a launch tactic. It is most of the reason this thing exists. A lot of us could never really justify the tools, and drowned in the technical side of them even when we could, so we would rather hand the free tier to everyone and only ask the people making money to chip in.

One thing I will own. While writing the pricing into those pages, we put an actual number on Pro, then pulled it back out the same day. The figure is not final, and putting a price we might change in front of you is exactly the kind of move we are trying not to make. So there are no numbers on the site yet, only what each tier is for.

Looking for Feedback
None of this is settled, the tool included. We ship early and write in the open because we want the people who actually use this to tell us what it should be, and that goes for the words on the site as much as the buttons in the editor. If something on there reads wrong to you, say so. The harsh stuff especially.

If you want to see the pages I'm talking about, they're all on the site: the comparison pages, the best-tools guide, and the pricing page. Find us on X as @ChoiceStoryDev, in our Discord, or by email.

Next we are back in the editor, on the part that actually makes the stories. More soon.

Pause menus, asset deduplication, end-screen nodes (Devlog #2)

Choice Story Studio — Sat, 23 May 2026 20:32:59 +0000

Hey again. I want to walk through where the canvas has gotten since then, because a lot of the work has been the unglamorous middle of a tool: the parts that don't really sell anything but that you discover you can't ship without. Pause menus. Asset cleanup. Editor performance. We added one big new node type in the last few days too, but most of the actual hours went into the boring half.

Here's roughly where things landed.

The first thing we built was a pause menu. Until now ChoiceStory Studio had one editable surface: the main menu (the launcher surface we walked through in Devlog #1, where the player sees Start / Load / Options / Quit over a configurable background). Adding pause was the first time we had to decide what a sub-surface actually is. We landed on this: the pause menu is not its own node, it's a second authoring face of the main menu, reached through a tab in the editor. Same right panel, same canvas tile, but at runtime it mounts as an overlay over the live scene when the player hits Escape. The design surface borrows the same drag and resize handles the main menu has, so the muscle memory carries over.

Then a feature we didn't plan but turned out to be necessary: asset deduplication. When you import the same video twice, ChoiceStory now fingerprints both files and offers to share the existing entry instead of writing a duplicate.A test project we'd been kicking around had 106 files on disk; after dedup and orphan cleanup it sat at 4 referenced files. The fix had to go deeper than the dedup dialog. Every reference in a project (backgrounds, button images,fonts, the lot) now resolves through a registry that is the single source of truth, so "delete unused files" actually knows what's used and what isn't.

Around the same time we added a performance settings modal in the File menu. Three toggles: follow active node on selection, recompute canvas viewport on resize, node glow animations. Two presets: high-spec PC and low-spec PC. The reason is that our target audience is creators on consumer-grade machines, not workstations, and some of the canvas animations were burning more cycles than the canvas itself. The toggle group is a stopgap; before the alpha we want a real Performance tab. The internal rule that came out of this work: any new feature that adds visible CPU or GPU load gets a toggle on the way in, never as a retrofit.

Next came a side-quest we called the parity pass. The main menu had affordances the pause menu didn't: per-element drag, per-element resize, draggable backgrounds with aspect-locked corner handles. So we pulled the drag and resize pipeline up out of main-menu/ (it never actually held any main-menu-specific knowledge in it) and pointed both surfaces at the same module. Future surfaces (choice overlays, options) inherit those affordances by reusing the same code, which was the whole point of the lift. We also closed a long-standing schema bug while we were in there. If you flipped a background between colour, image, and video schema keeps separate slots per variant and only the active one paints.

The newest addition is the end-screen node. It started life as another sub-surface (same shape as pause) and stayed that way for about ten minutes of planning before we changed our mind. End screens are different. A story can have several of them (good ending, bad ending, secret ending, joke ending) and each one needs its own configuration,so they had to be canvas-creatable nodes you can drop, configure, and connect to. Right-click on the canvas adds one.Right-click on the node copies it; right-click on empty canvas pastes a deep clone at the cursor. The config block for each instance is full: background, title, multi-line outro, music, font, a list of one to five buttons (per-button text, optional image, an appearance delay in milliseconds, and an action: return to main menu, restart, or quit). Optional auto-advance after a configurable delay. The buttons fade in one by one on a timeline the author writes. The runtime swap was the last piece. When a player choice routes to an end-screen node, the playback layer mounts the configured surface instead of trying to play it as a video.

Now the honest part :

A lot of the work above is what made it through. Plenty of stuff didn't. The pause-menu post-closure pass shipped eleven follow-up commits across a single session, and three of them got reverted by commit ten, because every fix had downstream consequences we hadn't mapped. Sub-state in React is the easy half; the hard half is the graph of "if I change this, what else re-renders, in what order, with which stale value." That session ended with a rule we have actually been following since: for every bug fix, write down the side-effect surface before writing the patch, and a list of files you deliberately did not touch. The follow-up count has dropped sharply since.

The CSS side gave us a similar lesson. We spent a first iteration on container queries to scale the pause menu inside variable Player-slot sizes. They worked, mostly, until they didn't on a small slot. We threw it out and used the recipe the main menu already used (viewport-relative clamps + flex with min-height: 0 + overflow: hidden) and it just behaved. The takeaway: if the older pattern already passes every test, the newer pattern needs a reason that survives ten minutes of "but does the existing one already do this?"

What's next is the choice overlay editor, the panel where the buttons that appear over a video (or an image) get designed. Same surface contract, same shared drag and resize infrastructure. We expect it to come together faster than end-screen because most of the substrate is in place now.

If you've read this far, thanks. If you've built something with branching video, or want to, the same line as last time stands. Come tell us what you'd want from a tool like this. Reply here, find us on X as @ChoiceStoryDev, email,whatever's easiest. The harsh stuff especially.

More soon...

Building a desktop studio for interactive video stories like Late Shift - Devlog #1

Choice Story Studio — Wed, 20 May 2026 14:41:03 +0000

Hey everyone.

I'm starting this devlog mostly because we've been heads-down on a project for about six weeks now and I've been wanting to talk about it with people who aren't just my teammates. So here we are.

We're a small team based in Antalya, working on a desktop app called ChoiceStory Studio. The short version: you drag your own videos and images onto a canvas, connect them with lines, and the app turns the whole thing into a branching, choice-driven story. When you're done you export it as a single installer file. No code, no game engine, no online accounts. It runs offline, end to end.

Here's what putting a tiny scene together actually looks like : one image, one video, a line between them, and the choice screen comes out of that automatically:

Right now we're focused on video because that's where the hard part lives. When the player makes a choice and the next clip starts, the cut has to feel invisible. No black frame, no audio gap, no "loading." If that's not smooth, the whole illusion falls apart and we might as well not exist. So we're spending a lot of our time on that one problem before pushing for breadth.

The canvas itself isn't going to stay video-only though. Visual novels, text-driven branching games, training simulations, kiosk experiences anything where "what happens next" depends on the audience we want to support all of it eventually, all from the same tool. But one thing at a time. We'd rather get the hard part right first than do five mediums badly.

Now the honest part, and the actual reason I'm writing this post:

We're heading into an early access release pretty soon. And I'm starting this devlog before launch on purpose,because I genuinely don't want to ship something, lock it in, and then call it done. I have my own ideas about what this tool should become, but they're just my ideas. If the people who actually try to use it tell us "we really need X," or "this thing you're spending weeks on doesn't matter to us," that's what should drive the next version. Not my taste, not my hunches. The people building stories with it.

So if any of this sounds even mildly interesting, and you have things you'd want from a tool like this a feature, a workflow, a use case I haven't thought of please come tell us. Reply here, find us on X as @ChoiceStoryDev, email, whatever's easiest. I read everything. Even the harsh stuff. Especially the harsh stuff.

I'll keep posting here as things move. What we built that week. What we threw away (already done that once burned seven iterations on a custom file protocol before scrapping it for a boring local HTTP server, that's a write-up for another day). Where we're stuck and could use outside eyes.

That's about it for the introduction. Thanks for being here this early. More soon.