The short answer: trunk first, then a few routes, then spaced choices
Three routes of twenty-five thousand words each on top of a fifteen thousand word shared trunk need about ninety thousand words of finished writing. Each reader only sees around forty thousand words on a single playthrough, because one path means the shared opening plus one route. Place roughly one meaningful choice every five to ten thousand words so the story keeps asking the reader to act. Extra routes raise the production total much faster than most first-time writers predict, since every new branch adds its full length while the shared part stays the same size.
That paragraph is the whole planning method in miniature. Everything below explains how to use it on a real project: how the totals are built, what the density bands mean, where late splits quietly inflate the budget, and which failure shapes show up again and again in unfinished drafts.
What a branching map actually shows
A branching map is a parts list for a story that splits. It names the shared trunk every reader plays, the separate routes that branch off it, the choice points where the reader steers, and the word budget each part is allowed to consume. The map does not tell you what happens in any scene. It tells you how much writing each structural decision commits you to, before you fall in love with scenes you cannot afford to finish.
Most visual novels follow the same skeleton. Readers begin together in a common route that introduces the cast, the setting rules, and the central tension. At some split point the story divides into routes, often one per major character or one per ending. Choices sit along the way: some steer the reader toward a route, some change events inside a route, and some only flavor a single scene. The map above treats all three kinds as choice points for budgeting, because even a flavor choice needs scripting, testing, and revision time.
The tool output has five parts. The verdict states whether the shape looks producible. The metrics give the total budget, the per-playthrough length, the words per choice, and the trunk share. The node table lists every structural piece with its word cost. The timeline stacks the trunk and the routes so you can see the production order. The recommendations tell you what to fix first when a band or flag fires.
How the tool math works, step by step
The arithmetic is deliberately simple so you can check it by hand. Four inputs go in: the number of routes, the total choice points across the game, the new words each route needs, and the words in the shared trunk.
First the tool computes the production total. It multiplies the route count by the words per route, then adds the shared trunk once. With the default inputs that is three times twenty-five thousand, which is seventy-five thousand, plus fifteen thousand of shared opening, for ninety thousand words altogether. That total is the writing you must finish, revise, and script before the game is complete.
Next it computes the per-playthrough length. It adds the shared trunk to a single route. With defaults that is fifteen thousand plus twenty-five thousand, or forty thousand words per path. This is the number that matters to the reader, and it is usually much smaller than the production total. A game can feel like a satisfying forty-thousand-word read while costing ninety thousand words to build.
Then it computes choice density by dividing the production total by the number of choice points. Ninety thousand divided by six gives fifteen thousand words per choice. The tool compares that figure against a working convention: about one meaningful choice every five to ten thousand words. Denser than one per three thousand words reads as crowded; sparser than one per fifteen thousand reads as distant. These bands are planning conventions drawn from common practice, not measurements of any live game or store data.
Finally it computes the trunk share by dividing shared words by the total. Fifteen thousand divided by ninety thousand is roughly seventeen percent. When that share drops below about fifteen percent on a project with four or more routes, the tool raises a late-split flag, because nearly every scene is being written separately per route with only small variations.
A worked example with the default numbers
Walk through the defaults once slowly, since every later section refers back to them. You enter three routes, six choice points, twenty-five thousand words per route, and a fifteen thousand word trunk.
Production total: fifteen thousand plus three times twenty-five thousand equals ninety thousand. Per-playthrough length: fifteen thousand plus twenty-five thousand equals forty thousand. Words per choice: ninety thousand divided by six equals fifteen thousand, which sits exactly on the sparse boundary, so the default map passes with a note to watch the gaps. Trunk share: fifteen thousand out of ninety thousand is about seventeen percent, comfortably above the late-split flag for three routes.
Now change one input and watch the structure move. Raise the route count from three to five without touching anything else. The total becomes fifteen thousand plus five times twenty-five thousand, which is one hundred forty thousand. Per-playthrough length stays forty thousand, so the reader notices nothing, but your workload grows by more than half. Words per choice stretches to about twenty-three thousand, which trips the sparse band. This is the core lesson of branch planning: adding routes is invisible to the reader and enormous for the writer.
Change a different input instead. Keep three routes but raise choices from six to fourteen. The total stays ninety thousand, so the budget does not move, but density tightens to about six thousand words per choice, squarely inside the comfortable band. Choices are cheap in words and expensive in logic, which is why the tool treats density as a testing problem rather than a word-count problem.
Illustrative hypothetical example: a three-route romance
Consider an illustrative hypothetical project, invented to show the method rather than drawn from any published game. Suppose you are planning a romance visual novel with three love interests, one route each. You expect each romance to need about twenty thousand words past the split, and you plan a twelve thousand word common route where the protagonist arrives in a new town, meets all three characters, and learns the festival contest that frames the story.
Enter three routes, perhaps seven choices, twenty thousand per route, twelve thousand shared. The total is twelve thousand plus sixty thousand, or seventy-two thousand words. Each playthrough reads thirty-two thousand words. Density is seventy-two thousand divided by seven, or just over ten thousand words per choice, inside the comfortable band. The trunk share is twelve thousand of seventy-two thousand, about seventeen percent. The map passes cleanly, and the recommendations focus on protecting the trunk from route-specific edits.
Now suppose you fall in love with a fourth love interest during drafting and promote a side character to a full route. Nothing else changes. The total jumps to ninety-two thousand words, density stretches past thirteen thousand per choice, and suddenly two routes feel thin because the trunk was paced for three introductions, not four. The map makes the cost visible before you write a word of the new route: twenty thousand words plus a trunk rewrite plus rebalanced choices. Many writers would still add the route, and the map does not forbid it, but it prices the decision honestly.
Alternatively, suppose you keep three routes but let each one sprawl to thirty thousand words while the trunk stays twelve thousand. The total reaches one hundred two thousand, playthrough length grows to forty-two thousand, and density drifts sparse unless you add choices. The fix the tool suggests is cheaper than it looks: add one mid-route decision per romance, perhaps a misunderstanding scene where the reader picks how the protagonist apologizes, and density returns to the band without cutting any beloved scenes.
Illustrative hypothetical example: a mystery with a thin trunk
Take a second illustrative hypothetical case with the opposite disease. You are planning a mystery with four suspect routes. Eager to reach the intrigue, you write only a six thousand word shared opening, then split into four routes of twenty-two thousand words each, with eight choices total.
The total is six thousand plus eighty-eight thousand, or ninety-four thousand words. Each playthrough reads twenty-eight thousand. Density is ninety-four thousand divided by eight, under twelve thousand per choice, which looks acceptable. But the trunk share is six thousand of ninety-four thousand, barely over six percent, and the route count is four, so the late-split flag fires.
The flag is pointing at duplicated setup. With almost no shared opening, each of the four routes must separately introduce the detective, the victim, the town, and the rules of the investigation. You are writing the same orientation material four times with cosmetic differences, and every time you change a clue, you must change it in four places. The remedy is to move shared material into the trunk: establish the crime, the cast, and the investigative method once, in eight to twelve thousand more shared words, and let the routes diverge only when the reader starts accusing different suspects. Paradoxically, writing a longer opening means writing less overall, because four copies of setup collapse into one.
This pattern also explains why sequels and fan discs often feel efficient: the trunk already exists, so new routes genuinely cost only their own words. First projects pay the trunk tax once. Plan the trunk as an asset you will reuse, not as throat-clearing before the real story.
Reading the node table
The branch map table lists one row per structural piece. The first row is always the shared trunk with its full word cost. Then comes one row per route, each carrying the same per-route budget you entered. A choice summary row records how many decisions the game contains and roughly how many fall on each route. The last row totals the whole script.
Read the table from top to bottom as a build order. The trunk row is phase one: write it, revise it, and lock it before routes multiply. The route rows are phases two through however many routes you have, and they should be built one at a time rather than in parallel, so the pipeline improves with each pass. The choice row is a testing checklist: every listed decision needs a clean-save playtest on each route it touches.
When the table feels wrong, the feeling usually points at a real problem. If the trunk row looks embarrassingly short next to the route rows, the split is probably too early. If one route secretly needs far more words than the others, split the per-route budget into per-route rows in your own outline rather than averaging; the tool assumes equal routes, and an ensemble route plus a short epilogue route will break that assumption. If the choice row shows fewer than one decision per route, at least one branch is really a novella with an ending tacked on.
Reading the route timeline
The timeline renders the same numbers as a stacked bar measured in words. The trunk occupies the left segment, and each route extends the bar further right. The final segment turns a caution color when the total passes about one hundred twenty thousand words, marking the point where many solo writers and small teams start needing phased production.
Use the timeline to schedule honestly. The trunk segment is calendar time before any route exists. Each route segment is a drafting block of roughly equal size. If the bar is twice as long as your last finished project, that is information, not discouragement: it means the project needs either a longer calendar, a smaller map, or help. The most common planning failure in branching fiction is treating five route segments as five chapters of one book when they are closer to five overlapping novellas plus a shared opening.
The timeline also settles arguments about where to cut. Shortening every route by two thousand words on a five-route map saves ten thousand words of production, while cutting the same two thousand from the trunk saves only two thousand but shortens every playthrough. If readers complain about pacing, trim the trunk; if your calendar complains about scope, trim the routes.
Choice density: what the bands mean and why they exist
The density bands deserve a longer explanation because they are the most misunderstood part of the tool. Words per choice is not a quality score. It is a proxy for two different risks at the two ends.
At the dense end, below about three thousand words per choice, the risk is state explosion. Every choice that matters creates a flag, a variable, or a remembered attitude that later scenes must respect. Fourteen meaningful choices across a short game can mean dozens of flag combinations to test, and decorative choices that change nothing teach readers to stop caring. Dense maps are playable and sometimes brilliant, but they need disciplined flag hygiene: name every flag, list which scenes read it, and merge back-to-back decisions that could be one turning point.
At the sparse end, above about fifteen thousand words per choice, the risk is agency fade. Long stretches without decisions start reading like a kinetic novel with interruptions, and readers who picked up a branching game may feel the branches were promised but not delivered. Sparse maps are also playable and sometimes exactly right for heavy drama, but they should earn the gaps: each long stretch needs its own arc and cliffhanger so the wait between decisions feels like buildup rather than absence.
Between five and ten thousand words per choice, most commercial shapes cluster: enough room for scenes to breathe, frequent enough decisions that the reader stays awake. Treat the band as a default, not a law. Horror can sustain longer gaps because dread carries attention; comedy often wants tighter decisions because jokes need interaction. Note your genre exception in the outline so future you remembers why the map deviates.
A final subtlety: only meaningful choices count toward density in spirit, but the tool counts every choice you enter. If half your decisions are cosmetic dialogue variations, the true density is sparser than the number says. Either enter only the choices that change something, or mentally double the words-per-choice figure before judging it.
Edge cases the tool handles, and what they teach
Zero choices produces an informational verdict rather than a failure. The math still works: the total is trunk plus routes, and the table still lists the structure. The message is blunt on purpose. Without decisions, the project is a set of parallel stories, not a branching narrative, and at least one route is probably redundant. Add one decision per route or admit the linear shape and pick the strongest single path.
Very large totals, above roughly one hundred fifty thousand words, trigger a scope warning even when density looks fine. The reasoning is productional. At that size, global edits propagate across every route, proofreading needs version control rather than memory, and scripting plus direction scale with the total rather than with any single path. The recommendation is to freeze the trunk, finish one route completely, and only then green-light the rest. A finished trunk plus one polished route is also a credible demo if funding or collaborators enter later.
Equal-route averaging is a known simplification. Real projects often have a long true route and shorter alternates, or a hidden route unlocked after the others. The tool models every route at the same length, so interpret the total as an average case: if your true route runs half again as long as the others, add the difference to the total by hand. Better, budget the routes separately in your outline and enter the average here for the density check.
Tiny trunks with many routes trigger the late-split flag described earlier. The fix is structural, not numerical: delay the split. Find the latest scene that still works for every route and move the divergence there. Common candidates include the inciting incident, the arrival, the team formation, or the first investigation briefing. Everything before that line belongs in the trunk.
Single-huge-route maps, such as two routes where one is triple the other, confuse the density figure in the opposite direction. The average playthrough length understates the long path and overstates the short one. When routes differ by more than a factor of two, plan each route as its own row in your own spreadsheet and use this tool only for the density sanity check on the combined total.
Failure modes: how branching projects actually die
Unfinished branching drafts tend to fail in recognizable ways, and the map predicts most of them.
Route sprawl is the most common. A three-route plan becomes five routes through enthusiasm, the total doubles, and the writer stalls in route four with no energy left for revision. The defense is a route freeze date: after the trunk locks, no new route enters without an old route leaving or the calendar extending. The map gives the freeze decision a number by showing exactly what each added route costs.
Trunk churn kills from the other direction. The shared opening keeps changing while routes are being drafted, so every trunk edit invalidates scenes across all branches. Writers then either rework everything forever or abandon consistency. The defense is versioning discipline: once route drafting starts, trunk changes require a written reason and a rework estimate multiplied by the route count. Small trunk fixes are fine; trunk rewrites mid-production are a restart wearing a disguise.
Flag debt accumulates silently on dense maps. Choices set variables that nobody tracks, later scenes contradict earlier promises, and testing collapses because nobody knows which combinations are possible. The defense is a flag ledger started on day one: each choice gets one row naming the flag, its values, and every scene that reads it. Review the ledger whenever density runs dense.
Ending starvation happens when routes consume the whole budget and endings get whatever words remain. Readers forgive a slow middle far more readily than a rushed ending, since the ending is what the route was for. Budget endings first inside each route allocation: reserve the final tenth of every route for the climax and resolution before drafting the middle.
Choice theater is the quietest failure. The map shows healthy density, but the decisions change nothing, so readers feel busy rather than powerful. Audit each choice with a simple test: can you name one later scene that plays differently because of it? If not, the choice is decoration. Either connect it to a flag or cut it and let density fall where honesty puts it.
Designing the shared trunk well
A strong trunk does four jobs in as few words as possible. It introduces the cast the routes will develop, so routes can skip re-introductions. It establishes the setting rules, so routes can spend words on consequences instead of explanations. It poses the central question every route answers differently, giving the branches thematic unity. And it ends at a split point that feels earned, where the reader understands enough to choose with conviction.
Length guidance follows from those jobs rather than from any rulebook. A trunk that cannot introduce the cast needs more words; a trunk that introduces them twice needs fewer. Most workable trunks land between ten and twenty thousand words, which is long enough for a real opening act and short enough that the first meaningful choice arrives before patience thins. Shorter trunks suit premises where the reader already knows the world; longer trunks suit original settings with rules to teach.
Write the trunk as the best linear opening you can, not as scaffolding. Many readers will play only one route, which means the trunk plus that route is the entire game for them. A trunk that only makes sense after seeing all routes has the structure backwards. Each playthrough should feel complete, with later routes adding depth rather than repairing confusion.
Lock the trunk early and conspicuously. Announce the lock to collaborators, archive a copy, and route subsequent ideas into route-specific scenes wherever possible. Every writer who has survived a branching project has a story about the trunk edit that cost a week; the lock exists so the story stays funny in retrospect instead of recurring.
Designing routes that differ
Routes justify their word budgets by differing in something the reader can feel. The most reliable difference is viewpoint character or relationship focus: the same events matter differently to different people. Plot divergence works too, sending routes to different locations or mysteries, but it costs more words because shared scenes cannot be reused. Thematic divergence, where routes explore different answers to the trunk question, is the cheapest kind and often the most memorable.
Give each route its own arc with its own stakes, climax, and resolution. A route that borrows its climax from another route reads as a detour rather than a destination. Sketch each route as a three-act miniature before drafting: a personal inciting incident after the split, a midpoint reversal that could only happen on this path, and an ending that answers the trunk question in this route voice. If two route sketches share all three beats, merge them and spend the saved words deepening the survivor.
Endings deserve separate planning inside each route. Decide how many endings each route has and what distinguishes them before drafting the middle. A two-ending route where the endings differ only in the final scene is really a one-ending route with a choice at the end, which is fine, but budget it honestly. True alternate endings that reframe the route need thousands of words each, not hundreds.
Cross-route continuity needs a single owner. When routes reference each other, whether through shared side characters, consistent world events, or unlockable epilogues, one person or one document must arbitrate what is canonically true. Without that authority, routes drift apart and the setting stops feeling shared. The trunk document is the natural home for the canon list.
Testing a branching map without losing weeks
Testing scales with choices and routes, not with words, which is why density matters more than it appears. A sensible minimum is one clean-save playthrough per route that takes every default or first-listed option, plus one targeted replay per choice that selects the alternative and confirms the flagged scene changes. For the default map that means three full playthroughs plus six spot checks, a manageable plan. For a dense map with twenty choices across five routes, the same policy means five full playthroughs plus twenty checks, which is where schedules break.
Automate what the engine allows. Most visual novel engines can jump to labeled scenes, display current flag values, or fast-forward through seen text. Learn those features before the map grows, not after testing becomes painful. A jump list keyed to the node table turns the map into a test plan: each row gets a jump label, each choice gets a flag assertion.
Recruit testers per route, not per game. A tester who plays one route deeply and reports every contradiction will find more than a tester who skims three routes. Assign routes like beats, collect flag-specific feedback, and rotate testers onto new routes only after their first route passes clean. Keep one tester unspoiled for a blind full playthrough near the end, since route specialists lose the newcomer perspective.
Budgeting words against calendar time
Word budgets become schedules through drafting speed. A writer producing one thousand finished words per writing day needs ninety working days for a ninety-thousand-word total, before revision, scripting, and testing. Faster drafters adjust the divisor; the method stays the same. Divide the tool total by your sustained daily output to get drafting days, then add revision time at roughly half the drafting time for branched work, since every change echoes across routes.
This is where the per-playthrough number can mislead. Ninety thousand words of production at one thousand words a day is three working months, but the game reads like a forty-thousand-word book that a fast reader finishes in a weekend. Nobody owes you three months of reader gratitude for three months of writing; branching labor is structurally invisible. Price the project, or pitch it to collaborators, on the production total, never on the playthrough length.
Contingency belongs in the plan explicitly. Branching drafts overrun because choices breed extra scenes: a single flagged variation can sprout two or three follow-up variations that were never budgeted. Add fifteen to twenty percent to the tool total as branch contingency on a first project, less once your flag discipline is proven. If the contingency-inclusive total still fits the calendar, the map is genuinely safe.
Frequently encountered questions, answered in depth
Readers arrive with recurring worries about scope, structure, and choices. The spec above answers each one briefly; this section works through the reasoning so you can adapt the answers to unusual projects.
On how many routes to attempt: the honest variable is not talent but revision bandwidth. Two routes let you compare and contrast during editing; three add a middle voice without breaking the calendar; four and beyond demand either short routes, a thick trunk, or a team. First-time solo writers finish two-route games at far higher rates than five-route epics, not because their ideas are smaller but because their rework surface stays manageable.
On what belongs in the common route: anything more than one route needs. Introductions, setting rules, shared history, and the framing question all qualify. A useful test is the copy test: if you find yourself writing nearly the same scene in two routes, that scene wants to live in the trunk. Conversely, if a trunk scene only pays off in one route, it is really a route scene and should move past the split.
On choice frequency: count only decisions that change something, then check the band. If the honest count lands sparse, the repair is usually one added turning point per route rather than a shower of minor options. Readers remember the choice that changed a relationship or revealed a secret; they forget the choice of breakfast order unless the story makes it matter.
On late splits: the expense is duplication, and the symptom is parallel setup scenes that differ only in wallpaper. The cure is moving the split later, but there is a counter-case worth naming. Some stories split early on purpose because the routes are genuinely different worlds, such as portal premises or alternate timelines. That is legitimate, and the map will still flag it, because the flag means expensive, not wrong. Budget the expense consciously and proceed.
On budgeting per route: separate the reader number from the writer number and use each where it belongs. The reader number, trunk plus one route, sets expectations for playthrough length and pricing. The writer number, trunk plus all routes, sets the calendar and the budget. Confusing the two is how ninety-thousand-word projects get scheduled like forty-thousand-word ones.
On whether the tool numbers are promises: they are planning conventions, offered as illustrative assumptions for scoping your own draft. No tool knows your prose density, your engine overhead, or your revision habits. Use the map to compare shapes against each other, not to quote delivery dates to a publisher.
Where this work continues
When the map is stable and the trunk is locked, the remaining craft lives where visual novels are actually built. That destination is the Visual Novel studio on the book-to-film route at /vn, which carries branching outlines toward scripted, directed scenes. Keep this map open beside that studio work so every new choice and route can be checked against the budgets agreed here. The map sets the shape; the studio is where the shape becomes a playable story.
A practical workflow for the next draft
Start by entering your current best guesses, even if they are rough. Most writers overestimate trunk length and underestimate route length on the first pass; the tool will show you which. Read the verdict without defensiveness, then read the recommendations as a task list ordered by damage: density fixes first, then split position, then phasing.
Then take the map to your outline and reconcile them. Confirm that every route in the outline appears in the map and vice versa. Confirm that every planned choice is entered, or deliberately excluded as decoration. Confirm the trunk ends where the map says it ends. This reconciliation pass routinely surfaces phantom routes that exist in one document but not the other, and killing phantoms before drafting is the cheapest edit in the craft.
Draft the trunk to its budget and stop. Revise it, test it with readers who will never see the routes, and lock it. Only then start route one, and finish route one completely, including its endings, before opening route two. Each finished route calibrates your speed for the next, and the first finished route is the demo, the proof of concept, and the morale reserve for the long middle.
Revisit the map at the midpoint of every route. Enter actual word counts alongside the plan and let the totals move. Maps go stale the moment drafting starts; a stale map misleads worse than no map because it carries false authority. Ten minutes of re-entry per milestone keeps the document honest and keeps small overruns from compounding into project-ending ones.
Close the project route by route, testing each as it finishes rather than saving all testing for the end. A route that passes its playthroughs and spot checks is done, even while sibling routes are still drafts. Celebrate those completions properly. Branching projects are marathons run as a series of solo sprints, and the map is the scoreboard that proves each sprint counted.
Draft every route in Co-Writer
A map is a plan, not a manuscript. The drafting happens in Co-Writer at slash write, one route per pass: open a route, set its word budget from the map, and draft inside the structure instead of rediscovering it. The choice points stay fixed while the prose moves, so each route inherits the map's discipline and the trunk stays shared. When every route has a complete draft, the branching story exists as a book first — which is exactly what a visual novel adaptation needs as its source.