Modeling Skippable Presentation Flow as a Race in Unity

When building UI presentations or cutscene-like flows in Unity, skip support sounds simple at first.

"If the player presses a button, skip the current presentation and move on."

In practice, though, it often turns into scattered control code:

• stop the running tween
• cancel the wait
• remove the input listener
• force objects into their final state
• somehow continue to the next step safely

The more complex the flow becomes, the harder it gets to keep skip handling clean.

In previous projects, skip handling often ended up as a mix of flags, conditional branches, and cleanup code scattered across the flow. That experience is what pushed me to look for a more structural approach.

I ended up approaching this problem from a different angle:

instead of treating skip as an external interruption, I modeled it as a race between user input and presentation flow.

That idea became what I call ChainRacePattern.

The problem with "just add skip"

Without skip support, a presentation flow is usually straightforward:

A -> B -> C -> Done

But once you add this requirement:

"At any point, the player can press a button and the flow should move on immediately."

the implementation gets much harder.

A common approach is to manage skip from the outside:

• track what is currently running
• stop those processes when skip happens
• manually move everything into its final state
• continue the rest of the flow

This works for small cases, but it tends to become fragile as the presentation grows.

Skip logic gets tied to the specific implementation details of each step.

That was the part I wanted to avoid.

Why I did not just use Coroutines

I have not used UniTask deeply enough to evaluate it fairly here, so I will not make claims about it.

As for Coroutines, sequential flow is still relatively manageable, but once the flow becomes more parallel in nature, it tends to become much harder to structure clearly. Even when it works, it often becomes difficult to modify later, and the intent of the code becomes harder to follow.

What felt difficult to me was not "waiting" itself, but expressing the following kind of behavior cleanly as part of the flow structure:

"If the user skips here, stop the remaining flow, move everything into the correct final state, and continue safely."

When I tried to implement that directly, it often turned into ad-hoc control code.

A different perspective: treat everything as a Chain

The core idea is to represent each presentation step as a Chain.

A Chain is something that:

• starts
• eventually completes
• can optionally be skipped

From there, you can compose flows declaratively:

• ChainSequence for sequential execution
• ChainParallel for parallel execution
• ChainRace for "whichever finishes first"

So instead of writing presentation flow as scattered control logic, I describe it as a composition of Chains.

The key shift: input can also be a Chain

This was the important realization.

An animation can be treated as something that starts, eventually completes, and can be skipped.

A button wait can also be treated the same way:

• it starts listening
• it completes when the button is pressed
• it can be skipped if needed

So user input is not something outside the flow.

It can be part of the flow itself.

For example:

new ChainButton(skipButton)

Once input is also represented as a Chain, skip can be expressed as a race.

Skip as a race

Here is the basic idea:

new ChainRace(
    new ChainButton(skipButton),
    new ChainSequence(
        CutsceneA,
        CutsceneB,
        CutsceneC
    )
)

Whichever finishes first wins.

• If the animation sequence finishes first, the button wait is skipped.
• If the button is pressed first, the animation sequence is skipped.

This changes the role of skip completely.

Skip is no longer a special case bolted onto the outside.

It becomes part of the flow structure itself.

That is the central idea of ChainRacePattern.

Why this helps

This approach helped me for a few reasons.

1. Skip logic stays local

Each Chain is responsible for its own skip behavior.

That means I do not need one large external "skip manager" that knows how every animation, sound effect, wait, and input listener should be interrupted.

2. The flow stays readable

Because everything is composed with Sequence, Parallel, and Race, the structure of the presentation remains visible in code.

You can often understand the entire flow just by reading the composition from top to bottom.

3. Skip support becomes structural

Whether a section is skippable or not is controlled by whether it is wrapped in a ChainRace.

That makes skip behavior a property of the composition itself, rather than an afterthought.

A practical example: result screen flow

Before getting into the result-screen example, here is a screenshot from another sample scene in the repository.
This demo shows different ways to structure skip behavior, such as skipping the whole flow, skipping per section, or making some sections unskippable.

A more practical example is a result screen flow like this:

1. fade in + show dialog
2. show bonus presentation
3. wait for user touch
4. hide dialog + restore the screen

That can be expressed as a composition like this:

return new ChainSequence(
    new ChainRace(
        new ChainSequence(
            new ChainDelay(0.1f),
            new ChainButton(screenButton)
        ),
        new ChainParallel(
            fadePanel.ChainFade(false),
            resultDialog.ChainShowDialog()
        )
    ),
    new ChainRace(
        new ChainButton(screenButton),
        resultDialog.ChainShowBonus()
    ),
    ChainTouchScreen(),
    new ChainParallel(
        resultDialog.ChainHideDialog(),
        fadePanel.ChainFade(true)
    )
);

What I like about this style is that the control flow stays explicit.

You can tell:

• which parts are skippable
• which parts run in parallel
• which parts must wait for input
• where the whole sequence continues

without needing separate skip control code scattered around the implementation.

One important detail: skipping means reaching the final state

In this pattern, skipping does not mean "just stop".

It means:

move this step immediately into its correct final state, then let the flow continue safely.

That distinction matters a lot.

For example, if a fade animation is skipped, the UI should not remain half-faded.

If a dialog slide-in is skipped, it should end up fully visible, not frozen midway.

That is why each Chain handles its own skip behavior.

In my implementation, SkipInternal() is expected to transition directly to the finished state.

Complete() is then handled by the outer lifecycle.

I also use isFastForward for cases where a Chain already knows it will be skipped immediately after starting.

That lets it avoid unnecessary work such as starting animations or acquiring temporary resources.

This is a pattern, not a finished library

At this stage, ChainRacePattern is a proposed design pattern, not a production-ready library.

The repository is intentionally minimal and acts as a reference implementation.

The goal is to demonstrate the idea clearly, not to provide a fully packaged framework for every Unity project.

Closing thoughts

What I like most about this approach is that it gave me a way to treat skip as part of the flow itself, instead of as an awkward interruption layered on top of it.

That made UI and presentation code much easier to reason about.

If you are interested, the repository is here:

• GitHub: ChainRacePatternUnity

I would also be genuinely interested to know how other teams handle this problem.

If your project has a different approach to skippable presentation flow in Unity, I would love to hear about it.