Drawing a Branch Is Easy. Keeping It Alive Is Hard.

A Game Master prepares an important choice.

A rebel leader is about to be executed by the kingdom.

The players can rescue him.

They can stand aside.

They can also hand him over to the kingdom in exchange for access to the royal court.

The GM draws three arrows in the scenario.

In timeline A, the players rescue the rebel leader.

In timeline B, the rebel leader dies.

In timeline C, the players earn the kingdom’s trust.

At this point, the branches look finished.

Each one has a different scene.

Different dialogue.

A different outcome.

But the difficult part has only just begun.

If the rebel leader survives, the rebels still have a leader later.

If he dies, the organisation may split or produce a new successor.

If the players willingly hand him over, their relationships with the kingdom, the rebels, and neutral factions may all change.

These differences do not remain inside the scene where the choice was made.

They continue into later locations, battles, negotiations, item transfers, and faction relationships.

Drawing a branch only requires an arrow leaving the original line.

Keeping that branch alive requires every timeline to remember why it became what it is.

A Choice Changes More Than the Next Scene

Branching scenarios are often written as alternate scenes.

If the players rescue the leader, they play through an escape.

If they do nothing, they witness the execution.

If they betray him, the kingdom receives them at the palace.

Once those scenes end, the GM brings the players back to the main path that was already prepared.

This is convenient.

It also makes it easy for a choice to change only one piece of performance.

The players rescue the rebel leader, but he has no effect on the rebels later.

They watch him die, but his death leaves no gap in the organisation.

They side with the kingdom, but every other faction continues treating them exactly as before.

On the surface, the players experienced different stories.

In practice, the world only allowed their choice to change a few lines for a short time.

A real branch changes the conditions that come afterward.

Who is still alive?

Who owns what?

Who belongs to which faction?

Which locations remain open?

Who trusts the players?

Which missions are still possible?

Which futures have been permanently closed by this choice?

A branch is not defined by the next scene being different.

It begins when the world continues operating under different conditions from that scene onward.

Two Paths Reaching the Same Place Do Not Return to the Same World

A GM cannot prepare completely different maps, NPCs, and events for every branch forever.

Branches will often return to the same locations and major situations.

Whether the players rescue the rebel leader, watch him die, or side with the kingdom, all three paths may eventually reach the siege of the capital.

This can look like the branches have merged again.

But they have only reached the same place.

They have not returned to the same world.

In timeline A, the rebel leader may personally lead reinforcements outside the capital.

In timeline B, the rebels may be divided after losing their leader, and some may refuse to take part in the battle.

In timeline C, the players may be allowed into the royal palace while the rebels treat them as priority targets.

The battlefield can be the same.

The city walls can be the same.

The same map and some of the same enemies can appear in every timeline.

But character locations, faction structures, available resources, relationships, and reasons for fighting are no longer the same.

Sharing a scene does not mean sharing a world state.

Two timelines can reuse the same city.

They cannot use the same map as an excuse to wash away everything the players changed before arriving there.

A Branch Is a Complete World, Not a Few Alternate Paragraphs

Many creators preserve branches by copying a chapter.

One version shows the players rescuing the leader.

Another shows them standing aside.

A third shows them betraying him.

This preserves the different prose.

But prose is only part of a branch.

In the rescue timeline, the rebel leader is still alive.

The players may receive a token from him.

Pursuers may block a road that was previously safe.

The rebels may trust the players more because of what they did.

In the death timeline, the token may remain on the body, be taken by the kingdom, or fall into someone else’s hands.

Information and missions that only the leader could provide cannot continue appearing as if nothing changed.

In the kingdom timeline, the players may gain official standing with the crown.

Rebel safe houses that once welcomed them may refuse entry.

Some NPCs may still believe the players are allies until news of the betrayal reaches them.

If the creator only copies the branching scenes, all of these differences still have to be maintained somewhere else.

The character sheet may still show the canon version.

The item record may have only one latest owner.

The faction notes may not know which timeline they belong to.

A real timeline cannot preserve only different paragraphs.

Its characters, locations, items, factions, flags, and causal events must also remain separate.

Otherwise, the branches are only different versions of the scenario.

The world state underneath them is still mixed together.

An Unchosen Possibility Is Not a Timeline

Every choice in a TTRPG can have many possible answers.

The players can use the front door.

Use the back door.

Climb over the wall.

Bribe the guard.

Pretend they were invited.

They can also walk away completely.

This does not mean the GM needs to create a parallel universe for every possibility.

An answer that has not been chosen is only a possibility.

