DEV Community: reelfork

Visual-novel scenes in an interactive drama: how one text game node carried a 4-ending story

reelfork — Sun, 16 Aug 2026 09:53:38 +0000

Some story beats fight against video: long conversations, inner monologues, the quiet standoff before a hard choice. Generating minutes of video for a dialogue-heavy act is expensive, and lip-synced delivery rarely beats well-paced text. Visual novels solved this decades ago — background art, character sprites, a dialogue box, one click per line.

ReelFork's text game node brings that form into the interactive drama story tree. It renders everything live in the player — no video file involved — and when the last line is read, the story continues through the node's exit like any other node. Video nodes and text game nodes mix freely in one tree, each doing what it does best.

The case: 7 nodes, 4 endings, one text game centerpiece

The published wuxia drama "Three Invitations at the Ferry" is built from just 7 nodes: a 10-second opening video of A-Ning waiting at a ferry dock, then a single text game node — 54 lines in which three old friends arrive one by one to make their case — then a four-way choice, three video endings, and a hidden fourth: a 28-line text game node with no exit at all, ending the story in pure text.

The division of labor is the lesson. Video carries what video is good at: the opening atmosphere and the ending payoffs. Text carries the emotional core — three characters each get a full entrance, voice, and argument, at a density no video budget would allow. The entire 54-line act compiles to about 60KB inside the drama's RFD file, less than one second of video.

Staging tricks worth stealing

Sound before sight. The scene opens with an off-screen voice line — hoofbeats written as text — before the rider's sprite enters on the next line. With audio channels not yet in play, sound is staged in the reader's head.

Center stage follows the speaker. 52 of the 54 lines carry sprite adjustments — whoever speaks takes the center position while the others step aside, and once all three suitors arrive, three sprites share the screen. Each line inherits the previous line's stage by default, so the author only overrides where the blocking changes.

Rhythm is a setting, not an accident. The scene runs a 34ms-per-character typewriter with 130ms punctuation pauses, and every line carries an end-of-line pause. It reads like a person speaking, not subtitles scrolling.

The lingering last frame. When the text game ends and the choice appears, the final frame stays as the backdrop — the choice buttons float over three tokens resting in front of A-Ning. The viewer decides inside the scene's atmosphere, not on a black screen.

A text-only ending

The fourth option, "choose no one", leads to a second text game node that simply has no exit. Twenty-eight lines of monologue at the dock, and the story ends where the text ends. When an ending's weight is inner voice rather than spectacle, a text ending lands harder than a video one — and costs almost nothing to make.

How to build one

In ReelFork Studio's story tree, add a node of type "Text Game", open the built-in editor, and write sections and lines — each line takes an optional speaker, its text, and per-line overrides for four channels: background, sprite layers, dialogue box, and music. Assets are referenced from the project canvas; an Agent button can generate backgrounds and sprites in place.

Publishing compiles the scene into the drama's RFD automatically as a textgame payload with an inlined asset table. The payload is a compiled artifact — hand-written payloads are rejected at upload validation — so all authoring happens in the editor. Cinema playback, embeds, and offline exports all render it natively.

Play the example: Three Invitations at the Ferry

Originally published on the ReelFork blog.

Embedding an interactive, branching video player with one iframe

reelfork — Mon, 03 Aug 2026 15:38:20 +0000

Originally published on the ReelFork blog.

Embedding a video player is a solved problem. Embedding an interactive one — where the viewer's choices branch the story, and where those choices need to survive fullscreen, resizing, and a paywall — is slightly less solved. Here's how the ReelFork embed works, including the two things that usually go wrong.

The snippet

One iframe. No JavaScript, no SDK, no server-side configuration on your end.

<iframe
  src="https://player.reelfork.com/d/<drama_id>"
  width="640"
  height="360"
  allow="autoplay; fullscreen"
  allowfullscreen>
</iframe>

You get the filled-in version from the drama page on ReelFork Cinema: Share → Embed. The drama ID and player URL come pre-populated.

Making it responsive

The fixed 640×360 works for a desktop column and breaks everywhere else. The reliable fix is the old padding-bottom trick, and it's still the right answer: it reserves the correct box before the iframe loads, so the page doesn't reflow when the player arrives.

.drama-embed {
  position: relative;
  padding-bottom: 56.25%; /* 9 / 16 */
  height: 0;
  overflow: hidden;
}

.drama-embed iframe {
  position: absolute;
  inset: 0;
  width: 100%;
  height: 100%;
  border: 0;
}

<div class="drama-embed">
  <iframe src="https://player.reelfork.com/d/<drama_id>" allowfullscreen></iframe>
</div>

