Sequence manager system #

User guide for Hyper's centralized Level Sequence playback workflow

This document explains how the Sequence Manager is structured, how it should be used in gameplay, and how to set up common cutscene, tutorial, and interaction flows.

Demo quick guide board showing the intended usage pattern for AC_SequenceManager.

---

Introduction #

The Sequence Manager is a centralized Blueprint component used to play and control Level Sequences on a per-player basis. Instead of placing sequence logic directly inside world actors, triggers, or one-off Blueprints, the system moves playback into a single manager attached to the Player Controller.

In practice, this gives the project one consistent entry point for cutscenes, tutorials, scripted interactions, and other sequence-driven moments. Each player owns exactly one sequence manager and only one active sequence is expected at a time.

The demo guidance provided with the system highlights the intended design very clearly:

• attach the component to the Player Controller
• call Client Create Sequence with a small sequence data struct
• allow the manager to load the asset, create the player, bind events, and start playback
• call Client Stop Current Sequence when the active sequence should end early

This is a clean design for larger projects because world actors do not need to know how to create or manage sequence players themselves. They only need to request that a sequence be played.

Demo prompt showing a skippable presentation variant.

---

Adding the Sequence Manager to the Player Controller #

AC_SequenceManager should be added to the Player Controller. This makes it a player-owned service for sequence playback, event forwarding, skip handling, and cleanup.

---

Why place it on the Player Controller? #

The Player Controller is the most natural owner for local sequence playback because the active sequence is player-specific rather than world-global. It also keeps sequence state in one predictable place and avoids duplicating similar logic across interactables, quest actors, or trigger volumes.

This setup also aligns with the intended multiplayer-safe design shown in the demo notes. The quick guide explains that the sequence request can originate on the server or client, while the component still resolves playback on the owning client.

AC_SequenceManager overview showing the public event graph, runtime variables, and helper functions.

---

Structures Explained #

---

F_SequenceManager #

The system is driven by a small data structure called F_SequenceManager. This is the payload passed into Client Create Sequence and it tells the manager what to play and how to play it.

This keeps the public API very simple. Callers only need to provide the sequence asset, the playback settings, and whether the sequence should be skippable.

F_SequenceManager contains the sequence asset reference, playback settings, and skippable toggle.

---

Details Panel / Important Variables #

The screenshots provided show a small set of runtime references rather than a large configuration surface. The component only stores the objects it actively needs while a sequence is running.

This is a sensible runtime model: create what is needed for the active sequence, forward the relevant events, then clear every reference when playback ends.

---

Functions to Use #

---

Client Create Sequence #

Client Create Sequence is the main entry point. It receives F_SequenceManager, loads the requested asset, creates the Level Sequence Player using the supplied settings, stores the resulting actor and player references, binds playback events, and optionally sets up skip support.

A useful implementation detail shown in the graph is the autoplay safeguard. The note in the Blueprint explains that when autoplay is enabled, the expected play path does not naturally fire in the same way, so the manager manually calls its On Play event. This keeps the event flow consistent regardless of whether autoplay is used.

Client Create Sequence loads the asset, creates the player, stores runtime references, binds events, and handles autoplay safely.

---

Client Stop Current Sequence #

Client Stop Current Sequence is intentionally small. It validates the current sequence player reference and then calls Stop on it. This makes stopping easy from other systems while allowing the manager's own stop and finished callbacks to own the cleanup path.

Client Stop Current Sequence validates the active player and requests a stop.

---

Clear Current Sequence References #

Clear Current Sequence References is the cleanup function that returns the manager to a neutral state. It unbinds the sequence events, clears the current actor and player references, removes the skip widget if one exists, and clears the widget reference.

Clear Current Sequence References unbinds events and clears actor, player, and widget references.

---

Is Playing Sequence #

Is Playing Sequence is a simple utility that returns whether the current Level Sequence Player reference is valid. This gives gameplay and UI systems a fast way to ask whether the manager is currently busy.

Is Playing Sequence reports whether a valid active player is present.

---

Event Binding and Callback Flow #

Once the sequence player has been created, the manager binds to all of the playback events it needs to care about. Based on the provided graphs, these bindings cover play, reverse play, pause, camera cut, stop, and finished.

Each of these callbacks is then forwarded through manager-level events or functions. That is one of the strongest parts of the system: other gameplay code can listen to the manager's clean callback layer rather than binding directly to newly created sequence players every time.

