How Should You Name Novelez Chapters as Branches Grow?

A short visual novel can survive chapter names such as chapter1, route2, and end3. You remember what they mean because you created them yesterday. A month later, after adding two choices and a shared reunion scene, the same names turn every destination menu into a memory test.

Chapter names in Novelez are not headings that players read. They are internal destinations used by Choice, Condition, and Go to chapter blocks. That makes naming a production decision. A useful name should tell you where play will land and what that section does, without forcing you to open the chapter first.

The practical rule is simple: name a chapter by its role and its arrival scene, then keep that pattern stable. You do not need a perfect taxonomy. You need names that remain distinguishable when several routes appear in the same dropdown.

What does a Chapter block actually do?

A Chapter block marks a point that other blocks can target. It does not pause the story, create a separate file, or end the section on its own. If a chapter reaches its last block without an Ending or Go to chapter, play continues into the next chapter in the list.

That behavior explains why names matter. A Choice may point to the right chapter while the chapter itself quietly runs into the wrong section below it. The destination name helps you choose the entrance. The chapter-end line and Flow View help you confirm where play leaves.

Novelez starts at the top block in the list, so the official docs say you do not need a chapter literally named start. If an opening chapter helps you scan the project, keep one, but give it information that will still be useful later. opening_station says more than start, and opening_station_night says more when the story returns to the station in daylight.

Which parts belong in a useful name?

Start with two pieces: role and scene.

The role tells you what the chapter does in the route. Common roles include opening, route, rejoin, ending, and hub. The scene tells you what the player meets after arriving, such as station, library, or rooftop_confession.

A small project might use names like these:

• opening_station
• route_mina_platform
• route_jun_ticket_hall
• rejoin_last_train
• ending_mina_stays
• ending_jun_departs

These names are not prose. They are short labels that answer two questions: what kind of section is this, and what happens immediately after arrival?

Avoid encoding facts that are likely to change. chapter4 becomes misleading when a new chapter is inserted before it. choice2_left describes the editor layout rather than the story, and the second choice may become the third. new_route_final_v2 records a temporary working state that will soon be false.

Names based on story function are more stable. The station can move from chapter four to chapter five without making route_mina_platform incorrect. If the scene itself changes from a platform to a cafe, the name should change because the destination now means something different.

Keep the vocabulary small. Pick one word for a shared return point, such as rejoin, instead of alternating among merge, common, and back. Pick either character names or route names and use them consistently. Consistency makes similar destinations easier to compare in a menu.

Should every chapter name include a number?

Numbers help when they carry durable meaning. They create trouble when they only reflect the current list position.

A chapter number can be useful inside a stable act structure. act2_route_mina_platform tells you that the route sits inside the second act even if blocks move within that act. A bare name such as chapter_17 only tells you where the section used to sit.

For most small projects, semantic names are enough. Add a number only when the number belongs to the story plan, not because the editor happens to show that chapter seventeenth today.

Length matters too. A destination dropdown filled with long sentences is not easier to read. Put the most distinguishing information early and stop once the chapter is unique. route_mina_platform is usually better than route_for_mina_where_the_player_talks_on_the_platform_at_night.

Novelez recommends letters, numbers, and underscores. A restrained format also makes names easier to reuse in planning notes and bug reports. Lowercase words separated by underscores are a practical default.

What should you do with names that already exist?

Do not rename every chapter in one pass. The current Novelez docs say that renaming a chapter updates Choice, Condition, and Go to chapter blocks that point to it. That removes a large amount of manual work, but it does not prove the new name is clear or that every route still tells the right story.

Rename one structural group at a time. Begin with the chapters that are hardest to distinguish in destination menus. If the project contains route1, route2, and route3, map each one to its actual first scene before editing anything.

A compact rename pass looks like this:

