How it works

Gamestage is six parts.

The creator's web app or page: your HTML, CSS and JavaScript. It draws the game, takes the fan's input and renders whatever the Engine returns. Gamestage never edits this for you: its tooling advises your agent what to write.

The CLI, gamestage: a local tool that inspects a project, scaffolds a new one, writes the browser client and validates the App Manifest, all with no account. Serving the real Engine rules on your machine and proving the migration each need you signed in, and deploying needs that account approved.

The Engine: the server that owns a game's truth. It holds the answer, counts attempts, decides whether a play is accepted and commits the score. One Engine runs one rule set per game format, and nothing in it knows what sport or subject your game is about.

Backstage: the API that knows about workspaces, games, plans, limits and deploys. It is what the CLI signs in to.

Monterosa Interaction Cloud: the platform underneath live games. A Gamestage game is a project on it, a named run of the game is an event, and one go at the game is an element.

Every deployed game is provisioned into Interaction Cloud, Starter included: a deploy always creates its project, event and containers on the platform. What changes above Starter is the Space it runs in, Studio access for content and live operations, and routing analytics to your own destinations, not whether provisioning happens.

Monterosa Studio: the platform's own CMS and live operations UI, and where content is managed above Starter. A producer working in Studio can change a game's styling and copy, for example. Gamestage has no content editor of its own.

The request path

FAN'S BROWSER                    ENGINE                        BACKSTAGE
  page + gamestage.js
      │ GET  /play/v1/games/{game}/rounds/current
      │────────────────────────────►│  public part of the round only
      │◄────────────────────────────│  board, labels, prompt. no answers
      │
      │ POST /play/v1/games/{game}/rounds/{round}/plays
      │────────────────────────────►│  marks against the private material
      │◄────────────────────────────│  outcome, feedback, committed score
                                     │
CREATOR'S TERMINAL                   │
  gamestage deploy ──────────────────┴──────────────►│  plan, limits, publish

Everything a fan's browser can reach is on /play/v1. The creator's own commands go to a different prefix on a different credential, so a fan holding a page has nothing that reaches a creator's workspace.

Why the answers live in the backend

Anything the browser holds, the fan holds. When the page is delivered to the fan's machine, its source, its bundles and every JSON file beside it can be read, changed and replayed. A score the page works out is a score anybody can send, so anybody can send a better one. A limit of three goes kept in device storage comes off in one line in a developer console.

The line is drawn at who decides, not at where the code sits. The page owns what it looks like and what the fan touches. The Engine owns anything a fan would benefit from lying about: the answer, the score, the number of attempts, whether play is open, and settlement. Every rule in the chapters that follow comes from that line.

So deleting the answers from the page is only half of it. They move into the private part of the App Manifest, and a deploy hands them to the Engine. A clean page with nothing on the server leaves the Engine nothing to mark against.

The journey, in one pass

Five steps, each ending in something the next one can rely on. The journey breaks the same route into finer steps, most with their own command.

Inspect the game. gamestage inspect . reads the source without changing it and reports what the browser owns that it should not: answers, scoring, limits, clocks and locks, each with the file and line. You get an inspection report and a proposed App Manifest.

Move authority. The agent edits the manifest and the page. Private material goes into the server-owned container in gamestage.yaml, and the page changes to render Engine state rather than its own. At the end of this step the browser holds no answer and has no second scoring path.

Run the rules locally. gamestage dev needs you signed in, then serves your own container through the same rule set the hosted Engine runs, so the game is playable against a real Engine on your own machine.

Verify the result. gamestage verify runs seven checks against your manifest and the published bundle (the round is the game's own, the attempt cap was chosen rather than defaulted, no answer sits in what a deploy publishes, the page reads every setting a producer can change, the client is present and is the only door to Monterosa, a deadline comes from the server's clock) plus two that need a real browser playing the game (the screen shows what the server decided, and the page notices the connection going and coming back). Each check ends up verified, open (something is wrong) or skipped (this cannot be checked from here, which is not the same as failing). It only counts as verified if nothing is open and nothing is skipped.

Publish. gamestage deploy <game-id> --dir . publishes a snapshot and puts a round on it. A person approves identity and GitHub first, and the account itself has to be approved before a deploy goes through.

The detail of each step is in Build and deploy.

Where a human takes over

The agent does the migration, and a person owns identity, commercial decisions and anything that changes what a live audience can touch. An agent that reaches one of these should stop, say why, and hand over the exact command.

Two commands need a browser and therefore a person:

gamestage login
gamestage link github

login starts a login device flow: the command prints a code and a URL and waits for approval, and it creates an account when none exists. The resulting creator token is stored in the macOS keychain for example, or in an owner-only file outside the project, and never in game code. link github is a second device flow, and the first hosted deploy is refused until it is done: it gives a deployed game a route back to its creator and makes account farming expensive.

Three commands change what fans can reach, so a person decides:

gamestage suspend <game-id>
gamestage wake <game-id>
gamestage archive <game-id>

Suspend takes a game off the air and frees its live slot. Wake puts it back when a slot is available. Archive takes it off the air for good while keeping its record, its claimed id and its files. Delete exists only for a game that was archived without ever deploying: gamestage prune clears that debris, and nothing removes a game that ever went live.

Some inputs cannot be inferred from code at all. If no built game format fits the mechanic, a person decides whether it merits a new format or bespoke customer work. Age gates, consent, privacy and promotion rules depend on facts outside the repository. Ownership, supplier licences and allowed use need confirming. So does the operating model: who changes content, who watches a live game and what service level is needed. Record what a person decided as human_decision provenance; an agent's proposal stays proposed.

Only a person can mark a manifest section approved, and the named owner should check the linked evidence rather than the prose. Particular checks: confirm the identity issuer, keys and token lifetime; confirm the minimum age and the basis for it; supply promotion terms, jurisdictions and either a free entry route or the legal basis for a skill competition; and play the final build at phone and desktop widths, because a skipped browser check is not approval. Build stage does not measure accessibility, so a high stage is not evidence of WCAG compliance.

Moving to a paid plan is a conversation with Monterosa. A paid customer needs a Monterosa account and org created by support, and the service account deliberately cannot create an org itself. See Plans and limits.