Submitting a game

How games reach the site today

There is no public submission form, no upload page and no self-service developer portal. Developers do not have accounts on the platform.

Every game on One Game a Day is added by the One Game a Day team. The team imports the game's folder, checks it, gives it a release day and publishes it.

If you have a game you would like considered, get in touch with the team. The About page says how.

To be clear about what this page is not:

• It is not a promise that a game meeting the checklist will be published. Whether and when a game is released is the team's decision.
• It is not a set of terms. No terms for submitting games and no content policy have been published. Raise questions about rights and licensing when you get in touch.

What the page does give is the list of things a game has to satisfy to get through the platform's validation and to present well once it is live. All of it is derived from the rules in Game package format, the metadata reference and Sandbox and permissions.

Technical checklist

A game that fails any of these is rejected by validation.

The folder

• The game is one folder with an HTML entry page at its top level, named index.html, or the only HTML file there.
• The entry page is smaller than 6 MB.
• The folder has at most 2,000 files, no file is larger than 50 MB, and the whole game is at most 300 MB.
• Every file has an accepted type. No server-side code, no executables, and no documents such as .md or .pdf files, apart from README, LICENSE and CHANGELOG files at the top level.
• There are no hidden files, keys, certificates, environment files, .git or node_modules folders in it.
• No file path contains a backslash or any of <, >, ", |, ?, *, #, %, and no name ends with a space or a dot.
• No two paths differ only by upper and lower case.

References

• Every file the game refers to is in the folder.
• References use the exact upper and lower case of the real file names.
• All references are relative. None begins with a slash, and none climbs out of the folder.
• Nothing is loaded from another website: no CDN scripts, no hosted fonts, no remote images, no analytics.
• The game still runs when served from a sub-path with no other network access.

Metadata

• If there is a game.json, it is valid JSON, uses only known fields, and every value is within its limits.
• The slug is 2 to 60 lowercase letters and digits with single hyphens, and is not a reserved word.

Behaviour checklist

These do not fail validation, but each one describes something that will not work, or will work badly, for players.

• The entry page has a viewport meta tag. Without one the game may render tiny on phones.
• The game sizes itself to its window and handles resize. The frame changes size when a player enters full screen or turns a phone.
• The game does not use alert, confirm or prompt. They are blocked unless a permission is granted.
• The game does not open new windows or tabs. That is blocked unless a permission is granted.
• The game does not register a service worker.
• The game saves with localStorage, not cookies.
• The game does not try to navigate the page that contains it.
• The game does not need the camera, microphone, location, motion sensors, USB, MIDI or payment requests. None of these is available.
• The game does not need SharedArrayBuffer or threads.
• The game copes with a missing or unreadable save.
• If the game's code is in separate script files and it uses pointer lock, forms or downloads, the matching permission is set in game.json.

Presentation checklist

A game is shown to players through its metadata. These items are what make its page complete.

• title, up to 80 characters.
• tagline, one line of up to 120 characters.
• description, a few sentences of up to 1,200 characters.
• instructions, a short "How to play" of up to 2,000 characters.
• controls, listing each key, click, tap or button with what it does, for every input the game supports.
• category, one of the fifteen category identifiers.
• tags, up to twelve lowercase labels.
• inputs, stating honestly which of keyboard, mouse, touch and gamepad really work. Players use this to decide whether a game suits their device.
• orientation, set to landscape or portrait if the game is built for one.
• developer, if you want a "Made by" credit.
• A thumbnail image file in 16:9, at least 1280 x 720, with the important parts away from the edges. Without one, make sure the game's opening screen looks right on its own, because that is what the automatic screenshot captures.

The platform also runs its own check on how complete a game's page is. It flags a game when any of these is true:

• Its address only repeats a file name, such as index-6, instead of naming the game. The address is permanent once the game is released.
• It has no thumbnail.
• It has no tagline.
• Its description is shorter than 80 characters. The check suggests 80 to 300 characters saying what the game is and why it is fun.
• It has neither instructions nor controls.
• It has no tags.
• It lists no inputs.
• Its title is longer than 50 characters, which search engines cut short.

Testing without the platform's tools

The platform's validator is not publicly available, so you cannot run it yourself. You can still catch most problems by hand:

1. Serve the game folder from a sub-path of a local web server, not from the root.
2. Disconnect from the internet, or block other sites, and open the game.
3. Watch the browser console for failed or blocked requests.
4. Resize the window while the game runs, and try it in a narrow window.
5. Reload and check that saved progress is still there.

Planned

These items appear on the platform's roadmap. None of them exists yet, and none has a date.

• A "report a problem" link on game pages.
• Short preview clips shown on hover, captured when a game is imported.
• Localisation of the site, including per-language game metadata.

A public submission form and a developer portal are not on the roadmap at this time.

For the path a game follows once the team has it, see Publishing workflow.