Skip to content
Gamivate
Docs

Game spec

A Gamivate game is a self-contained, static HTML5 bundle. It runs in a sandboxed iframe served from an isolated origin, and reports the final score to the platform via postMessage. No backend, no cookies, no network calls beyond fonts — Gamivate owns scoring, leaderboards, and rewards.

1. Bundle

A folder (zipped for upload) with index.html at the root and everything else inline or relative. Plus a gamivate.json manifest:

{
  "name": "Quick Tap",
  "version": "1.0.0",
  "entry": "index.html",
  "orientation": "portrait",     // portrait | landscape | any
  "scoreType": "points",         // points | time | boolean
  "scoreRange": { "min": 0, "max": 200 },
  "capabilities": ["pointer"]
}

scoreRange drives the server-side anti-cheat plausibility check — set it to the real min/max your game can produce.

2. Score contract

The game posts lifecycle events to its parent. Only gamivate:score is required; send it exactly once, at game over. The game never receives the play token — the parent submits the score server-side.

function gvPost(type, extra) {
  try { window.parent.postMessage(Object.assign({ type }, extra), "*"); }
  catch (e) { /* running standalone — no parent */ }
}

gvPost("gamivate:ready");                       // on load
gvPost("gamivate:progress", { value: 0.5 });    // optional, 0..1
gvPost("gamivate:score", {                      // once, at game over
  score: 8500,
  metadata: { combo: 6, matches: 42 }
});

3. Rules

  • Stay self-contained — the sandbox has no same-origin access and blocks its own network.
  • Keep it standalone-playable (wrap posts in try/catch) so it works opened directly, too.
  • score must be a finite number within your declared scoreRange; out-of-range scores are rejected server-side.
  • Don't ship your own leaderboard, accounts, or score submission — that's the platform's job.

Reference implementations live in the game library (e.g. quick-tap, coffee-match). Upload via the dashboard game library.