If you only support modern browsers, aspect-ratio: 16 / 9 on the iframe does the same job in one line. The wrapper version is still worth keeping if you care about older Safari.

Thing that goes wrong #1: autoplay

Browsers block autoplay with sound. The usual workaround — mute the video — is exactly wrong for a story-driven format, where the dialogue is the content.

So the player doesn't autoplay. It renders a start screen and waits for a click. That click is a user gesture, which unblocks audio for the rest of the session. This is why allow="autoplay" in the snippet is about permitting later programmatic playback between branches, not about starting on load.

The practical consequence for you: don't try to force playback from the parent page. It will either be blocked or will start muted, and a muted interactive drama is a broken one.

Thing that goes wrong #2: assuming the iframe is sandboxed away from monetization

It isn't, and that's deliberate. Unlocks made inside an embedded player count toward creator earnings identically to unlocks on Cinema. Embedding moves where the drama is watched, not whether it's monetized.

The player is served from player.reelfork.com with permissive CORS headers, so it works from any origin without you configuring anything.

Starting at a specific episode

Append ?episode=<episode_id> to the src:

<iframe src="https://player.reelfork.com/d/<drama_id>?episode=<episode_id>" allowfullscreen></iframe>

Episode IDs are listed in the embed panel when you pick a specific episode from the dropdown. Useful when you're writing a post about one chapter and want readers to land there rather than at the series start.

Where this is actually useful

The honest case for embedding isn't "reach" — it's context. A newsletter archive, a portfolio, a documentation page, a community forum thread: places where the reader already has a reason to care, and where sending them to a new platform loses most of them at the click.

Full docs: Embed interactive dramas on any website.

RFD: a YAML format for branching video, so the story lives in Git

reelfork — Mon, 03 Aug 2026 15:34:32 +0000

Originally published on the ReelFork blog.

Most interactive-video tooling keeps the story structure locked inside a proprietary editor. If you want to know what your branching drama actually looks like, you open the app and squint at a canvas. You can't diff it. You can't review it. You certainly can't generate it from a script.

We went the other way. In ReelFork, the story is a YAML file — readable, diffable, and perfectly happy in Git. It's called RFD (ReelFork Drama), and this post walks through the whole format.

Why a text format at all

Three reasons, all of them boring and all of them the point:

Diffable. git diff on a story file shows you exactly which choice changed. Try that with a binary project file.
Generatable. An LLM can emit valid RFD directly. Our story agent does exactly this — it writes YAML, not clicks.
Portable. The canvas is one view of the file, not the source of truth. Author in the editor, in a text file, or from a script, and you end up in the same place.

The minimum viable file

A valid RFD file needs four things: a format version, a title, a cover, and a list of nodes.

rfd: "1.0"
title: "Night Shift"
cover: "cover.jpg"
nodes:
  - id: scene_01
    video: "clips/01.mp4"
    next: scene_02

That's already playable. It's a one-scene drama that ends after scene_02, which is not much of a drama — but it validates and it runs.

Nodes are scenes

Every node is one video clip plus instructions for what happens when it ends.

- id: scene_01          # unique within the file
  video: "clips/01.mp4" # path relative to the package root
  next: scene_02        # linear continuation

next is the linear case. Replace it with choices and the node becomes a fork.

Choices are edges

- id: scene_01
  video: "clips/01.mp4"
  choices:
    - ["Help the stranger", scene_help]
    - ["Keep walking", scene_ignore]

Each entry is [label, target_node_id]. The player freezes on the clip's last frame, renders the labels as buttons, and jumps to the target the viewer picks. Two options is the common case; three is fine; four starts to feel like a form rather than a story.

Conditions and effects: state across the whole drama

This is where it stops being a flowchart. effects writes to a variable when a branch is taken. if gates whether a node or a choice is available at all.

- id: scene_help
  video: "clips/help.mp4"
  effects:
    trust: +1
  next: act_two

- id: act_two
  video: "clips/act2.mp4"
  choices:
    - ["Ask him for the key", scene_key]
      if: trust >= 1
    - ["Break the door", scene_force]

Variables persist for the whole watch session, which is how a decision in episode one can open — or permanently close — a route in episode three.

The practical advice: keep the variable count small. Two or three named flags (trust, has_key, told_truth) cover almost every story you'd actually shoot. A dozen booleans produces a state space you cannot test.

Text game nodes: visual-novel scenes without video

RFD also supports a textgame node type for visual-novel style scenes: background art, character sprites, typewriter dialogue, music, and voice — all rendered live by the player, with no video file involved. A text game node declares type: textgame and carries a compiled textgame payload (schema: reelfork.textgame) plus a next field for its exit.

