How to write a visual novel with multiple endings: routes, flags and structure

A visual novel with multiple endings is built from two things: a structure, which decides where the story splits and joins, and a set of variables, which record what the player has chosen. Most of the writing problems in branching stories are structure problems, and they are much easier to solve before any scene is written.

This page explains the structures visual novels commonly use, how choices are tracked, how endings are decided, how true endings are locked, and how to keep a branching script small enough to finish. The code examples use Ren’Py, the most common engine for visual novels, and follow its documentation.

Key points

• Choose a structure first. The common route and character routes model is the visual novel standard.
• Two kinds of choice. Dialogue choices adjust values; action choices often decide the route.
• Flags and counters. Flags record events; counters such as affection points add up.
• Endings check variables. The game decides the ending from what has been recorded.
• True endings use persistent data. It survives between playthroughs.
• Branches multiply work. Every route needs its own writing, art and testing.

How visual novels usually branch

The common route and character routes

The structure most readers know starts with a common route, shared by every playthrough, in which the player meets the cast and makes choices. At a branch point, usually a third to a half of the way through, the game locks the player into one route. Each route then runs on its own to one or more endings.

In romance-led visual novels, routes are usually named after characters. In mysteries and thrillers, they may be named after outcomes or revelations.

This is close to what the game designer Sam Kabo Ashwell, in his widely cited Standard patterns in choice-based games, calls the Sorting Hat: early choices branch and rejoin until the player is assigned to one major branch, which is then fairly linear.

Other structures

Ashwell describes several other patterns, and visual novels use many of them.

The time cave is the one to be careful with. Because branches rarely rejoin, the amount of writing grows with every choice. It works for short pieces and becomes unmanageable at length.

Not every visual novel branches

Branching is common but not required. Wikipedia cites a study in which 18% of the visual novels examined had no branching narrative at all. Linear works are called kinetic novels; see kinetic novel vs visual novel.

How to turn a story into branches

A useful approach, suggested in a Writing Codidact discussion, is to start from a story you already have and work backwards.

1. Find the decisions the protagonist makes. Each one is a possible branch point.
2. Ask what happens if the other choice is made. The rejected path may become an alternate ending.
3. Keep only the branches that change something important. A branch that leads to the same place by a different road is a bottleneck, not a route.
4. Decide where each branch ends. Write the endings first, then the paths to them.

That last point matters most. A branching story that knows its endings can cut and merge paths freely. One that discovers its endings as it goes tends to grow until it cannot be finished.

Tracking choices: flags and counters

Choices are recorded in variables. Two kinds cover almost everything.

Flags record that something happened. Did the player keep the letter? Did they tell the truth? A flag is true or false.

Counters accumulate. The most common are affection points, one per character, which rise or fall with dialogue choices and decide which route the player ends up on.

Wikipedia notes that choices “may have no immediate effect” and instead feed a system of relationships that resolves late in a playthrough. This is why many dialogue choices in visual novels feel small: they are adjusting a counter.

In Ren’Py, a menu choice can set a variable with a line of Python, and a choice can be shown only if a condition is true. Following the documentation’s own example:

default drank_tea = False
default affection_mira = 0

menu:
    "Drink coffee.":
        "I drink the coffee."
    "Drink tea.":
        $ drank_tea = True
        $ affection_mira += 1
        "I drink the tea."
    "Fly above." if drank_tea:
        jump fly_ending

The third choice appears only if the player has already made the second, which is a simple way to make an earlier decision matter later.

Deciding the route and the ending

At the branch point, the game reads the counters and sends the player to a route. At the end of each route, it reads the flags and picks an ending.

default affection_jun = 0
default kept_letter = False

label branch_point:
    if affection_mira >= 5:
        jump mira_route
    elif affection_jun >= 5:
        jump jun_route
    else:
        jump solo_route

label mira_ending:
    if kept_letter:
        jump mira_good_end
    else:
        jump mira_bad_end

Three rules keep this under control.

1. Always have a fallback. The else line catches players who did not reach any threshold.
2. Decide ties in advance. If two counters can both pass the threshold, the order of the checks decides the route, and that should be deliberate.
3. Keep a variables sheet. List every flag and counter, where it changes and where it is checked. Without one, a branching script fills with variables nobody remembers.

Good, bad and true endings

Most routes have more than one ending. A common pattern is a good ending and a bad ending per route, decided by a few key choices.

Many visual novels also have a true ending: a final route or ending presented as the full resolution, locked until the player has finished others. It turns repeated playthroughs into part of the story, close to Ashwell’s loop and grow pattern.

True endings depend on information that survives between playthroughs. Ren’Py provides persistent data for this: “saved data that is not associated with a particular point in a game.” A field on persistent set at one ending can be checked anywhere, in any later playthrough.

label mira_good_end:
    $ persistent.mira_cleared = True
    "..."

label after_prologue:
    if persistent.mira_cleared and persistent.jun_cleared:
        jump true_route

The documentation notes that an undefined persistent field reads as None, so a check like if not persistent.mira_cleared works before the flag has ever been set. The same mechanism is used for galleries of scenes already seen.

How many endings?

There is no right number. Wikipedia gives the extremes: 428: Shibuya Scramble has 85 endings, while Steins;Gate 0 has six. Many visual novels have one or two endings per route.

What decides the number in practice is cost. Every ending needs writing, often its own art and music cues, and testing from every path that can reach it. For a first project, two or three distinct endings are plenty. For what each extra route adds to a budget, see how much it costs to make a visual novel.

Keeping a branching script finishable

1. Write a one-page map first. Every route, every ending, every branch point.
2. Merge where you can. Bottlenecks, scenes every route shares, cut the writing without cutting choice.
3. Make choices matter through variables, not new scenes. A changed line of dialogue costs far less than a new branch.
4. Count words across all routes. That total is what you are actually writing; see how long should a visual novel be.
5. Prototype in a mapping tool. Twine shows passages as a diagram, which makes structure problems visible early, even if the final game is built elsewhere.
6. Test every path. Bugs in branching games hide in the routes nobody tested.

For engines and tools, see Ren’Py vs Godot vs Unity vs RPG Maker vs Twine. For how dating sims differ in structure, see dating sim vs visual novel.

How this page was put together

The structural patterns are taken from Sam Kabo Ashwell’s essay on choice-based games. The code follows the Ren’Py documentation on menus and persistent data, read on 19 October 2026; the variable names in the examples are our own. Figures on branching and endings come from Wikipedia’s article on visual novels, and the working-backwards method from a Writing Codidact discussion.

This page is a guide to common practice, not an account of how a particular game was written. To report an error, see the corrections standard.