Publishing workflow
This page follows a game from the moment its folder is handed over until after it has been released. Games are imported by the One Game a Day team; Submitting a game covers how a game reaches them.
The states a game moves through
| State | Meaning |
|---|---|
| Draft | The game has not passed validation, or is being held back on purpose. |
| Validated | The game passed validation and is waiting for a release day. |
| Scheduled | The game has a release day that has not arrived yet. |
| Published | The game has been released and is public. |
| Archived | The game has been retired. It is hidden from discovery but still playable at its address. |
Only published and archived games, and scheduled games whose release instant has passed, can be seen by the public.
1. Validation
The folder is checked against the rules in Game package format, and its game.json against the metadata reference.
The checks run when the game is prepared for import and again on the platform's server. The server reads the files it has actually stored, and its verdict is the one that counts.
- Errors stop the import. The game stays a draft, nothing is published and nothing that is already live changes. Each error names the file or field concerned.
- Warnings do not stop anything. They point at features the sandbox will block. Treat them as a list of things to test.
A game that passes becomes a build: an unchangeable copy of its files, identified by a hash of every file's path and contents.
2. Metadata is filled in
The values in game.json are applied to the game's record. Where a field is missing, the platform fills it from the game's page as far as it can: the title and tagline from the page title, the description from the description meta tag, a category and tags guessed from the wording, and the inputs and orientation from the code of the entry page.
The game's page is built from this record. The metadata reference lists exactly what is used for each missing field.
3. Thumbnail
Each game has one piece of artwork, stored in three sizes: 640 x 360 and 1280 x 720 for the site, and 1200 x 630 for link previews.
Supplied artwork. Put a file named thumbnail.png, thumbnail.jpg, thumbnail.jpeg or thumbnail.webp at the top level of the folder. A supplied image always takes priority.
The image is scaled and cropped from the centre to fill each size. Use a 16:9 image of at least 1280 x 720 and keep titles and faces away from the edges, because the link-preview size is slightly wider than 16:9 and trims the top and bottom.
Automatic screenshot. When no image is supplied, the game is opened in a 1280 x 720 window with sound muted, and a screenshot is taken a few seconds after the page loads. Nobody presses anything first, so whatever the game shows on its own at start-up becomes its artwork. A good title screen makes a good thumbnail.
Generated cover. If no screenshot can be taken either, the site draws a cover from the game's title on a background in its category colour. A missing thumbnail never blocks a release.
The team can replace a game's thumbnail later.
4. Scheduling
A validated game is assigned a release day by the team.
- A day is a calendar day in the site's time zone, written
YYYY-MM-DD. - Each day holds one game. A day that is taken cannot be given to a second game.
- The earliest day a game can normally be scheduled for is the next one whose slot has not opened yet.
Until its day comes, a scheduled game is completely private. Its page returns "not found", it is absent from lists, search and the sitemap, and its files are not served, even at their exact address.
5. Going live
A day's slot opens at the site's release time. At that instant the game is public. No one presses a button, and nothing is redeployed.
From that moment the game:
- Is featured on the front page as "Today's game" for that slot, unless the team is featuring a different game at the time.
- Has a live page at
https://onegameaday.net/games/<slug>and can be played. - Is listed in "Recently added", on All games, on its category page, under its tags, in search and in the release history.
- Is in the sitemap.
Shortly afterwards its state changes from scheduled to published and it receives the next release number.
6. After release
The game stays in the catalog after its day as Game of the Day. It can be found, played and shared at its permanent address, and it takes part in "Most played" and "Trending" according to real play. See How Most played and Trending are calculated.
Once plays have been counted, its page shows a play count, and after ten counted plays a typical session length. There are no private statistics for developers.
7. Updates as new builds
To change a released game, a new version of the folder is imported. It goes through the same validation and becomes a new build beside the old one.
- Unchanged files produce no new build. A build is identified by its contents, so importing identical files changes nothing.
- Before release, the new build is used at once. A game that has not been released yet switches to its newest valid build.
- After release, the new build waits. A released game keeps serving the build it had. The new one is stored and can be previewed by the team, who then switch the game over to it.
- A failing build never replaces a working one. If the new version fails validation, it is recorded as failed and the game carries on serving its current build.
- Going back is immediate. Earlier builds are kept, and the team can switch a game back to one.
Each build is served from its own path, so a player never receives a mixture of files from two versions.
Two things to keep in mind when updating:
- Saves carry over. Players' saved data belongs to the game's origin, not to a build. A new build reads what the old one wrote, so do not break your save format.
- Edits made on the site are kept. If the team has edited the game's title, text or other details on the site, those edits stay, and values in a later
game.jsondo not overwrite them.
8. Retirement and withdrawal
Retiring a game takes it out of the front page, search, the rankings and the sitemap. Its page keeps working, shows a notice that the game has been retired, and stays in the release history marked "Retired". Retirement can be reversed.
Withdrawing a game takes it off the site and frees its release day. Its files and history are kept by the platform.
Nothing is deleted by either action.
Summary
folder -> validated -> scheduled for a day -> live at the release instant -> numbered -> in the catalog
|
new builds, switched in by the team