# Prepare a Poki Build With a Submission Preflight Prepare a specific Poki candidate build with current requirements, Inspector evidence, lifecycle checks, and a clear release decision without guessed SDK calls. Canonical URL: https://gameskit.ai/blog/poki-game-submission-preflight Last updated: 2026-10-29 [Publishing](https://gameskit.ai/blog#publishing) Prepare a specific Poki candidate build with current requirements, Inspector evidence, lifecycle checks, and a clear release decision without guessed SDK calls. [AI Games Kit Editorial](https://gameskit.ai/blog#editorial) Published October 18, 2026 · Updated October 29, 2026 3 min read [← All guides](https://gameskit.ai/blog) A submission preflight connects a particular build to evidence that it meets the platform's current expectations. Start with the exported files you intend to upload, then test the player journeys those files provide. For this guide, imagine a small level-based arcade game with pause, retry, saved progress, and an optional rewarded continue. The goal is an inspectable candidate, with remaining issues attached to specific requirements. /01 ## Freeze the candidate and requirement references Record the source revision, engine version, build configuration, and a hash or manifest for the exported package. Give the candidate a clear identifier so a recording, an Inspector session, and an uploaded version can be matched. Keep development toggles out of the intended release configuration. If the package changes during testing, identify it as a new candidate and repeat the affected checks. Read Poki's current requirements and the documentation for the integration you actually use. Record the pages and review date in the release notes. Confirm the intended distribution with the project's publishing owner before preparing another portal variant. Poki describes its platform as curated; completing a technical checklist is evidence about your build, not a promise that a submission will be selected or released. /02 ## Inspect the real player flow Poki Inspector provides QA modules and an event log for reviewing a game's integration. Use the current official tool with the actual candidate, then keep the resulting observations alongside that candidate's identifier. A green test in a separate sample project does not establish that your exported game wires the same lifecycle correctly. Review warnings and explain any unresolved finding instead of marking it passed by assumption. Walk through first load, first player action, pause, resume, level completion, retry, and return to a menu. For the arcade example, record when gameplay is active and when it has stopped at each transition. Compare the observed event sequence with the current SDK documentation. Let the engine-specific integration owner implement corrections; do not invent event names, argument shapes, or callbacks from memory. /03 ## Test interruption and fallback paths Exercise the rewarded-continue flow through the documented test facilities, including every outcome supported by the integration. Before testing, define the game-owned rule: an eligible success can grant one continue; a canceled or unsuccessful attempt must leave a coherent playable path. Trace the reward identifier and level state so duplicate completion handling cannot hide behind a visually correct animation. Check audio and input through pause, an advertisement interruption where applicable, tab return, and a device rotation. Inspect what happens when progress cannot be saved and when an optional service is unavailable. These are candidate-specific tests, not a replacement for Poki's policies. Consult the current requirements for the expected platform behavior and preserve evidence from the actual embedded game rather than only its local standalone page. /04 ## Review the package and make the decision explicit Inspect the candidate's network requests and explain every external dependency against the current external-resources policy. Check missing files, filename casing, required control schemes, and layout in the supported device modes. The arcade game's retry button must remain reachable after a small-screen transition, and its saved stage must reopen coherently after a fresh load. Keep screenshots and failure sequences tied to the same exported package. Use an acceptance sheet with requirement, evidence, result, and owner. Mark the candidate ready for submission only when required checks have evidence, known failures are resolved or explicitly accepted by the appropriate owner, and the package matches what was tested. Include a short route to reproduce the most fragile flow. After any subsequent fix, repeat that route and the neighboring transitions before replacing the submission candidate. Keep this in mind ## Key takeaways - Tie every check to an exact exported candidate and current official requirement reference. - Use Inspector evidence to verify the game's actual lifecycle and interruption paths. - Treat submission readiness as a documented decision, with no implied platform acceptance. ## Sources & further reading Consult the source documentation for the version and platform you are working with. - [Poki: Requirements](https://developers.poki.com/guide/requirements-quality) - [Poki: Inspector](https://developers.poki.com/guide/inspector) - [Poki: Working with Poki](https://developers.poki.com/guide/working-with-poki) Inside the AI Games Kit ## Workflows for your next step - [Poki SDK Integration](https://gameskit.ai/#roster) - [Web Portal Readiness Check](https://gameskit.ai/#roster) - [Game Release Regression Check](https://gameskit.ai/#roster) Explore these agents and skills in the [Games Kit roster](https://gameskit.ai/#roster). Keep building ## More from the field notes [All guides](https://gameskit.ai/blog) [Publishing](https://gameskit.ai/blog/game-post-release-regression-triage) ### Triage a Game Regression After Release Turn a post-release game bug into a reproducible incident with version evidence, player-impact priorities, a bounded fix, and recovery checks. October 20, 2026 3 min read Read guide [Publishing](https://gameskit.ai/blog/crazygames-launch-preflight) ### A CrazyGames Preflight for the Right Launch Stage Build a CrazyGames release checklist around the correct launch stage, tested export, platform preview, and concrete evidence for unresolved integration risks. October 19, 2026 3 min read Read guide [Publishing](https://gameskit.ai/blog/web-game-release-checklist) ### A Web Game Release Checklist for the Build You Actually Submit Check a browser-game release artifact for loading, input, audio, saves, portal integration, and recovery before submitting the exact tested build. September 26, 2026 5 min read Read guide Put the workflow to work ## Give your next game a focused team. Explore the AI Games Kit’s agents and skills for Unity and browser-game development, from debugging and playtesting to release preparation. [Explore the AI Games Kit](https://gameskit.ai/#pricing) [See how to use it](https://gameskit.ai/start) --- Markdown version of https://gameskit.ai/blog/poki-game-submission-preflight, from AI Games Kit (https://gameskit.ai). Site index: https://gameskit.ai/llms.txt · Full text: https://gameskit.ai/llms-full.txt · AI usage policy: https://gameskit.ai/ai.txt