A published example shows the economics: in the wuxia drama "Three Invitations at the Ferry", the 54-line centerpiece — three characters arriving one by one, sprites trading center stage, backgrounds cutting between wide and close views — is a single text game node that compiles to about 60KB, less than one second of video. One branch even ends in a second text game node with no exit at all: a text-only ending. The choice buttons render over the scene's lingering final frame.

Unlike the rest of RFD, the payload is not meant to be hand-written. You author text game scenes in the ReelFork Studio story tree with the built-in Text Game editor; publishing compiles the scene into the RFD automatically. Hand-crafted payloads are rejected at upload validation.

What ships in a package

An RFD package is a plain zip: one YAML file plus every asset it references, with paths resolved relative to the package root.

Validation happens on upload

Uploading runs the file through a validator before anything is published. It checks:

the YAML parses and rfd is a supported version
every video path resolves to a file that's actually in the package
every next and every choice target points at a node that exists
the start node is reachable and at least one ending is reachable from it
no node is orphaned

Failures come back as a list with node IDs, not a generic "upload failed". The point is to catch a broken reference at upload time rather than when a viewer hits a dead end.

Why you might care even if you never use ReelFork

The interesting idea here isn't our specific keys. It's that branching video is a graph, and graphs belong in text. Once the story is a file:

code review works on narrative structure
CI can validate every path is reachable on every commit
a script can generate 40 localized variants from one source
an LLM can author the structure and a human can edit the diff

If you're building anything with branching media, steal the shape of this even if you don't use the format.

Full reference and the rest of the spec: The RFD format on the ReelFork blog. If you want to see a finished branching piece before reading a spec, there's a worked example here.

I Built a Clickable Video Ad in 30 Minutes — Here's the Exact Workflow

reelfork — Sun, 02 Aug 2026 07:49:55 +0000

Originally published on the ReelFork tutorials page.

Most video ads are a one-way street: the viewer watches (or skips), and that is the whole relationship. Interactive ads flip that. The viewer makes a choice inside the ad — which flavor, which storyline, which ending — and the ad branches accordingly. Engagement and completion rates go up because the viewer is doing something, not just watching something.

The catch used to be production cost: branching video meant custom players and custom code. This walkthrough shows the no-code version. I built a fully clickable beverage ad — one main storyline, two flavor branches — in about 30 minutes using ReelFork Studio. Here is the exact workflow, step by step.

What we're building

A vending-machine scene: the intro video plays, then freezes on two glowing bottles. The viewer taps "Fresh Lemon" or "Sweet Peach", and the ad continues into that flavor's branch.

Step 1: Open the canvas

From the home page, select Free Canvas to enter the canvas page.

Step 2: Create an interactive story tree

Double-click the canvas to open the node list, then click Interactive Story Tree. Double-click the tree to enter node editing. You can switch between Interactive Story Tree and Infinite Canvas from the top navigation at any time.

Step 3: Produce the video content

Ignore the node editor's buttons for now — go back to the canvas and produce your clips there. This example needs three: one intro (the main line) and two branch clips (lemon and peach).

Step 4: Bind the main video

Back in the story tree, open Final Video in the right-hand menu and click Bind Existing Content — you'll see every video on the canvas. Bind the intro to the Start node. A READY badge confirms it.

Step 5: Create the branch choice

Drag the + next to the Start tab and click Choice to create a choice interaction panel. Pick a style that matches your content — mine is comic-styled, so Comic Popup fits.

Step 6: Extract the last frame

In the workbench, click Canvas Video → Select, choose the intro, then Use Video → Extract Last Frame. That frozen frame is what viewers see while deciding.

Step 7: Bind the branches

Close the workbench, create two narrative nodes after the choice, and bind each branch video the same way as Step 4.

Step 8: Create hotspots

Open Hotspot in the workbench. Drag each hotspot region to overlap a bottle's button in the frame, then link each one to its narrative node in the Action section.

Step 9: Label the options

On the Choice node, rename the branch options to match the on-screen choices ("Fresh Lemon", "Sweet Peach").

Step 10: Preview and assemble

Click Preview to play through every path, then Assemble to produce the final interactive video.

Why this structure scales

The pipeline — canvas assets → story tree → bind videos → choice + hotspots → assemble — works for a lot more than one ad:

Multi-SKU product ads (one branch per variant)
Story-driven ads where viewers decide for the protagonist
Chapter selection in interactive short dramas

The full tutorial with all 20 screenshots lives here: Interactive Ads Quickstart. If you want the deep reference on the canvas, AI generation, and story trees, that's the ReelFork Studio Complete Guide.