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.