Skip to main content

Overview for game developers

One Game a Day publishes one browser game per day. This section explains what a game has to be in order to run there.

One thing first: there is no public submission form and no self-service developer portal. Games are added by the One Game a Day team. Submitting a game explains how that works today.

What kind of game fits​

A game is a folder with an HTML page in it. The platform serves that folder; it does not build, convert or wrap anything.

A game fits when it is:

  • An HTML5 game. An HTML entry page, plus whatever scripts, styles, images, audio, fonts and data files it needs.
  • Self-contained. Everything it needs is inside its own folder and is referred to by relative paths.
  • Able to run offline from that folder. It loads nothing from other websites: no scripts from a CDN, no hosted fonts, no remote API. Outside connections are blocked by default and need a specific permission.
  • Happy at any size. The game is shown in a frame whose size depends on the visitor's screen, and the frame can change size while the game runs.

A game can be a single HTML file with everything inline. All five launch games are built that way.

What a game can use​

Inside its frame a game has the normal tools of a web page: Canvas, WebGL, Web Audio, WebAssembly, web workers, the Gamepad API, the Fullscreen API and browser storage for saves. Inline scripts and eval are allowed, so engines that compile code or shaders at run time are not blocked by that.

Pointer lock, form submission and file downloads are switched on automatically for games that use them. A few other abilities need an explicit request. Sandbox and permissions has the full list.

What has actually been run​

It is worth being exact about this.

  • The five launch games are each a single HTML file.
  • Multi-file games are covered by the platform's automated tests, using a small reference game made of an HTML page, a script, a stylesheet and two images.
  • Exports from large game engines have not been tried on the platform. The file types such exports commonly use, including .wasm, .data, .pck and .unityweb, are on the list of accepted types, but that is not the same as a tested export.
  • Game documents are not served with the cross-origin isolation headers that SharedArrayBuffer requires. A build that depends on threads will not run.

How a game is hosted​

  • Its own origin. Each game is served from its own subdomain, formed from its slug: https://<slug>.onegameaday.net. To a browser that is a separate website from the platform and from every other game.
  • A sandboxed frame. On the game's page at https://onegameaday.net/games/<slug>, the game runs in an iframe with a sandbox attribute. The game's own documents are also served with a content security policy.
  • Files served as delivered. The platform does not modify, minify or inject anything into a game's files. There is no script added to your page and no overlay drawn inside your frame.
  • Builds. Each version of a game is stored as a build, identified by a hash of its file paths and contents, and served from a path that contains that identifier. Files can therefore be cached for a long time, and a visitor never receives a mix of two versions.
  • Loaded on demand. Nothing of the game is requested until a visitor presses Play.

What the platform adds around a game​

  • A page for the game, with its title, tagline, description, instructions, controls, facts and tags, all taken from the game's metadata.
  • A player: Play button, loading and error states with retry, Restart, Favourite, Share and Full screen, a full-window mode on phones and a rotate hint for landscape games.
  • A thumbnail in three sizes, from artwork you supply or from an automatic screenshot.
  • A release day, a release number and a spell as the Game of the Day.
  • A place in All games, in its category, in tag lists, in search and in the release history.
  • Link previews and structured data for search engines, and an entry in the sitemap from the moment of release.
  • A credit: the developer field is shown on the game page as "Made by".
  • Rankings based on real play. See How Most played and Trending are calculated.

What the platform does not provide​

  • No SDK and no API. There is nothing to integrate, and no channel between a game and the page around it. That also means no leaderboards, cloud saves, player identity or multiplayer services from the platform.
  • No advertising and no payments. The platform shows no ads, and has no purchase or payment feature. Every game is listed as free.
  • No developer dashboard. Developers have no login and no private statistics. The figures the platform publishes are the ones on the game's public page: the play count once plays have been counted, and a typical session length after ten counted plays.
  • No translations. The site and its game listings are in English only.

Where to go next​

  1. Game package format: what the folder must contain and what is rejected.
  2. game.json metadata reference: every field that describes a game.
  3. Sandbox and permissions: what a game can and cannot do.
  4. Publishing workflow: from folder to release day.
  5. Submitting a game: the checklist, and how to get in touch.