The DHSeaDev arcade is a collection of free browser games and one app at play.dhseadev.online, served as plain files from Cloudflare Pages with no accounts and no ads. As of 21 September 2026 it holds ten games and one app. Adding one takes a folder and a single row in one table, and every shared check runs against every row. This post is how that works, and what those checks caught when Mosslight went through them on 20 September.
If you want the history instead: why the games left WordPress for static hosting, the back button that was invisible, one build running in three places, and what Mosslight is are the earlier posts. This one is about the process that sits under all of them.
What does it take to add a game to the arcade?
A folder and a row. The folder holds only the files the game serves, because the build copies the whole folder to the live site. The row goes in one file, scripts/entries.mjs, and carries the game’s name, its one-line pitch, its search title and description, and the page on this site that writes it up. The build refuses a row without its site page, search title or search description.
Everything else comes from that row: the card on the arcade’s front page, the sitemap, the list for AI crawlers, the structured data on each page, the back button, and a hidden page heading for screen readers when the game has none of its own. On the arcade itself, a game cannot be listed but missing, or live but unlisted, because it has only one list.
Why can no game skip a check?
Because a skipped check is how a broken game ships. Earlier this month three of the arcade’s test scripts each kept their own hand-typed list of games. Prismwar was added to the build, deployed, and never tested by any of them, because nobody added it to three other lists. Now all three read the same table, and the main one stops with an error if the list it builds is shorter than the table.
There is also no way to exempt a game from the shared checks. The main test file says why in a comment: an entry exempted from the gate is an entry with no gate. That rule is what caught Mosslight saving under plain, unprefixed names, before any player’s save was at stake.
Why did Mosslight’s itch.io version not work on the arcade?
Mosslight was already live on itch.io as one self-contained file, with its scripts written inside the page and a security rule that allows exactly that. The arcade’s security rule, sent by Cloudflare for every page, only allows scripts loaded as files from the arcade itself. A browser enforces both rules at once. Nothing satisfies both, so copying the itch file across would have loaded an empty page with every script blocked.
The fix was to serve Mosslight’s scripts as separate files and change its own rule to match the arcade’s, while keeping the one line that blocks every network connection. The same pairing works in the other direction: the arcade allows a few outside services for other entries, and Mosslight’s stricter rule shuts them out of its own page. After the deploy I asked the live Mosslight page to contact one of those services. The browser refused and named Mosslight’s rule as the reason.
The itch.io file is still built from the same source. A small script turns the arcade folder back into one file, and before any game code changed, its output matched the file already on itch.io byte for byte. So the arcade folder and the itch.io file come from one source, not two copies.
How do saves stay separate when every game shares one website?
Every game on the arcade saves into the same browser storage, so each one keeps its saves under its own name. Games that began as Chrome extensions get that for free from a small layer the arcade loads ahead of them. Mosslight was written for the web and saved under plain names, which would have failed three of the arcade’s checks and could have clashed with another game’s saves. It now uses the arcade’s storage when it is there and the browser’s own storage everywhere else, so itch.io behaves exactly as before.
What bug did the arcade’s checks miss in Mosslight?
Slot 3. Mosslight has three manual save slots, numbered 1 to 3. My first version of the change that moved Mosslight’s saves into the arcade’s storage loaded slots 0 to 2 when the game started. On the arcade, anything saved to slot 3 would have looked empty after every reload. The test I wrote for it only tried slot 1, so every check passed.
A panel of three reviewers found it. Each read the change against a short description of what it had to do, without my reasoning, and one of them followed the slot numbers through the code. They also found three smaller problems: a start-up error that would have been silently swallowed, a failed read that could have saved a new game over a real one, and a slot that could show as full when storage was blocked. All four are fixed, and the save list now comes from the same place the settings screen draws its slots from.
How do you know a new automated test actually works?
By watching it fail first. A test that has never gone red on a broken build proves nothing when it goes green. Mosslight’s save test has fifteen checks, and I ran it against three broken versions before trusting it: the original itch.io code failed five checks, the draft that loaded slots 0 to 2 instead of 1 to 3 failed exactly one, and a version that crashes on start-up failed seven and named the error. Then the real version passed all fifteen, along with the rest of the arcade’s suite.
The last check is a person looking at it. I opened Mosslight in both of its themes and at the size it will be played. Several problems on this site have passed every automated check and only showed up on screen.
Where is the arcade’s process for adding a game written down?
In the arcade’s code, which is public on GitHub, in docs/adding-an-entry.md. It covers the row, the folder, storage, the arcade’s and each game’s security rules, building for more than one place, the checks, and how to confirm a deploy on the live site. Most rules keep the incident that produced them, and several keep the date, so none of them gets loosened later for looking arbitrary.
What is not done yet?
- Nothing checks the arcade’s game count on this site. When Mosslight arrived, pages here said eight and nine, and one card said nine next to a chip that said 8, while the arcade served ten games and one app. Those pages were corrected by hand on 20 September, which is exactly the kind of fix that drifts again.
- Mobile layouts are tested in a browser at phone sizes, not on phones.
- A game’s save lives in the browser you play it in. A save made on itch.io does not follow you to the arcade, because they are different websites. Mosslight’s export and import move one between them.
Every game and where to play it is on the games index. Every post is on the devlog and in the full history.