Rooms And Sessions Reference

Execution separates setup from observation. Rooms controls which games players can enter; Active Sessions 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.

Room-level controls create a game set, add games, copy or release links and shortcuts, and remove eligible rooms. The main Room is the account's default and cannot be removed.

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.

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 affects admission to the run; it does not erase sessions or rewrite their captured definition.

Active Sessions 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 Active Sessions 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.