Skip to main content

Testing with the Simulator

Run a build in the Simulator​

The Simulator is a tool in the Developer Console that runs your game in a framed preview and plays the role of Jest.com for it. The SDK is handled by a mock host, so player identity, purchases, notifications, and other platform calls are answered locally.

Use it when you want a clean, full-viewport surface to:

  • Record a self-review attached to a specific version so moderators can watch a real play-through during review.
  • Drive a build (or a local URL) end-to-end with a checklist that flags common issues before you submit.

The Simulator is reachable from the left sidebar (Simulator) and from the Self Review action on each version in a game's Versions tab.

Record a self-review​

A self-review is a recorded play-through of a specific version. Moderators watch it during game review, alongside the build itself.

  1. Open your game's Versions tab in the Developer Console.
  2. Next to the version you want to submit, select Self Review. The Simulator opens in record mode for that version.
  3. Select Record and grant the browser's screen-capture prompt for the current tab.
  4. Play through your game. The Simulator captures both the iframe and any overlays (login, purchase, loading screen) at the tab level.
  5. When you're done, select Stop & Save. A short form appears where you can add notes for the moderator, then save.

Saved self-reviews are listed under the version in the Versions tab and appear in the moderation view for that version.

Good for​

  • Giving moderators evidence that a version's core flows actually work end-to-end before they review it manually
  • Capturing reproducible play-throughs to attach context (notes) to specific builds
  • Catching regressions in your own flows by replaying saved sessions across versions

Not good for​

  • Demonstrating real platform behavior — login, purchases, and notifications are mocked, not live (use sandbox users for that)
  • Performance or timing measurements — the Simulator runs in a framed container with a mocked host, not the real Jest.com shell

Drive any URL​

In URL mode, the Simulator loads any URL you give it — including http://localhost:<port> — instead of an uploaded build. Recording is disabled in this mode; it is meant for ad-hoc test-drives.

  1. Open the Simulator from the sidebar.
  2. Keep the mode toggle on URL.
  3. Paste your URL (for example http://localhost:3000/g/my-game?host=http://localhost:3000) and select Load.

This works against a running local dev server, so you can iterate on your game and reload the Simulator manually to see changes. There is no auto-refresh today — if your dev server hot-reloads the game itself, that still works inside the iframe; changes that require re-running SDK initialization need a Simulator reload.

If your local server sets X-Frame-Options: DENY or a restrictive frame-ancestors, the iframe will refuse to load. Adjust the dev server config to allow framing during development.

Good for​

  • Trying out a local build against the Simulator's mocked host (products, player data, entry payload) without uploading
  • Exercising the checklist against changes you haven't shipped yet
  • Sharing a repeatable test harness across developers without each person needing a sandbox user

Not good for​

  • Testing inside the real Jest.com shell — use the hosted emulator for that
  • Validating an uploaded build with a live platform — use sandbox users
  • Day-to-day local iteration where the in-game JestSDK debug menu is enough — use local mocks

Reading the checklist​

The Simulator evaluates a set of rules against the SDK activity it observes. Each rule has one of four states:

  • Pass — the rule saw what it expected.
  • Warn — not broken, but worth improving (for example, notifications that never name your game, all notifications using the same body, or bodies containing emoji that may not render on SMS).
  • Fail — a clear problem that will block review (for example, scheduling fewer than one notification per day across D1–D7, logging in an already-registered player, or never calling GetIncompletePurchases after a meaningful amount of startup traffic).
  • Waiting — the rule has not seen enough activity to judge yet. This is the default before you exercise the relevant flow and is not a failure on its own.

Rules cover five areas: user management (SDK initialization, login, guest data), notifications (the D1–D7 sequence, naming the game, scheduling window, customization, asset references, body length, charset), purchases (catalog fetch, purchase start, recovering incomplete purchases), referrals, and analytics (signalling readiness via markGameLoaded(), reporting the first_milestone event via markFirstMilestone()).

The checklist is a guide, not a gate. Some rules remain in Waiting for legitimate reasons — for example, the recovered-purchase rule stays in "Waiting" until your game actually fetches the pending purchase and completes it.

Configure the mocked host​

The Simulator's right-hand Config panel lets you set up mocked platform state for the session:

  • Player — toggle registration, edit username/avatar, log out to restart as a guest.
  • Entry payload — edit the payload the game receives on startup. Changes reload the iframe so the game re-runs initialization.
  • Player data — pre-seed player data, or pull the current in-game state into the editor with Use live state.
  • Notification assets — register known asset references so the checklist can validate them.
  • Purchases — configure products, choose canned responses for BeginPurchase / CompletePurchase, and manage incomplete purchases for recovery testing. When you load a game version, the first catalog product is queued as a pending purchase automatically; remove it if you want to test a clean startup.
  • Subscriptions — edit plans, choose canned responses for begin/cancel, and toggle a subscription Active to simulate a player who already holds it (reload the game so it re-reads entitlement).
  • Referrals — seed referral entries for GetReferrals.

Everything in the Config panel is in-session only. Nothing here writes back to the platform.

Simulated purchases are flagged​

The purchases and subscriptions the Simulator fabricates keep the prices you configured, so treat the amounts as real for display testing, but every one carries sandbox: true — including inside the signed token, which is signed with your game's real shared secret. Have your backend check that flag before it books revenue or hands out anything of value. See Recognize sandbox purchases.