Activity

Hands a structured interaction (a multiple-choice prompt, a quick-time event, a minigame) over to the host game. The runtime pauses the current commit while the host has it, then resumes with the values the player supplied. The activity itself, including its fields, groups, and how completion mutates the project’s variables, is authored on the Activity (entity) it points at. For the cross-cutting Condition and Timing properties shared by every event, see Event types.

Fields

Activity

The activity to start. Pick from the editor’s activity picker. The picker lists every activity in the project by name; the reference survives renames, so changing the activity’s ID does not break the event.

Variables (per-firing overrides)

For each of the activity’s loose (ungrouped) variable bindings, the event row shows an Override button that opens a small editor. Once you set any override on a binding, that button relabels to Edit. Set any subset of the binding’s fields to change them for this firing only; leave a field blank to inherit from the activity’s declaration. When one or more overrides are set, an accent stripe appears down the row’s left edge and the overridden values render in the accent color in the row’s summary line.

Each override can set:

• Default: the value the activity writes when the player makes no input, replacing the binding’s declared default. Kind-aware (checkbox for bool, number field for int and decimal, text field for string).
• Mandatory: override the binding’s mandatory flag for this firing. Tri-state (inherit / on / off).
• Read-only: an override can lock a normally-editable field for this firing, but cannot unlock a field the activity declares read-only. Tri-state (inherit / on / off); setting off has no effect, since the activity’s declaration wins.
• Min / Max: numeric bounds. Accept literals or expressions (e.g. 10, var_difficulty * 2), evaluated at fire time. Shown only for int and decimal bindings.

Two things are intentionally out of scope for per-firing overrides:

• Grouped variables are owned by the group’s rule and do not appear in the override list. To change how a grouped variable behaves for one firing, either move it out of its group in the activity’s declaration or author a second activity.
• List bindings cannot be overridden inline. Edit the activity definition to change list defaults.

Overrides work like function arguments: only the bindings you touch change for this firing; everything else uses the activity’s authored values.

How the event pauses the flow

The activity event is a cut in the mutation phase. Events authored before it on the same node fire normally as the commit runs top to bottom. When the runtime reaches the activity, it queues the activity for the host, pauses the commit, and returns control. Nothing downstream of the cut executes: not the rest of the node’s events, not scene Update nodes, not the On exhausted node, not the next choice set.

While the runtime is paused, it reports the pause through the HasPendingActivity signal, and both GetChoices() and GetEncounters() return empty. When the host completes the activity, the runtime resumes the commit against the new variable values, and every event held past the cut evaluates its condition against post-activity state. A Jump gated on the activity’s output branches on what the player chose; a Complete project authored after the activity fires only when the activity flipped its trigger.

Activities surface one at a time. A second activity on the same node, or an activity reached by the first activity’s continuation, does not appear alongside the first. It arrives after that first completion. Undo works at the commit boundary, so rewinding a completed activity lands at the point before the choice that triggered it, not between the pause and the resume.

See the Activity (entity) page for the writer-facing view of the pause.

Use cases

Start the activity with its authored defaults. Pick the activity in Activity and leave the override buttons alone. The host renders the interaction exactly as the activity declares it. The everyday case: run this activity here.

Tighten the bounds for one firing of a reused minigame. The same lockpicking minigame appears on both a starter door (range 0 to 5) and a vault door (range 5 to 10). Pick the activity, then open the override for the score binding and set Min and Max to the stricter range. The activity’s declared range stays the same everywhere else.

Make a normally-optional field mandatory here. Open the override for the relevant binding and set Mandatory on. The host cannot complete this firing until the player supplies a value, even though other firings of the same activity leave the field optional. Common when a multiple-choice question has a “no answer” default everywhere except the one scene where downstream branching needs the player to commit.

Lock an editable field for one firing. Open the override for the binding and set Read-only on. The player still sees the field but can’t change it; whatever value the runtime supplies at fire time is what gets written on completion. Handy when the same activity runs both as a normal prompt and as a scripted “cutscene” firing where the answer is predetermined.

See also

• Activities: the authoring walkthrough for building an activity end to end.
• Activity (entity): what the activity declares and how completion writes back to variables.
• Simulator → Activity widgets: what the runtime hands the host, shown live.
• Set variable: for direct variable mutation outside an activity.
• Skill check: often paired with activities to gate outcomes.