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.