Start With A Solo Command
A normal command row uses its command id, activation mode, input pattern, input action, requirements, prompt text provider, and execution actions. In the editor, keep Command Details set to Solo when one interactor owns the full interaction: opening a nearby chest, talking to an NPC, picking up an item, pressing a personal button, or triggering a simple machine.
Build the solo command first even when the final design is co-op. A working solo command proves the point id, command id, input action, prompt provider, requirements, target component, interactor component, and execution action are all wired correctly. Multi-participant routing should be the next layer, not the first layer.
Convert To Co-op
In Command Details, switch the command mode from Solo to Co-op when the command should wait for more than one participant or accumulate group contribution. Co-op reveals the Multi Participant section. Required Participants controls quorum. Enter Mode controls how a participant joins. Pattern controls what participants do after quorum. Resolution Policy controls whether each participant must satisfy the pattern or the group fills one shared threshold.
Entry Versus Execution
Entry is the join step. EInteractionRuntimeMultiParticipantEnterMode can be Instant, Hold, or Multi-Tap. Execution is the active group step. EInteractionRuntimeMultiParticipantPattern can also be Instant, Hold, or Multi-Tap. This lets a command use a deliberate hold-to-join step followed by an instant execution, or an instant join followed by a shared hold or tap contribution.
Do not make both stages complex unless the design needs it. For most co-op interactions, one stage should be simple. Examples: instant join plus hold together, hold to join plus instant execution, or instant join plus shared tap threshold.
All Participants Versus Shared Threshold
EInteractionRuntimeMultiParticipantResolutionPolicy AllParticipantsSatisfyPattern means every required participant must satisfy the authored pattern. Use it for synchronized levers, paired switches, or actions where every player must hold or tap successfully. SharedThreshold means participant contribution is pooled into one route threshold. Use it for pushing, cranking, repairing, channeling, or any task where uneven contribution is acceptable.
Participant State
FInteractionRuntimeParticipantSnapshot tells UI whether the local player has entered, committed, is contributing, is satisfied, has quorum, and what role the local player has. EInteractionRuntimeParticipantRole distinguishes initiator and joiner for copy or visual treatment. FInteractionRuntimeRouteProgressSnapshot tracks group progress and participant counts for the route as a whole.
Prompt Differences
Solo prompts usually show key, command, progress, cooldown, and failure state. Co-op prompts often add participant count, route phase, local participant role, group progress, and cancellation state. Prompt text providers receive these values through FInteractionRuntimePromptBuildContext, and widgets can read canonical route projection from the UI manager or widget base.
Decision Checklist
- Keep it solo when one player can complete the action without shared state.
- Use co-op when the command needs quorum, shared contribution, or participant-specific UI.
- Use All Participants Satisfy Pattern for synchronized actions where every required participant must complete the same contribution.
- Use Shared Threshold when participants can contribute unevenly toward one shared meter.
- Provide a cancel input action when players need an explicit way to leave the route.
- Set point admission capacity so the surface can admit the intended participants.