1. Open Flow View and identify every incoming connection to the chapter.
2. Read the first few blocks after the Chapter block and decide what the arrival scene really is.
3. Rename the chapter with the chosen role and scene pattern.
4. Reopen one connected Choice, Condition, or Go to chapter block and confirm the new destination appears.
5. Check the chapter-end line before moving to the next name.

This order separates identity from structure. You are changing what the destination is called, not where the route goes. If you also reroute connections during the same pass, a later failure will not tell you whether the name change or the route edit caused it.

Use Undo immediately if the wrong chapter was edited. After an important naming pass, use Save even though ordinary edits are saved automatically. A deliberate save gives the cleanup a clear stopping point.

How do you name branches that meet again?

A reunion chapter deserves its own role in the name. Without that distinction, it can look like one character's route even though several branches enter it.

Imagine a station choice with two options. One path follows Mina to the platform. The other follows Jun into the ticket hall. Both paths later return to the last train announcement.

The route chapters might be route_mina_platform and route_jun_ticket_hall. The shared destination should not be route_mina_train, because that makes Jun's connection look suspicious even when it is correct. A name such as rejoin_last_train states that several branches are expected to arrive there.

Put a Go to chapter block at the end of each branch and point both to the reunion chapter. Then read the line shown at each chapter end. It should state the intended jump, not a continuation into the next branch.

The same rule helps with endings. Name the destination chapter for the narrative result, then keep the Ending block as the actual finish. ending_mina_stays is easier to verify than ending_good_1, because the word good may describe the author's judgment rather than what happens on screen.

When is a name too specific?

A name is too specific when ordinary editing makes it false. Weather, time of day, or a prop belongs in the name only if it distinguishes that destination from another one.

If there is one library chapter, route_jun_library is enough. If the story visits the library before and after a reveal, route_jun_library_before_reveal and route_jun_library_after_reveal prevent a real mistake. Add detail to separate competing destinations, not to summarize the whole scene.

Character names also need care. A shared chapter can contain Mina and still belong to every route. Use a character prefix only when the route ownership matters. Otherwise name the event or location that all incoming paths share.

When a chapter's purpose changes completely, rename it. When only dialogue wording changes, leave the name alone. Constant renaming is as confusing as vague naming because planning notes and test reports lose their reference point.

How should you verify the cleaned-up map?

A naming system succeeds only if it speeds up a real edit. Test it with the jobs that usually cause mistakes.

Open a Choice block and read its destinations without opening the target chapters. Can you tell where each option lands? Open a Condition and compare routes with similar outcomes. Can you distinguish the ordinary ending from the stronger result at a glance? Find a shared reunion in Flow View. Do the incoming lines converge on a name that sounds shared?

Then verify behavior:

• Every chapter name is unique.
• Every Choice, Condition, and Go to chapter destination exists.
• Each branch ends with an Ending or an intentional Go to chapter.
• No red warning remains at a chapter end.
• The first blocks after each destination make sense for every incoming route.
• Each renamed branch has been played through at least once.

Use Play from here for a focused check near a changed destination. For routes that depend on earlier variables, run from the real opening too. The official testing guidance notes that Play from here can apply Variable blocks above the selected block in list order, including blocks from other branches. A short preview can prove that a connection opens. It cannot always prove that the real route state is correct.

For a large cleanup, download the script as text before the first rename. Novelez provides recent undo, but the docs say there is no whole-project history that restores an older saved version. A local script copy is a modest safeguard before changing many internal references.

A naming rule you can keep

You can start with one line:

role_subject_scene

Use only the parts that distinguish the chapter. An opening may be opening_station. A character route may be route_mina_platform. A shared return may be rejoin_last_train. An ending may be ending_jun_departs.

The exact words matter less than the discipline. Use one vocabulary, describe the arrival rather than the current list position, and rename one structural group at a time. Then inspect the updated connections and play the path.

Good chapter names do not make a branch correct. They make an incorrect branch easier to spot before a player finds it. Which three chapter names in your current Novelez project would be hardest to distinguish if you saw them together in one destination menu?