Encounter Lobby, Ready Check, and Instance Entry

What This System Is

The encounter lobby is a real realtime-authority feature for premade parties. It is not part of the scenario or balance simulators. Encounter boards, portals, NPC services, and UI widgets emit a typed EncounterLobbyUiCommand; the client sends that intent through the normal reliable gameplay-action channel and only renders the replicated server snapshot.

How Authors Use It

1. The party leader opens a lobby for an encounter. A player without a party receives a server-created solo lobby.
2. The server snapshots the authoritative party roster and selects the encounter's default difficulty.
3. The leader may choose any difficulty and compatible mutator set allowed by the encounter difficulty profile.
4. The leader begins a 30-second ready check. Configuration and roster membership are frozen.
5. Every online member answers. A decline or timeout returns the lobby to configuration and clears all ready answers.
6. Unanimous readiness reserves one dungeon_run_id for the roster. The server attaches that same run id to every active session, preserving encounter-runtime isolation and reconnect state.
7. After every member is attached, the lobby becomes entered. A disconnect race leaves it reserved, so the reservation can be resumed instead of silently splitting the party.

Rules And Invariants

• Only the authoritative party leader may open/configure/start/cancel.
• Only roster members may answer a ready check.
• Every member must be online when the check begins.
• Difficulty tiers, mutators, duplicates, and conflicts are validated against assets/gameplay/encounter_difficulty_catalog.json on the server.
• A roster change after the ready check begins cancels the lobby. Leader changes made while configuring are reconciled from party authority.
• The client cannot choose a party id, leader id, roster, reservation id, or entry state.

Validation And Debugging

The shared domain lifecycle lives in crates/world-domain/src/encounter_lobby.rs. The realtime adapter lives in services/game-server/src/encounter_lobby.rs. Commands use GameplayActionRequestKind::EncounterLobbyCommand, while GameplayConditionSnapshot.encounter_lobby carries the player-facing read model.

Player surfaces send one of these commands:

• Open { encounter_id }
• Configure { difficulty_id, mutator_ids }
• BeginReadyCheck
• SetReady { ready }
• Cancel

PlayerGameplayUiState.encounter_lobby contains encounter and difficulty labels, recommended level, selected mutators, deadline, member online/ready/leader rows, lifecycle status, errors, and the reserved run id. This lets multiple visual surfaces share one projection without duplicating lobby logic.

Reconnect and extension points

The assigned dungeon_run_id already participates in active-session lifecycle and resume projections. The next content step is to author encounter-board/portal widgets that send Open, then use the existing scene-transition transaction to move the already-reserved roster to a dedicated dungeon zone. Public matchmaking is intentionally outside this premade-party slice.

Examples

The Slime Infestation activity board can open an encounter lobby, let the leader choose difficulty and mutators, run the ready check, and reserve one dungeon run id for the whole roster before scene transfer.

Related Systems

• World Interactions And Activity Boards
• Encounter Difficulty, Mutators, And Reward Scaling
• Session Handoff And Transfer