# 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. Canonical URL: https://gameskit.ai/blog/crazygames-launch-preflight Last updated: 2026-10-29 [Publishing](https://gameskit.ai/blog#publishing) Build a CrazyGames release checklist around the correct launch stage, tested export, platform preview, and concrete evidence for unresolved integration risks. [AI Games Kit Editorial](https://gameskit.ai/blog#editorial) Published October 19, 2026 · Updated October 29, 2026 3 min read [← All guides](https://gameskit.ai/blog) A CrazyGames release checklist should begin with the launch stage. Otherwise a team can spend time integrating an unavailable feature while overlooking a basic packaging failure. This guide uses a fictional driving game with saved vehicle unlocks and short races. The practical outcome is a candidate package with clear evidence for loading, control, progress, and the platform features appropriate to its current stage. /01 ## Identify the launch stage and its requirements The current CrazyGames documentation distinguishes Basic Launch from Full Launch. It describes the SDK as optional in Basic Launch, with monetization unavailable there, and requires the integration requirements for a selected Full Launch. Confirm the project's actual stage in the developer workflow and read the corresponding requirements. Record that decision before assigning SDK or monetization work. Create a short requirement map covering technical limits, gameplay, metadata, and any applicable account or multiplayer features. Link each item to the current official page rather than copying a remembered limit into a permanent project constant. Keep requirements distinct from recommended quality improvements. A recommendation may still be valuable, but the team should know which finding prevents submission and which is a planned refinement. /02 ## Test the exported package from a clean entry Produce a named candidate with a source revision, build settings, and package manifest. Start it through the platform's preview workflow as well as your local checks. CrazyGames documents its Developer Portal preview as a place to run the game in its platform context and inspect implemented SDK features. Preserve the version identifier so the preview evidence can be matched to the submitted files. For the driving game, begin with a new disposable profile and reach the first controllable race. Record missing assets, confusing entry screens, incorrect controls, and loading failures. Then repeat with an existing profile that has unlocked a vehicle. Check supported window sizes and touch layouts, including a resize during the race. The tested outcome is a usable game journey, not merely an HTML page returning successfully. /03 ## Exercise only the features actually implemented List the platform interactions present in this candidate and assign each a game-owned state transition. For a Full Launch candidate with ads, document the pause, audio, resume, and optional reward behavior before checking the provider integration. For an account-enabled game, document how the selected profile and saved unlocks behave. Use official SDK guidance for the exact calls and callback semantics. Test interruption and failure at the boundaries you own. For example, a player requesting an optional reward must not receive it twice because a completion path runs twice, and a denied or failed attempt must not leave the race permanently paused. Use supported test facilities and disposable data. Do not assume that a local mock proves real platform behavior; mark the provider preview checks separately. /04 ## Close the evidence loop before uploading Verify that the description, controls, and cover assets describe this candidate accurately. A touch-only screenshot does not explain a keyboard-only implementation. Check external requests and optional dependencies against the current technical rules. If the project keeps multiple portal exports, inspect the package for an unintended provider configuration or an outgoing link inherited from another variant before attributing every failure to the new integration. Make the acceptance decision from a concise table: requirement, reproduction route, observed result, evidence, and owner. The driving candidate passes when the required stage-specific checks are satisfied, first play works, existing progress remains coherent, and implemented platform flows reach their documented outcomes. Preserve unresolved questions for the platform or project owner. Recheck the latest official guidance before submission, since a saved checklist cannot establish that a changing policy is still current. Keep this in mind ## Key takeaways - Confirm Basic or Full Launch before scoping integration and monetization work. - Match preview evidence, packaging checks, and metadata to one identifiable candidate. - Verify real platform flows separately from mocks and keep unresolved requirements explicit. ## Sources & further reading Consult the source documentation for the version and platform you are working with. - [CrazyGames: Requirements introduction](https://docs.crazygames.com/requirements/intro/) - [CrazyGames: Technical requirements](https://docs.crazygames.com/requirements/technical/) - [CrazyGames: Basic Launch guide](https://docs.crazygames.com/resources/basic-launch-metrics/) Inside the AI Games Kit ## Workflows for your next step - [CrazyGames 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/poki-game-submission-preflight) ### 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. October 18, 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/crazygames-launch-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