> For the complete documentation index, see [llms.txt](https://wiki.playgama.com/playgama/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.playgama.com/playgama/mcp/game-checklist.md).

# Game checklist

What a game needs before it goes up on playgama.ai — the required Bridge steps in the order you do them, build constraints, and the tips that save the most time.

The list below is in the order you work through it. Everything numbered is required; the tips at the end are not, but each one removes a problem people hit repeatedly.

## Checklist

1. Connect and initialize the Bridge — nothing else works until initialization finishes.
2. English localization is required. Use English as the default and fallback language. If the game supports multiple languages, automatically select the supported language reported by `platform.language` after Bridge initialization.so
3. If manual language selection is available, make it accessible even when the player does not understand the current language. Use recognizable settings or language icons, and display language names in their own languages, such as English or Español.
4. Save and load progress only through Storage, never through `localStorage` directly.
5. Save and load everything in a single call — pass an array of keys at once, instead of one key per call.
6. Verify that saved progress is restored after reloading the game. Games with levels or story progression must save progress; endless and high-score games must save the player's best score. 
7. Rotating the device or watching an ad must not reset progress.
8. Subscribe to the pause and audio state events. Verify that gameplay and sound pause during full-screen ads, and that sound stops when the game is in the background. After returning, the game must resume correctly without losing progress.
9. Send `platform.sendMessage('game_ready')` when the first playable frame is ready. Send it only after loading is complete and the player can actually interact with the game. Never send it while the loading screen is still displayed.
10. Integrate at least one working ad format: interstitial or rewarded ads.
11. Ads and payments go through the Bridge only, with no third-party advertisers.
12. Show interstitials at natural pauses — level transitions and game over.
13. An ad block never appears under the player's finger or cursor, on top of what they were about to tap.
14. Rewarded ads are opt-in: a clear button that says an ad is coming and what it gives; the reward is an extra bonus rather than a condition for continuing; never offer "+1 life" every time the player loses one.
15. Grant the reward only after the Bridge confirms successful completion of the rewarded ad. The reward must match what the button promises. If the ad is cancelled or fails, do not grant the reward, and keep the game playable.
16. Load no external resources — everything the game needs ships inside the build, and only the Bridge itself comes from the Playgama CDN.
17. The whole archive is 300 MB or less.
18. `index.html` sits at the root of the archive, and file and folder names use Latin characters only.
19. No external analytics — neither GA4 nor any equivalent; requests to them may be blocked. Send game events through the Bridge [analytics module](/playgama/bridge-sdk/api/analytics.md) instead (`analytics.send`, Bridge 2.3.0 or newer).
20. Launching the game requires no registration or sign-in with an external service.
21. If authentication is implemented, verify that it works correctly and does not prevent players from entering the game because of errors or a stuck login flow.
22. Check that interface elements do not overlap and that the layout holds at every screen size — in both portrait and landscape if the game supports both orientations, otherwise in the one it supports.
23. No browser page scrollbar; custom scrolling inside the game is fine.
24. Every popup has a close button or a cross.
25. If mobile support is declared, touch controls must be responsive. Long presses inside the game field must not trigger text selection or browser context menus.
26. On mobile: full screen during gameplay, elements that do not deform when the orientation or the available area changes, and a keyboard that opens by itself when an input field is tapped.
27. On desktop the game field stretches to the edges of the available area, but no further than a 2:1 ratio — on an ultra-wide or very short window, leave margins rather than turn the game into a strip.
28. Check font sizes: text stays readable at every screen size.
29. If the game has sound, provide a mute control. Verify that sound stops during full-screen ads and while the game is in the background.
30. If the game has multiplayer, get the host whitelisted — without it multiplayer will not work on playgama.ai.
31. Check that the game has both mobile and desktop controls, and that both of them work.
32. Play the game through: levels can be completed, and nothing freezes anywhere.
33. Test screen rotation, window resizing, long presses, gestures, switching away from and returning to the browser, and opening and closing ads. These actions must not cause crashes, freezes, technical error messages, or broken controls.
34. Do not restrict the game's operation to a specific domain or URL.
35. Do not include external links to social networks or third-party websites inside the game.
36. After uploading to Playgama, open the published link with Playwright and check that everything works there the same way.

## Tips

Not required, but each one removes a familiar problem.

### Assets

* Take assets from free CC0 libraries, and download them before you start rather than asking the agent to look for them along the way.
* Do not synthesize sound procedurally — use ready-made free sound packs. It is faster and it sounds far better.
* Ship audio compressed (ogg/mp3, not wav). The 300 MB limit is not the constraint here; load time is.
* Prefer asset packs painted from one shared palette texture: the whole pack lives on a single material and batches into one draw call, while a model carrying its own 2K texture costs a draw call of its own. The art choice is the performance choice.
* Script the asset pipeline into one command instead of optimizing by hand: lossless glTF compression cuts size several times over with no visual change, and the originals stay in a folder that never ships. Do not strip node names to save bytes — if the game finds parts of a model by name, that silently breaks everything.

### Performance

* Budget draw calls, not polygons. The bottleneck is usually the number of meshes rather than the geometry: a scene with tens of thousands of triangles can run worse than one twice as heavy but merged into a few meshes.
* Cap the frame rate at 60 on touch devices. A 120 Hz panel runs the loop twice as often, heats up and starts throttling.
* Do not judge performance by the first 5–10 seconds — that is shader compilation and the first meshes being built, and the same phones reach a normal frame rate afterwards. Automatic quality downgrade must not run inside that window.
* Ask for numbers, not adjectives. While JS time per frame is above 10 ms, touching graphics settings is pointless.

### Process

* Describe the world as data rather than as content: a map of a few lines with one character per block type is edited with a single character, and an agent will rewrite it twenty times in a session — it will never hand-place hundreds of objects once.
* Give the agent eyes: a few debug hooks on a global object, so a headless browser can drive the game, switch quality presets and report FPS, draw calls and triangles. An agent that only reads code guesses; one that can play the game measures.
* Run the UI through a fixed matrix of sizes instead of eyeballing it: 360×640, 390×844 portrait, 915×412 landscape, 1280×720, 2560×1440.
* Look at every screenshot yourself before calling a check passed.

***

Points 1–9 are the required steps from the [Bridge SDK](/playgama/bridge-sdk/api.md) documentation. The rest are build and quality requirements.