Testing a Game Before Class

Test a game before using it with players. Demo mode is helpful, but the most realistic browser test uses the moderator dashboard and separate player tabs.

First Check From Design

1. Open the intended saved game in Design. If you started from Demo, use Save As to create your own copy first.
2. Resolve Validation errors, review any warnings, and save.
3. Use Test players → Open test player once per participant needed for the session. It starts a run from the saved definition without requiring a room placement.
4. Play through Results in the separate tabs. Compare the values with a small hand calculation, rather than checking only that a Page appears.
5. Stop the test run, then open it in Run Logs and confirm the decisions and results in Primary analysis.

Saving a changed definition or applying a proposal stops its open test/run. Start it again to test the new revision; an old player tab does not switch to the new definition.

Then Check Participant Entry Through A Room

1. In Execution, place the saved game in a separate test room and start it.
2. Copy the room link and open it as a participant, preferably in a separate browser profile. Enter a player name and optional PIN, select the game and join.
3. Add enough participants to fill the session. Open test client beside the room game is useful for the remaining test tabs.
4. Confirm Game sessions and Moderator view show progress. Complete the intended path, then stop the test run.
5. Only after this check, start the live game in the intended room and share that room's link.

The two checks cover different work: Design tests the saved game, while room entry also tests the invitation and lobby used by participants.

Why Separate Tabs Matter

A real run has one browser client per player. Separate tabs expose issues that a one-tab Demo cannot show, such as:

• session fill behavior,
• duplicate player names,
• reconnect behavior,
• player-specific waiting screens,
• simultaneous player decisions,
• moderator active-session status.

What To Check

Check:

• players can open the room link,
• the intended game appears in the room,
• fixed-player games wait until the session is full,
• one-session games show content when expected,
• each player sees the correct player type and username,
• decision controls are visible,
• clicks or Enter submissions give feedback,
• invalid inputs stay correctable,
• the game advances after valid decisions,
• the game reaches a final state,
• Game sessions shows sensible status,
• stopping the game prevents new joins.

Verify the actual player presentation for each game type. Matrix, Tree and Market Layout help preview its structure; Auction Layout is a settings workspace with a separate participant board. Check Instructions, decisions and Results. Confirm that every Page reference resolves to a value, Choice, or Image when that Stage is reached.

When a Stage has several Pages, test at least two Player Types when their Audience rules differ. Confirm that Active content takes priority over Observe and Glance content and that a missing rule remains Passive.

Testing Uploaded Games

Uploaded games can differ from built-in reference games. Test the actual uploaded file that will be used in class.

If a game has multiple paths, test at least one typical path. For complex games, also test one path with a different player acting first or a different choice outcome.

Using Demo During Testing

Use Demo when you want a quick visual check of reference-game behavior.

Do not rely on Demo alone for:

• uploaded games,
• final classroom readiness,
• testing multiple real browser clients,
• verifying room links.

After Testing

Stop test games that should not remain visible to players. If you used a separate test room, leave the live class room clean until you are ready to start the real run.