Once the players make a choice at the table, an ordinary campaign only needs to continue from what actually happened.

The other possibilities do not all need to be preserved as complete worlds.

Another version becomes a timeline only when the creator decides to continue developing it.

The GM may want to write a What If story.

The same campaign may be played by several different groups.

A module creator may need to test incompatible long-term routes.

An abandoned version may later become another official story.

The creator may simply want one choice to grow into several complete futures.

These are situations where each version needs its own history.

A timeline is not every option that failed to happen.

It is a future the creator has chosen to preserve and continue holding responsible for its consequences.

The Later a Branch Becomes Independent, the More It Costs

Some branches look small at first.

An NPC survives in timeline A and dies in timeline B.

The creator assumes that changing a few lines in the relevant scenes will be enough.

As the story continues, the differences begin to grow.

The living NPC joins a faction.

Gives an item to the players.

Carries information no one else can provide.

Later, he persuades another character during a negotiation.

None of these events happen in the death timeline.

The item remains somewhere else.

The information never reaches the players.

The negotiation also lacks the person who could have changed its outcome.

By the time the creator realises that the two versions can no longer be maintained with a few alternate lines, their differences may already be scattered across many chapters.

This is how branches often become unmanageable.

The number of routes did not suddenly become too large.

The creator simply waited too long to admit that these futures no longer shared the same world state.

A choice that changes character survival, item ownership, location states, faction structures, or other important conditions should split at the point where those differences begin.

The longer a branch waits to become independent, the more history the creator must untangle later.

Story Timelines Do Not Always Need to Merge

Code branches often need to be merged.

Different people may work on separate features, but those features usually need to return to the same product.

Stories do not always work that way.

In one timeline, the players rescue the rebel leader.

In another, he is dead.

Forcing those timelines together would require the world to treat the same person as both alive and dead.

The same item might appear in the hands of different owners.

The same faction might have two conflicting sets of leaders and relationships.

A story can certainly include a multiverse collision.

Two timelines can meet as part of the plot.

But that should be an event designed by the creator, with its own rules and consequences.

It should not happen simply because every branch is expected to return to canon.

If a What If timeline keeps growing into a complete story, it can continue on its own.

If an experimental branch becomes the creator’s favourite version, it does not need to be merged into the branch named main before it is allowed to become canon.

A branch name is only a way to organise versions.

The creator decides which future is worth continuing.

Git Preserves Universes. InkWeave Maintains Causality Inside Them.

InkWeave does not generate parallel worlds with a single branching button.

Instead, InkWeave and Git can work together so that every Git branch preserves a complete project.

A Git branch does not store only an alternate version of one chapter.

It stores the chapters, characters, items, locations, factions, and recorded causal data belonging to that timeline.

Timeline A can preserve the world where the rebel leader survived.

Timeline B can preserve the power vacuum created by his death.

Timeline C can preserve the players joining the kingdom and changing their faction relationships.

After switching Git branches, InkWeave opens the project stored in the current timeline.

Whether a character is alive.

Who owns an item.

Whether a location has been destroyed.

Which faction a character belongs to.

Which story flags have been set.

None of these states need to borrow answers from another branch.

Git preserves the universes that exist.

InkWeave maintains causality according to the events recorded inside the current universe.

Git does not understand the story.

InkWeave also cannot know facts the creator never defined or recorded.

But when each branch keeps the changes that actually happened, causality validation can evaluate later events against the history of the current timeline.

Creating and switching these timelines does not require GitHub, and InkWeave does not place plan limits on the number of Git branches. InkWeave must be completely closed before switching branches so that autosave cannot write one timeline’s content into another. The full process is explained in How to Write What If Branching Multiverse Stories with InkWeave.

Every Future Has to Answer to Its Own Past

The appeal of branching stories is the chance to see what kind of world can grow from a different choice.

The same person can become an ally in one timeline and a dead character in another.

The same item can be acquired by different people.

The same city can be saved, occupied, or destroyed.

The same faction can grow stronger, split apart, or stop existing because of what the players chose.

These differences only become real branches when they continue to matter later.

If a death leaves no absence, it does not matter which version a character is in.

If an item changing hands does not change what anyone can do, its history has little weight.

If betraying a faction does not change any relationship, the timelines have not truly separated.

A branch does not truly begin when an arrow leaves the main line.

It begins when every timeline starts remembering its own dead, its own items, its own relationships, and its own choices.

From that moment on, they are no longer alternate versions of the next scene.

They are worlds that must answer to their own pasts.