The manager binds the active sequence player to play, reverse, pause, and camera cut callbacks.

Stop and finished both flow through manager callbacks and then clear the active sequence references.

---

Skippable Sequences #

The manager includes a dedicated skippable path controlled by the Skippable boolean in F_SequenceManager. When the value is true, the component creates WBP_SequenceWidget, adds it to the viewport, gives it focus, stores the widget reference, and binds its Try Skip event.

When the skip event is fired, the manager sends the active sequence to its end and then stops it. This is a strong implementation choice because it keeps the cutscene's end-state behavior deterministic rather than abruptly abandoning the sequence mid-flow.

The demo board also highlights a presentation variant where the skip prompt fades in and out. That is presentation-layer behavior rather than core playback logic, but it shows how the manager can support more polished UX on top of the same skip event.

Skippable logic creates the widget, focuses it, binds the skip event, and sends the active sequence to the end before stopping.

---

Stopping and Cleanup #

Stopping a sequence and cleaning it up are related but intentionally separate concerns. The public stop request only needs to ask the active player to stop. The manager then relies on the stop or finished callbacks to clear event bindings and runtime references in one predictable place.

This prevents duplicated cleanup logic and reduces the chance of partial state being left behind after a sequence ends. It also means a sequence that reaches its natural end and a sequence that is stopped early follow a very similar cleanup path.

• Client Stop Current Sequence asks the current player to stop.
• On Stop or On Finished fires through the manager callbacks.
• Clear Current Sequence References unbinds events and removes the skip widget.
• The manager becomes ready to play a new sequence.

---

Why This System Is Useful #

The Sequence Manager solves a very common problem in Blueprint-heavy projects: sequence logic becomes fragmented when every actor handles its own cutscene flow. By centralizing playback into one manager component, the project gets a single API, a consistent callback model, and one cleanup path.

• no sequence setup needs to live inside every world actor
• the project uses one consistent playback flow for tutorials, interactions, and quests
• skip support can be standardized instead of rebuilt repeatedly
• runtime references are cleaned up in one place
• other systems can ask whether a sequence is active before trying to start another one

---

How to Use the System #

---

How to play a sequence #

1. Get the Player Controller.
2. Get its AC_SequenceManager component.
3. Build an F_SequenceManager struct.
4. Assign the Level Sequence asset you want to play.
5. Fill in the playback settings you want to use.
6. Set Skippable to true or false.
7. Call Client Create Sequence and pass in the struct.

At that point the manager handles asset loading, player creation, callback binding, and any skip setup internally.

---

How to make a sequence skippable #

Set the Skippable field in F_SequenceManager to true before calling Client Create Sequence. The manager will create the skip widget, add it to the viewport, bind its skip event, and end the sequence cleanly if the user chooses to skip.

---

How to make a sequence non-skippable #

Set the Skippable field to false. The manager will still create and play the sequence normally, but it will not create the skip widget or bind skip input.

---

How to stop a sequence early #

Call Client Stop Current Sequence on the manager. This safely stops the current player and allows the normal stop/finished cleanup path to run.

---

How to check whether a sequence is already active #

Call Is Playing Sequence before starting a new request. If it returns true, the manager already has a valid active sequence player.

This is especially useful if you want to prevent overlap between tutorial sequences, quest cinematics, or interaction-driven camera moments.

---

How to reuse it for quests, tutorials, and interactables #

Keep the sequence logic out of the world actor itself. Let the actor, quest step, or tutorial controller decide when a sequence should happen, then send a request to the player's AC_SequenceManager.

This gives the project a shared playback service rather than many actor-specific cutscene implementations, which is exactly the architecture the demo board is encouraging.

---

How to react to playback events #

Bind your project-specific logic to the manager's callback layer rather than directly to each created sequence player. The graphs show that the manager already forwards play, reverse, pause, camera cut, stop, and finished. That makes it the best place to hang UI, quest progression, or interaction-state logic.

---

Summary #

The Sequence Manager is a compact but practical system. It wraps Level Sequence creation, playback, callback binding, optional skip support, and cleanup into one Player Controller component. The result is a much cleaner project-wide workflow for cinematics and scripted moments.

From the provided implementation, the intended usage is straightforward: create a small struct, call Client Create Sequence, let the manager own the playback lifecycle, and call Client Stop Current Sequence when needed. For buyers or teams integrating the system into a larger project, the biggest value is consistency. One active manager per player means fewer one-off sequence Blueprints, clearer event flow, and safer cleanup.