Packaging Your Game

Every browser build — html5, xAPI or SCORM — is uploaded as a single .zip archive. The checks below run automatically when your upload finalizes — if one fails, the error message you get back links back to the relevant section here. SCORM exports follow the same rules with one difference: the entry point is imsmanifest.xml rather than index.html — see SCORM Packages.

Zip layout

Your zip must contain an index.html either at the root, or exactly one folder down (e.g. a build output directory). Deeper nesting is not accepted. (For a SCORM package the same rule applies to imsmanifest.xml instead, and the launch file is whatever the manifest names.)

OK — index.html at the root
mygame.zip
├── index.html
├── game.js
└── assets/
    └── sprites.png

Also OK — index.html one folder down
mygame.zip
└── build/
    ├── index.html
    └── assets/

Rejected — index.html nested deeper than one folder
mygame.zip
└── build/
    └── web/
        └── index.html

Size limits & quotas

Upload frequency

Separately from the size and count quotas above, you can start at most 20 game uploads per day (new builds and replacements combined, counted per UTC day). Image, document and studio-logo uploads don’t count towards it. If you hit the cap you’ll get a 429 when requesting an upload URL, and the budget resets at 00:00 UTC. The cap is about iteration churn, not storage — if you’re re-uploading repeatedly to debug a build, test it in the dev-portal sandbox first rather than spending upload slots.

File-count cap

A zip may contain at most 10,000 entries (files and folders combined). This is well beyond what any reasonable html5 build needs — if you’re close to the limit, check for stray build artifacts or an accidentally-included node_modules folder.

Compression safety

Uploads are checked against a zip-bomb guard: no single file may expand more than 100:1 when decompressed, and the total uncompressed size of the archive is capped well above any normal game build. Ordinary asset compression (PNG, JPEG, audio, gzip’d JSON, etc.) is nowhere near this ratio — this check only ever fires on maliciously crafted archives.

No native executables

Html5 games run inside a sandboxed iframe — nothing in the package should ever need to execute outside it. The following extensions are blocked anywhere in the archive:

.exe  .dll  .msi  .bat  .cmd  .sh  .app  .dmg  .com  .scr  .ps1  .vbs  .jar  .apk

Desktop builds (Windows and Mac)

A game can ship more than one build: a browser build (the html5, xAPI or SCORM zip above) and a desktop build for each platform, each with its own file and version. Tick the builds you ship on the upload form. Students with a seat get every build — one licence covers the whole game, and any game with a desktop build is priced per seat per year.

A Windows package is your build folder zipped up, executables and all — the blocklist above applies to browser builds only. We encrypt every file and add launcher-win.exe, which checks out a seat and launches your game. If the zip contains several .exe files, name the one to run in a top-level edugames.json:

{ "entry_exe": "Binaries/Win64/MyGame.exe" }

A Mac package is your built MyGame.app bundle zipped up (the bundle itself, not just its contents — right-click the .app in Finder and choose Compress). We encrypt every file inside it, keep its symlinks and permissions, and add edu.games Launcher.app, which is signed and notarised with Apple; students double-click it, it opens a Terminal window, checks out a seat and opens your game. The bundle must be signed (ad hoc signing, which Unity, Godot and Xcode do by default, is the minimum — a Developer ID signature is recommended for schools that lock Macs down). If the zip holds several bundles, name the one to open in edugames.json:

{ "entry_app": "MyGame.app" }

Nothing else about your game changes: the same seat covers the Windows and Mac builds.

xAPI tracking is optional

None of the above requires xAPI instrumentation — a plain html5 zip that meets the layout and size rules will publish and play fine. If you want richer progress tracking for teachers and Learning Intelligence presets, see the xAPI Overview and the SDK & Libraries docs. You can add it any time after your first publish — it’s not a blocker for review. SCORM packages get progress tracking without any instrumentation: the runtime turns the course’s status, score and quiz responses into statements for you (see what teachers see).