Manifest reference

manifest.json is the game's declaration to the portal: who it is, which version this is, what it sends and what the portal may believe about it. It sits next to index.html in the build output. The schema is gameManifestSchema in @gameportal/sdk-types; the platform validators read the same file out of your build (rules R-MAN-*, R-BLD-06, R-SDK-*), and a manifest that does not parse means the game does not ship (R-MAN-01).

JSON has no comments, so this page explains every field. The table of all fields is generated from the schema; the sections after it say what each field is for and which rule watches it.

{
  "id": "my-game",
  "version": "1.0.0",
  "entry": "index.html",
  "sdkVersion": 1,
  "name": "Oyunum",
  "genre": "arcade",
  "session": "quick",
  "languages": ["tr", "en"],
  "saveVersion": 1,
  "challenge": {
    "metric": "round_score",
    "targets": { "easy": 150, "medium": 300, "hard": 500 }
  },
  "events": {
    "round_end": { "props": { "score": "number", "hits": "number" } },
    "new_best": { "props": { "score": "number" } }
  },
  "scores": {
    "round_score": { "maxPerSecond": 60, "integer": true, "max": 1200 }
  }
}

All fields #

events and scores are maps: the key is a name you choose (snake_case), the value says what that event or score mode may look like. In the table <event>, <prop> and <mode> stand for those keys.

Identity #

Catalogue #

Save #

saveVersion is the format of the save the game writes. It goes into ready and every save. When the format changes, raise it here and in createBridge(), and add an upgrade step (see save formats). Never lower it: the portal refuses to let an older build overwrite a save with a higher version (conflict), and the bridge then asks the player to reload (R-STO-05, R-STO-07).

Events #

events lists every event the game sends with bridge.event(name, props), with the type of each property. The portal answers an event it does not know, or one with an undeclared or wrongly typed property, with invalid. Events feed badges and daily challenges, so a refused event is a reward the player never gets.

"events": { "round_end": { "props": { "score": "number", "hits": "number" } } }

• The event name and every property name match ^[a-z][a-z0-9_]{0,63}$.

• A property type is "string", "number" or "boolean"; a property is accepted only if it is declared here.

• props may be left out for an event without properties.

• At most 5 events per second may be sent.

• List only what the game really sends: a declared event that never arrives is reported by R-MAN-06.

Rules: R-MAN-03 (every sent event is declared and typed; a session never receives invalid) and R-MAN-06.

Daily limits #

An event may carry two optional limits. The portal stores an event only within them; one outside is ignored like a repeated event id (the game still gets ok: true, the response's accepted does not count it), and the rest of the batch is stored as usual.

"events": { "run_end": { "props": { "score": "number" }, "perDay": 29000, "max": { "score": 5000 } } }

The portal counts some events into a player's progress: a badge that counts an event (Simit Sarayı's first franchise), and the stage rule that picks the daily challenge's tier (one event per run, match or board). Every such event needs perDay, and a number property the portal adds up needs max (R-MAN-09). Which events these are is the portal's data, not the manifest's, so the reviewer asks for them when a badge or stage rule is set up. Make the numbers generous: at least 3 times what a dedicated player reaches in a day. The portal's own games use 86 400 seconds divided by the fastest the event can happen (the shortest run plus a 2 s restart, the shortest board, one prestige a minute). Do not cap the challenge metric's value below the hard target.

Rules: R-MAN-09.

Scores and plausibility #

scores lists the score modes the game reports with bridge.score(mode, value). Everything the game reports runs on the player's device, so any number may be forged. The portal checks each score against the rules of its mode, in this order:

A rejected score is accepted at the message level (the game gets ok: true and is not told) but stored as suspicious, and it never reaches a leaderboard. Too tight a number rejects honest players; one far too loose lets forged scores through.

Derive the numbers, then prove them. Compute maxPerSecond from the rules of your game (the most points the fastest possible player can earn per second), take a margin of up to 2x, and write a test with a bot that plays as fast as the rules allow and never beats it. The starter's test/plausibility.test.ts is the example: its bound is about 55 points per second, the manifest says 60, and the best bot never beats it over any window.

• The mode name matches ^[a-z][a-z0-9_]{0,63}$.

• At most one score per second may be sent.

• A score is whatever number your game ranks by; send it at the end of a round, not on every frame.

Rules: R-MAN-04 (every mode has maxPerSecond, and integer and max where they hold) and R-MAN-06.

Leaderboards #

A score mode gets a public leaderboard only when its manifest bounds the value on both axes, because a board of numbers the player's own device reports would otherwise rank the fakers. Everything else still works (the scores are accepted, stored and drive challenges); it just has no board.

Daily challenge #

"challenge": { "metric": "round_score", "targets": { "easy": 150, "medium": 300, "hard": 500 } }

A game with a challenge takes part in the portal's daily challenge: each day the player gets one of three targets, picked by their stage, and the portal shows the progress.

Rules: R-MAN-05, R-MAN-07, R-TIM-02 (daily counters restart only on the portal's day message).

Not in the manifest #

• The English name, the tagline, the description and the tags: the portal keeps them in its copy file; you hand them over with the submission (R-I18N-02).

• Cover pictures.

• Which version is live: that is a value in the portal's database. A rollback changes the value, not the files.

• Rights and credits: public/CREDITS.txt, shipped in the build (R-CNT-02).