Rooms And Sessions Reference

Execution separates setup from observation. Rooms controls which games players can enter; Games in progress shows session instances already created by those joins.

Rooms And Game Sets

A Room owns one player link and may contain games directly or inside named game sets. Game sets are organizational containers inside Rooms; they do not copy or change catalog definitions.

Use + beside Rooms to create a Room after entering and confirming its name. Each Room has a + action for creating a game set; game sets and Rooms can be renamed. The protected main Room cannot be renamed or removed. Room rows also provide the game placement, full room link, and shortcut controls.

Game Row Controls

Controls act on the game placement in the Room:

• arrows change the order within its current Room or game set,
• participant count overrides an allowed open count for the next run,
• Start opens the saved game for joins,
• Stop prevents new joins,
• Open test client opens the Room's player flow in another tab,
• Change game set moves the placement to a Room root or game set,
• X removes the placement from the Room.

Changing or removing a placement does not rename, move, or delete the catalog definition.

Shortcut Controls

Edit the slug in the Room row and click Add/Update shortcut to reserve or update it. Unsaved text is visually distinct from the saved shortcut. Use Copy shortcut to copy the saved /r/{slug} link and Release shortcut to free it. Generate secret shortcut text inserts a sequence into the field; save it with Add/Update shortcut. A Secret tag marks saved shortcuts containing that sequence in order. Adding other characters preserves the tag, while deleting or reordering sequence characters clears it. The full Room link is a separate control.

Starting A Run

Start uses the last saved definition, performs execution validation, and creates one run. Participants joining that open game are allocated into one or more sessions according to Assignment.

A session with a positive Players per session value waits until full. An open session uses the run-specific participant count where supplied. Stop closes admission and completes current play with final calculations and configured Results pages. Results are delivered before connections close; saved session history is retained.

Games in progress Fields

• Game identifies the Room game that created the session.
• Status summarizes the current lifecycle state.
• Room identifies the entry Room.
• Players shows readiness and connection information; hover exposes the complete participant list when the compact line is truncated.
• Opened is the session opening time.
• session-N (E) shows the session ID and recorded event count E.

The event count is a compact progress signal. It is not a score and may increase because of timers or server-side transitions as well as participant actions.

Ordering And Filtering

Nonterminal sessions appear first. They are ordered by ascending event count, then newer opening time, so the least-progressed session is easiest to notice. Terminal sessions follow in newest-first order.

At five or more sessions, the filter searches game, Room, session, status, game type, and participant names. Rooms and Games in progress have independent scroll areas.

Session Actions

• Eye opens the read-only Moderator view.
• Finalize closes a session that has not reached a terminal lifecycle state.
• Download saves the session JSONL event log.

For Free Form and Market runs whose sessions share one game-level view, only the first relevant card exposes the eye; later cards show stage above.

Status Interpretation

• waiting: the session needs participants or another prerequisite.
• running: execution is in progress.
• completed or finalized: the session is terminal.
• stopped: admission or execution was explicitly stopped.
• abandoned / SERVER_RESTART: the former live process ended during a server restart; the session is historical.
• Update cadence delayed: a timer-driven game experienced a longer update gap than expected.

Use the status together with Players, event count, and Moderator view. No single field alone proves that every participant completed the intended path.