What I Checked Before Shipping a Browser Game to itch.io

I uploaded a small first-person sci-fi demo to itch.io this week. The build already ran in a normal browser, so I expected the upload to be the easy part.

It was not difficult, but it did force me to separate “works on my machine” from “someone else can actually play this.” A browser game inside an itch.io page has a few extra ways to fail: the iframe can lose focus, a remote asset can stall, and a refresh can expose state that was never properly reset.

Here is the checklist I used before calling the build public.

Start from a clean page

My first pass was deliberately boring. I opened the game from its public page, clicked into the frame, and checked every control shown in the instructions: movement, sprint, jump, interaction, universe switching, and the memory log.

That click into the frame matters. Keyboard input that works perfectly in a local tab may do nothing until the embedded game has focus. A player will not diagnose that problem; they will assume the game is broken and leave.

I also tried resizing the window and returning to the page after switching tabs. The goal was not to cover every browser combination. I just wanted to catch the obvious cases that make a playable build feel dead on arrival.

Refresh in the middle, not only at the beginning

A fresh load is the easiest state a game will ever see. I refreshed while moving through the first area, after interacting with an object, and after switching between the available universes.

For each refresh I checked three things:

• the player started from a valid position;
• old input handlers were not duplicated;
• the UI and game state agreed about what was available.

Restart bugs are easy to miss in short demos because the first run looks fine. The second run is where duplicated timers, stale flags, and half-reset objects usually become visible.

Test the network assumptions

This build uses Three.js and two background music files that are loaded remotely. That keeps the package small, but it also means the game is not truly self-contained.

I tested the public build from a fresh tab instead of trusting cached files from development. I also made the dependency clear on the game page. If the network is slow, a player should know whether the game is loading or has failed; silence and a blank frame are not useful feedback.

For a later build I would rather package more of those assets locally. For this first public version, documenting the limitation was more honest than pretending it did not exist.

Do not expose a checkout that cannot finish

The larger project has more areas and systems than the itch.io demo. The uploaded build only includes the first three universes: the engine core, a low-gravity area, and a high-entropy dystopian area.

I kept later content out of the playable path and did not leave an incomplete purchase flow inside the itch.io version. A button that looks like a real checkout but cannot complete is worse than a clear “demo ends here” boundary.

This was less about payment implementation and more about player trust. The public build should only promise what it can deliver in that session.

Play more than the opening minute

A loading screen and ten seconds of movement can make almost any prototype look functional. I played several complete sessions and kept going after the first successful interaction.

I wanted to know whether switching universes remained understandable, whether the controls stayed responsive, and whether the game still had something meaningful to investigate after the initial visual impression wore off.

The result is still a demo, not a finished commercial game. Publishing it was useful precisely because the boundary is now visible. I can ask for feedback on the actual browser build instead of showing screenshots and guessing how it feels.

Be specific about generated content

Some of the project's content was produced with generative AI tools, then assembled, edited, and tested as an interactive game. I included that disclosure on the itch.io page.

For me, “AI-generated” is not a substitute for testing. The useful question is still whether a player can load the page, understand the controls, move through the available spaces, refresh, and continue without hidden state breaking the experience.

If you want to try the current browser build and tell me where it breaks, it is here: ENTROPY: The Critical Loop on itch.io.

I am especially interested in iframe focus problems, loading failures, and anything that behaves differently after a refresh.