Authoring Multi-Participant Routes

Command Setup

1. Create a working interactive command row with a stable FInteractionRuntimeCommandId and input action.
2. In Command Details, switch the command mode from Solo to Co-op. This reveals the Multi Participant section.
3. Set Required Participants to the number of players needed for quorum.
4. Choose Enter Mode for the join step: Instant, Hold, or Multi-Tap.
5. Choose Pattern for active contribution after quorum: Instant, Hold, or Multi-Tap.
6. Choose Resolution Policy for completion: every participant satisfies the pattern, or the group fills a shared threshold.
7. Assign a cancel input action when cancellation should be available from input.

Visible Co-op Fields

Co-op command rows show Required Participants, Enter Mode, Enter Release Behavior, Pattern, Release Behavior, Resolution Policy, Cancel Input Action, Commit Hold Duration, Pattern Tap Count, Pattern Tap Window, Contribution Rate Per Second, and Decay Rate Per Second. The underlying API type is FInteractionRuntimeMultiParticipantCommandConfig, but the editor workflow starts from the Solo/Co-op control.

Input Timing

FInteractionRuntimeMultiParticipantInputSettings controls hold duration, required taps, and tap window for entry and execution pattern settings. Use separate entry and pattern settings when joining should feel different from completing the shared action. For example, a participant can join instantly but then hold for two seconds to contribute to a lift.

For hold patterns, test early release, exact completion, focus loss, and another participant joining midway. For multi-tap patterns, test slow taps, fast taps, missed windows, and route cancellation. These cases expose most authoring mistakes before content scales to more targets.

Release Behavior

FInteractionRuntimeExecutionReleaseSettings controls contribution rate, decay rate, and EInteractionRuntimeMultiParticipantReleaseBehavior. Reset makes released progress start over. Persist keeps progress where it stopped. Decay drains progress over time. Use reset for strict timing, persist for forgiving group tasks, and decay for pressure-based actions.

Shared Threshold

When EInteractionRuntimeMultiParticipantResolutionPolicy is SharedThreshold, FInteractionRuntimeMultiParticipantSharedThresholdSettings supplies the completion threshold and release settings for the pooled group meter. This is the right model for pushing, cranking, channeling, or other tasks where participants add to one total instead of each completing their own meter.

Set the completion threshold high enough that the task feels shared. If one participant can complete the threshold before another participant matters, either reduce contribution rate, raise the threshold, or use AllParticipantsSatisfyPattern instead.

Admission Capacity

FInteractionRuntimePointDefinition has Multi Participant Admission Capacity for the point surface. Keep it aligned with the route design. A two-player command on one shared surface usually needs capacity of two, while two separate linked surfaces can each admit one participant into the same route.

Route Identity And UI

FInteractionRuntimeRouteIdentity includes target id, point id, activation point id, variant id, command id, multi-participant flag, and optional execution instance id. Use it to match prompt rows, progress snapshots, participant snapshots, route events, and outcome events. Prompt text providers can use participant counts and route phase to show copy like 1/2 ready or Hold together.

FInteractionRuntimeRouteProgressSnapshot gives widgets route lifecycle, pattern, raw progress, threshold, participant count, required participants, and quorum state. FInteractionRuntimeParticipantSnapshot gives local-player state for entered, committed, contributing, satisfied, quorum, local contribution, participant count, and role.

Cancellation

Assign Cancel Input Action when a participant should be able to leave or cancel the route through input. Prompt text and widgets should make cancellation visible only while a cancellable route is active. After cancellation, verify the local participant snapshot, route phase, prompt text, and controls all clear or return to the expected waiting state.

Execution Actions

Execution actions run when the route completes according to the command configuration. If an action has participant scope, choose the scope that matches the design: route-wide state changes should run once for the target, while participant-specific rewards or feedback may need participant-aware handling from the execution context.

Validation Checklist

• One player can enter and leave without leaving stale route UI behind.
• The required number of players reaches quorum and moves the route into active contribution.
• Release behavior matches the design for hold and multi-tap patterns.
• Shared threshold routes show group progress instead of only local progress.
• Cancellation input clears local participant state and updates prompt text.
• Execution actions run once for the intended participant scope.
• Route identity stays stable across prompt, progress, participant, and outcome events.