Goal
This recipe extends a hold command into a multi-participant route. Use it for interactions such as cooperative levers, shared repair actions, synchronized panels, or group-only objectives.
Build From A Working Hold Command
- Complete Hold And Multi-Tap Interaction first.
- In Command Details, switch the command from Solo to Co-op so the Multi Participant section is visible.
- Set required participant count and shared threshold values.
- Choose enter mode and release behavior.
- Assign cancellation input if participants can leave before completion.
- Add prompt text for current participant count, required participant count, stage, and progress.
Prompt UI Requirements
The widget should show waiting, contributing, complete, and cancelled states distinctly. Participant count should be visible when the user must wait for others. Progress should reflect runtime route state, not a local-only widget timer.
Verification
- One participant enters and sees that more participants are required.
- Enough participants can contribute to the same route.
- Progress reaches completion only when runtime threshold rules are satisfied.
- Cancellation removes the participant from the correct route.
- Execution actions run once for the completed route.
Route Test Matrix
- One participant enters and sees waiting state.
- Second participant joins and both see updated participant count.
- Progress contribution advances shared progress.
- One participant releases early and release behavior matches the authored rule.
- Cancellation removes only the intended participant or route.
- Completion runs the intended execution actions once.
- Late joiners see the correct route state or rejection.
Failure Diagnosis
Route mismatch usually means the target, point, command, participant, or phase identity is not the same between prompt display and server validation. Recheck stable ids, current focused surface, command page, and whether participants are entering the same target route.
Authoring Prompt Text
Use prompt text that tells users what state the route is in: waiting for participants, contributing, ready, cancelled, or complete. Include participant count and required count when the user needs to know why progress has not started. Include progress percent when contribution is visible over time.
Authority Test
Run the recipe in multiplayer and verify route state is accepted by the server, not just by local widgets. Completion should trigger the intended action once and shared state should update for every client that can observe the target.
Authoring Fields To Recheck
- Base command works as a single-participant hold.
- Multi-participant configuration is enabled on the same command row.
- Required participant count is greater than one when cooperation is required.
- Shared threshold and contribution values match the intended duration.
- Cancel input exists when participants should be able to leave.
- Prompt provider text includes participant and stage information.
Participant UX Review
A participant should know whether they are waiting, contributing, blocked, cancelled, or complete. If the route requires more players, the prompt should say so. If the user can cancel, the prompt should show the cancel control. If progress decays or resets on release, the widget should make that behavior understandable.
Network Review
Test with late joins, early releases, cancellation, and two players activating at nearly the same time. The server should own completion and execution actions. Clients should display route state without creating separate local-only routes.