Google Playground Export: Check the Game ZIP Before Handoff

Inspect the package before trusting the playable preview

For a Google Playground game handoff, save the original ZIP, check its paths and statically declared resources, then test the actual game in its intended hosting environment. Keep dependency findings separate from gameplay and rights review. The downloadable lab below helps with the file check; it does not execute Playground, run your game or certify an export.

Google describes Playground as an experimental, text-driven game creator. Unity’s October 7, 2026 announcement distinguishes that launch from the expanded Unity Spark experience planned for later in the year. A browser-game ZIP should not be assumed to be a Unity Editor project. This guide checks package structure, not an undocumented conversion path.[2][3]

Check access, then preserve the original export

As checked on October 11, Google’s Help Center limits Playground to US users aged 18 or over. Free-tier creation access is rolling out through a waitlist; a Google One AI plan offers immediate creation access. Availability and quotas can change, so confirm eligibility before planning work around it.[1]

The documented export path is Your Games → Edit → Creation Studio → Export (Download Zip). Google says the archive includes HTML, JavaScript, CSS and generated assets. We inspected that documentation, not a signed-in export. The lab’s archives are independently authored examples.[1]

Keep the download unchanged and record its SHA-256 hash, export date and the version you intended to hand over. Put experiments in a separate working copy. If someone reports a missing texture, a specific archive hash is a better starting point than “the latest game.” Do not rename individual resources until you understand their references.

Ask three small questions about the ZIP

• Does the archive have an identifiable entry page and a plausible file layout? Record any wrapper directory instead of assuming every export has the same root.
• Do statically declared local HTML resources resolve to actual entries, with matching spelling and case? A reference to a file is not the file itself.
• Which references point outside the archive? Record each dependency and its purpose before assuming the package is self-contained.

Python’s zipfile documentation warns against extracting untrusted archives without inspection. Our tool lists and reads selected entries in memory; it does not unpack or execute them. It applies deliberately conservative path and size rules. A rejected archive needs investigation, not an automatic instruction to disable the checks.[5]

Use the README’s command to inspect the authored examples first, then a copy of your own archive if it fits the tool’s documented limits. Read errors and warnings separately. A missing file is a packaging finding; an external URL is a dependency to review, not proof that the URL is malicious. A zero-error result means only that these static checks found no error.

Use deliberate failures to understand the report

The lab includes a small original browser-game fixture and altered archives with missing or external resources. Its generated report records what the checker observed. These are controlled examples for learning the audit, not a sample of Playground’s output quality or a claimed failure rate.

In the authored fixtures, 01-complete.zip has no static errors or warnings; 02-missing-texture.zip reports one missing local file, assets/target.svg; and 03-external-resource.zip reports one external-resource warning. The last case is not fetched. These outcomes describe three deliberately constructed archives, not a measured rate of problems in real exports.

Change one reference in the fixture builder and regenerate the archives to see whether the finding changes as expected. Keep the unmodified report for comparison. The included tests exercise both accepted and rejected inputs. A separate handoff worksheet leaves observed gameplay results blank until you actually run those checks.

Static HTML parsing cannot follow every dependency a browser may request. JavaScript can construct URLs at runtime, stylesheets can load images or fonts, and platform services may be required after the first screen. Treat unsupported reference forms and the tool’s own limits as unfinished review work. It is not a malware scanner, a full browser URL resolver or proof of offline readiness.

Test behavior after the file check

Once you have reviewed the code and chosen an appropriate test environment, exercise the exported build rather than relying only on its hosted preview. Use the same short route on each revision: start, perform the core action, reach success or failure, restart, and repeat. Record the exact build, browser and input method. This is a proposed acceptance routine, not a test we ran on Playground.

• Verify the intended keyboard and touch controls independently. A visible button does not establish that it receives input or remains reachable on a small screen.
• Check restart state: score, timers, collected items and overlays should match your design. Replay after both winning and losing.
• Inspect browser network and console output while exercising later screens. The opening screen can work while a delayed resource or remote service fails.
• State whether accounts, leaderboards or network access are required. Do not silently remove a dependency and call the altered behavior equivalent.

Exporting and publishing are different actions. Google says new creations start as drafts, while edits to a published game remain draft changes until republished. Record whether your recipient is reviewing a ZIP, the current public version or an unpublished revision. A share link alone does not identify the bytes in your handoff.[1]

Keep file possession separate from asset permissions

Google’s September 20, 2026 additional terms say it does not claim ownership of Your Games, while retaining rights in Google-provided features, services and assets. They also restrict unauthorized third-party intellectual property and removal of AI-origin labels or metadata. A successful download is not a blanket commercial-use clearance. Review the applicable terms and each asset’s provenance for your intended use.[4]

For a separate game project needing directional character animation, Goblin3D’s public Sprite Generator offers four- or eight-direction sheets and sprite exports. Plan an asset handoff with filenames, dimensions and animation intent, then test it in the destination game. This is not a claim of direct Playground import support.[6]

The practical finish line is a handoff another person can inspect: the unchanged export, a dependency report, a short observed playtest record and the relevant asset permissions. Keep unknowns visible. A working preview is a useful milestone; the package still needs its own review.