The Developer Portal

dev.edu.games is where you upload games, watch them move through review, test xAPI instrumentation, and see sales. This page walks the sidebar top to bottom — every item, what it shows, and the limits behind it. If you are here for the first time, read the Quick Start first.

Overview

The landing page after sign-in. Until you have finished onboarding it shows a checklist (studio profile, first upload, and so on); after that, four tiles — Published, In Review, Drafts and Total Plays — and the Storage & Games meters:

• Storage used — the sum of your live build sizes against the 25 GB per-account cap. The bar turns red at 90%.
• Games — how many game records you own (drafts included) against the 20-game cap.

Both caps are enforced server-side when you request an upload; the meters use the same arithmetic. Full rules in Packaging Your Game. If you joined as one of the Founding 100, your founder card is revealed here the first time you visit (see below).

Achievements

Eight cards, each earned from real platform activity. Earned cards appear on your public studio page; locked ones show a progress line. The thresholds are:

“Published” means a game that passed review; the teacher, student and country counts come from real classroom usage of your published games (Teachers’ Choice needs more than 2 teachers, Learning Impact more than 100 students, Global Impact 3 or more countries).

My Games → All Games

A sortable table of every game you own — Title, Type, Status, Version, Likes, Submitted — with one action column per task:

• Status badge — draft, in review, published, rejected or removed. A published game with a staged edit also shows edit pending review, or edit rejected with the reviewer’s reason; a published game hidden from the catalogue shows private. What each state means is in Review & Game Lifecycle.
• Play — opens the game as it is served to students (absolute edu.games play link).
• Edit — the listing form, including build replacement.
• Review — Submit for Review on a draft, Resubmit for Review on a rejected game, “Awaiting review” while in review.
• Access — on a published game, Make Private / Make Public. Private games leave the catalogue and their public game page; students who already hold a licence or seat can still play.
• Sandbox — opens an edugames.dev session for the uploaded package (disabled until a browser build has been uploaded).
• Analytics — the game’s Analytics Readiness page.

There is no delete button in the table. A draft whose first upload fails is removed automatically by the upload form; for anything else, email developers@edu.games.

My Games → Upload New

One form creates the listing and uploads the builds. Fields, top to bottom:

• Title (required) and Subdomain (required) — the game’s shareable address, my-game.edu.games, pre-filled from the title until you edit it. Availability is checked live.
• Description and Learning Outcomes — what teachers read in the catalogue.
• Teaching Notes — up to 5 documents (PDF, DOC, DOCX, PPT, PPTX; 10 MB each), each with a short description.
• Builds — tick the slots you ship. Browser: choose Standard HTML5 or xAPI Package, pick the zip (maximum 1 GB, index.html at the root or one folder down) and set a version. Windows: an encrypted package run through the edu.games launcher. Mac: shown as coming soon and refused server-side until the launcher ships. See desktop builds.
• Subjects (toggle chips) and Min / Max Age — catalogue filters.
• Price in AUD (0 = free). With any desktop build the label switches to price per seat per year, and one seat covers every build.
• Images — up to 10 (5 MB each); the first is the cover.
• Save as Draft — creates the record, uploads each file straight to storage, then finalizes: the zip is validated (layout, size, file count, zip-bomb ratio, executable blocklist) before it is attached. Errors link to the exact rule in Packaging Your Game.

You can start at most 20 game-build uploads per UTC day (new builds and replacements, all slots combined). Images, documents and logos do not count.

Analytics Readiness (per game)

Reached from the Analytics column. It shows how your game’s xAPI traffic measures up against the Emission Profile and unlocks the sandbox:

• Conformance badge — Core or Full Learning Intelligence, plus Timed / Choice / Confidence badges as they are observed. Full needs all four capabilities below.
• Observed capabilities — derived nightly from stored statements: Decision tracking (Decision-path Sankeys (P04, P14)); Confidence capture (Confidence vs correctness scatter (P10)); Attempt durations (Time-to-mastery and pace presets (P05, P17)); Objective states (Objective state progressions and the Full badge). Each is greyed until data arrives.
• Competency framework — upload a JSON document mapping your objective IRIs to competencies. Saving a new version replaces the active framework and re-stamps historical statements, which is what gives teachers competency-level insights.
• Test session — pick a persona (Alex, Billie, Casey, Devon) and open the game on edugames.dev with a live, conformance-annotated statement feed. See Testing on edugames.dev.
• Statement inspector — the last 50 statements received under the game’s credential, each annotated pass / warn / fail.

Sales

Titled Analytics & Sales in the portal. Three totals across your published games — Plays, Downloads (desktop builds) and Earnings — then a per-game table of price, engagement, units sold and earnings. Earnings are 70% of every completed sale (pending and refunded purchases are excluded); edu.games keeps the rest, and payment processing comes out of that share. Buyers pay edu.games through Stripe checkout and edu.games pays you — there is no Stripe Connect account to set up. Payouts are monthly; the exact payout terms are those agreed in your developer agreement (Terms of Service).

Plugins & SDKs

• xAPI Credentials — one key/secret per approved game, created automatically at approval. Only a hash of the secret is stored, so the page cannot display it: press Rotate Secret to mint a new one, shown once. These are for server-side use — the player gives each session a short-lived launch token instead (Authentication).
• SDKs & Libraries — a link to the official SDK.

Support

Links to these docs, the API Reference and developers@edu.games. See Community & Support for what to include in a report.

Profile

Your studio as buyers see it: name and display name, studio name, bio, website, studio contact email, phone, city and country, the studio subdomain, and a logo (an image up to 5 MB). The same page changes your sign-in email: a confirmation link goes to the new address and, depending on your account, an approval link to the old one — both must be clicked before the change applies, and each link is single-use.

The Founding 100

The first 100 developers to onboard claim a numbered founder spot during studio setup. Spots are tiered by number — Gold Founder №1–33, Silver Founder №34–66, Bronze Founder №67–100 — and each founder gets a generated card (a scene seeded from the studio name, coloured from the logo) at dev.edu.games/founders/<number>, by email, on the Overview page the first time they sign in, and permanently as the Founding 100 achievement. Once all 100 spots are claimed, onboarding continues without a card.

Your studio page and the studios directory

Claiming a studio subdomain during onboarding (or from Profile) gives you <studio>.edu.games — your public studio page with your profile, achievement cards and published games; the sidebar’s Studio Page ↗ opens it. Every studio with a studio name is also listed at studios.edu.games, a public directory that needs no sign-in and shows each studio’s public published games.

Each directory entry has a contact form. Messages are relayed to the studio contact email you set in Profile — that address is never shown to the sender, and replies go straight back to them — behind a CAPTCHA and a limit of 5 messages per 10 minutes per sender.