The final release check should examine the exported artifact in its intended environment. A game working in the editor or on a development server does not establish that its uploaded archive has the right assets, configuration, and lifecycle behavior. Start by identifying exactly what you plan to submit.
This checklist is a practical review structure for Unity Web and JavaScript or TypeScript browser games. It complements a portal’s current documentation. It cannot establish acceptance by a platform, and one platform’s required integration should never be assumed to apply to another.
/01
Name the artifact, platform, and launch stage
Record the source revision, export settings, artifact hash, and intended destination. Include the engine or framework version and the provider variant. This gives every screenshot, log, and test result an unambiguous subject. If the export changes after testing, treat the replacement as a new candidate and rerun the checks affected by that change.
Read the destination’s requirements for the actual launch stage. For example, CrazyGames documents different integration expectations for Basic and Full Launch; its current overview says the SDK is optional in Basic Launch and required for Full Launch. Poki publishes its own technical and gameplay requirements. Keep these requirements in separate checklists and verify the current documents again before submission.
/02
Load the exported package from a clean start
Serve the candidate with the intended hosting behavior and inspect the requests made during first load. Look for missing files, unexpected redirects, incorrect content types, failed compressed resources, and dependencies left on a developer machine. A repeat visit with cached files is a separate scenario; keep the first-visit test intact rather than allowing a successful warm load to conceal a broken package.
Reach the first usable game state using the candidate alone. Confirm that the visible loading UI matches what remains to be loaded and that failure gives the player a recoverable next step. Record every external dependency and check whether the destination permits it. Poki’s external-resource rules, for instance, require explicit attention to requests beyond the submitted build. Do not infer permission from success on your own server.
/03
Check controls inside the real container
Test the game in the portal’s preview or an appropriate local embedding harness, not only as a full browser tab. Confirm focus, pointer coordinates, touch behavior, viewport changes, and the transition between menus and gameplay. Verify that the surrounding page remains usable while the game receives the input it needs.
Use the input methods you claim to support. Resize while a menu is open, rotate a touch device where applicable, and return after switching tabs. Check that the game does not retain a stale held key or restart an action unexpectedly. Save the exact sequence for any failure so it can be rerun after a fix. Do not classify an untested device family as passing because one desktop browser worked.
/04
Verify audio, pause, and provider transitions together
Browsers can block audible autoplay; MDN documents how this affects media elements and Web Audio. Test the first deliberate user interaction, the mute control, backgrounding, and a return to play. A fresh browser context can reveal behavior hidden by the permissions or interaction history of a developer’s usual profile.
Where the chosen integration includes advertising or other platform interruptions, exercise the documented success, unavailable, and failure paths. Check gameplay pause, audio state, and return behavior as one sequence. For a reward, verify the provider’s documented completion condition and the game’s protection against applying it twice. Use only APIs confirmed in the current official documentation or in the developer’s own authorized partner materials.
/05
Exercise saved progress and unavailable storage
Create progress, reload, and verify that the next session can use it. Then test the supported recovery cases: unavailable storage, an older save format, a missing resource, or an interrupted request. Keep these tests confined to disposable accounts and data. A release checklist should make it easy to reproduce a failure without risking a player’s existing progress.
MDN’s Web Storage documentation explains that storage is scoped by origin and that sessionStorage and localStorage have different lifetimes. An embedded deployment can therefore expose assumptions that were invisible during local testing. Make save success and fallback behavior truthful in the UI. If persistence is unavailable, do not show a durable-save confirmation simply because the current in-memory state looks correct.
/06
Attach evidence to the release decision
Finish with a concise result for every required check: passed, failed, or unverified. Include the artifact identifier, device and browser coverage, evidence location, and remaining limitations. Keep a failed requirement attached to its consequence and owner. A long list of completed low-risk checks cannot compensate for an unresolved failure that prevents the game from starting or preserves the wrong save data.
An AI agent can help assemble this report and trace a failure back to the relevant code, but it should not manufacture a successful portal preview or treat an absent SDK reference as permission to invent calls. Submit only after the responsible person has the actual evidence needed for the decision. Retain the previously accepted artifact and a recovery plan, then verify the deployed result once the platform makes it available.
- Match submission metadata and control instructions to what this exact candidate supports.
- Keep provider credentials and private player data out of the archive and the review evidence.
- Recheck the uploaded candidate instead of assuming that successful local packaging proves the remote result.
Keep this in mind
Key takeaways
- Tie every release result to a specific exported artifact and destination, including the platform’s launch stage.
- Inspect fresh loading, embedded input, audio transitions, and saved progress in the deployment context.
- Treat unavailable documentation and untested paths as explicit gaps rather than successful checks.
- Preserve the previous working artifact and verify the platform-served result after release.
Sources & further reading
Consult the source documentation for the version and platform you are working with.