Review & Game Lifecycle
Every game has exactly one status. This page explains each state, what you can do in it, how review works, and what happens to old builds when you replace them. The status badge for each game is in My Games → All Games.
The flow: draft → Submit for Review → in_review → approved → published, or rejected → rejected → Resubmit → in_review again. removed is a moderation takedown that can be applied to a game in any state and reversed by an admin.
The five states
| Status | What it means | What you can do |
|---|---|---|
| draft | Created but never submitted. Not visible to anyone but you. | Edit every field, add or replace builds (changes apply immediately), test in the sandbox, and Submit for Review. |
| in review | Submitted and waiting for a reviewer. The table shows "Awaiting review". | Edit the listing and replace builds through the Edit page (applied immediately, so the reviewer sees the latest). The first-upload finalize path is closed — a game that has been submitted only accepts builds via Edit. |
| published | Approved and live. Listed in the catalogue when public; playable by anyone entitled to it. | Make Private / Make Public, and edit — but every edit to a live game is staged as a pending revision for review; the live version keeps serving until it is approved. |
| rejected | A reviewer sent it back. The written reason is stored with the game and emailed to you. | Everything a draft can: fix the listing or build (changes apply immediately) and press Resubmit for Review. |
| removed | Taken down by moderation for a Content Policy violation. Hidden everywhere; nobody can play it. | Nothing that changes the outcome: it is not resubmittable and accepts no new build uploads. Contact developers@edu.games if you believe it was in error — an admin can restore it. |
Submitting for review
Submit for Review (or Resubmit for Review on a rejected game) moves a draft or rejected game to in_review, records the submission time and clears any previous rejection reason. Only those two states can be submitted from. Reviews take 2–5 business days. Before you submit, run the game in the sandbox — a broken build is treated as a policy violation by reviewers.
- Approved — status becomes
published, the publish time is recorded, an xAPI credential is generated for the game (Authentication), and you get an email “Your game is now live!”. It is immediately playable on edu.games and in the teacher and student portals. - Rejected — status becomes
rejectedwith the reviewer’s written reason, shown in the games table and emailed to you. Fix it and resubmit; there is no limit on resubmissions. - A game needs a subdomain before it can be approved — set one on the Edit page if the reviewer asks.
What reviewers check is the Content Policy.
Editing a published game
Students may be mid-licence on a live game, so nothing you change on the Edit page of a published game goes live unreviewed:
- Listing changes and a replacement browser zip are staged as a pending revision — the table shows
edit pending review. The current build keeps serving from its own storage key until a reviewer approves the revision, at which point the fields and the new file swap in together. - Replacement desktop builds are encrypted and packaged immediately (at their own key) but held as pending; approval promotes them to current for their platform. Version-label-only edits to a desktop slot apply immediately — the label is cosmetic.
- A rejected revision shows
edit rejectedwith the reason; the live game is untouched and the staged file is deleted. Edit again to submit a new revision. - Not allowed on a live game: removing a build slot or changing the browser build’s type (HTML5 ↔ xAPI). Contact support to retire a build.
- Applied immediately, never staged: the subdomain (a routing concern, not reviewable content) and the public/private switch.
On any other status — draft, in review, rejected — edits apply the moment you save.
Public and private
Every game has a visibility flag, public by default. Make Private takes a published game out of the catalogue and off its public game page (the table shows private); it stays published, and students who already hold a seat or licence can still launch it, as can you. Free games are only playable by the general public while they are both published and public. Make Public reverses it. Neither needs review.
Deleting a game
There is currently no delete button in the portal. A draft is deleted automatically only when its first upload fails partway (so a half-created record does not hold your subdomain). Deleting a draft releases its subdomain; games in any other state cannot be deleted by you. Email developers@edu.games to remove a game you no longer want.
What happens to old builds
- Replaced browser zips are archived for 90 days from the moment they are superseded — immediately for a draft, in-review or rejected game; at approval time for a staged replacement on a published game — then disposed of by the nightly storage cleanup.
- Replaced desktop builds keep working for a grace window after a newer build is approved, so launchers already mid-download or mid-session are not cut off, then retire.
- Uploads that never finalize (you closed the tab, the zip failed validation) are swept after 48 hours.
- Storage accounting: your quota counts the live build of every game plus any staged or still-in-grace desktop builds; archived browser zips waiting out their 90 days are not charged to your quota. The daily cap of 20 build uploads counts every new build and replacement, in any state.
See Data Retention & Privacy for the full retention schedule.
Removed games and buyers
A takedown sets the status to removed and forces the game private. The entitlement check treats removal as an override: play is denied for everyone — including students, teachers and institutions who paid for it — and no new build can be uploaded. The only residue is a session that started just before the takedown, whose signed play URL stays valid for up to 10 minutes. An admin can restore a removed game to exactly the status and visibility it had before removal. The policy side of this is in the Content Policy.