What you’ll leave with
A tiny original game whose win condition, controls and restart behavior can be checked before you add visual complexity.
Before you begin. Access to Playground. Google’s October 7 announcement describes an early US experiment for adults, with creation access depending on subscription rollout. Check access before starting; this guide did not generate or play a game.
What the documentation establishes
Google announced Playground on October 7 as an experimental browser game-creation platform with conversational editing and private or shared games. Source ↗
The walkthrough below is an original worked exercise. We have not independently tested this product’s performance.
A convincing screenshot is not a playable game. Movement, collisions, scoring and restarting have to agree with one another. Generative tools can get you to something visible quickly, which makes it tempting to add characters and worlds before checking the simplest rule.
Build a small original game called Parcel Dash: move a courier to a parcel, then bring it to a depot. The exercise below supplies a brief, an explicit state model and a playtest. It uses invented art and rules, avoiding the distraction of recreating a commercial game’s identity. These are proposed instructions and expected results, not a claim that a working build was produced during this research.
1. Define the first playable version
Use a single screen, one parcel, one depot and a thirty-second timer. The courier should move on a flat board. Leave enemies, upgrades, procedural levels and online play for later. Every extra system adds interactions that can hide a basic scoring error.
Google documents conversational creation, immediate testing, private games and optional sharing in Playground. Its announcement describes Unity Spark integration as forthcoming. This exercise stays inside the documented browser workflow; it does not assume a native export or a production game-engine handoff.
Write down the success condition before the prompt: the player collects the parcel, reaches the depot while carrying it, and wins before the timer expires. A screenshot of the courier standing on the depot is insufficient; carrying state is what makes the rule testable.
2. Use a prompt with observable rules
Create Parcel Dash, an original single-screen delivery game.
Use simple geometric placeholder art with clearly labelled Parcel and Depot.
Arrow keys move the courier. Provide visible on-screen direction buttons
for touch; the layout must fit a narrow phone screen.
Start with a visible Start button. The timer begins only after Start.
Collecting the one parcel changes the courier to a carrying state.
Entering the depot wins only while carrying. Stop the timer on a win.
If 30 seconds elapse first, show a loss and stop movement.
A Restart button resets position, parcel, timer and outcome.
Show a short instruction and remaining seconds.
No accounts, purchases, external assets or multiplayer for this exercise.Generate this first version and immediately try the core route. Keep a note of what the tool actually created, including missing touch controls or a timer that starts too early. Do not describe unsupported controls as working just because they appear in your request.
Save the initial prompt and capture the first result in whatever form your account provides. If revision history is not available, keep screenshots and a short description locally. You need a way to compare behavior after edits; no specific versioning feature is assumed here.
3. Check transitions, not just appearance
| Current state | Event | Required next state |
|---|---|---|
| Ready | Start pressed | Playing; timer 30; parcel visible |
| Playing, empty-handed | Courier enters depot | Still playing; no win |
| Playing, empty-handed | Courier touches parcel | Playing, carrying; parcel removed |
| Playing, carrying | Courier enters depot before expiry | Won; timer and movement stopped |
| Playing | Time expires | Lost; movement stopped |
| Won or lost | Restart pressed | Ready; original positions and timer restored |
Play the empty-handed route first. If the depot awards a win, the visual layout is disguising a missing state check. Then collect the parcel and take a deliberately indirect route. Confirm that leaving and reentering the parcel location cannot create a second parcel or award a second score.
Test expiry without moving at all. A timer that shows zero while movement continues has not implemented the loss state. Finally restart after both a win and a loss. Restart bugs often leave invisible carrying state behind, so test the depot immediately after restarting.
4. Change one failing behavior at a time
Observed failure: entering Depot before collecting Parcel currently wins.
Expected: an empty-handed courier stays in the playing state.
Please change only the win-condition check. Keep layout, controls,
timer duration and art unchanged. Explain the state that gates the win.
After the change I will retest empty-handed entry, carrying entry,
expiry and restart. Do not add new mechanics.Replace the observed failure with what you actually see. A good revision request names the trigger and expected behavior. Asking for more polish at this point may produce different art while leaving the rule broken.
After each fix, replay all six transitions from the table. Small generated changes can affect nearby behavior. If a repair introduces another failure, keep both observations and ask for the smallest change that restores the contract. Stop after a few attempts and reduce the mechanic if the tool cannot maintain the state consistently.
5. Give somebody a short, specific playtest
Ask one person to play without a spoken explanation. Observe whether they find Start, understand the parcel goal and recognize a win. Then ask them to restart and intentionally lose. Record what they did rather than interpreting every pause as confusion.
On a phone, check whether direction buttons overlap the board, whether text remains readable, and whether the browser scrolls instead of moving the courier. On a keyboard, check that one held key does not get stuck after a loss or restart. These are checks to perform, not claims that the generated game already supports every input correctly.
Build label/date:
Device and input:
Empty-handed depot entry: pass / fail / not tested
Parcel collection visible: pass / fail / not tested
Correct carrying win: pass / fail / not tested
Timer expiry stops play: pass / fail / not tested
Restart clears all state: pass / fail / not tested
Player understood goal without explanation: yes / no
Observed failure and exact steps:
Next single change:6. Decide what deserves another iteration
When the mechanic works, add one visual improvement that supports play: a carrying indicator, a clearer depot outline or feedback when the parcel is collected. Retest after that change. Visual feedback should help the player understand state, not hide it behind an effect.
Keep the game private while checking it. If you choose to share later, use the account’s current sharing controls and verify what the link exposes. This article does not publish a game for you or promise that a generated result will pass platform review.
The final deliverable is a brief, a tested build and a list of known limits. If the tool cannot deliver dependable controls, preserve the prompt, state table and failure receipts as a handoff to another implementation path. The work remains useful because you have made the behavior precise instead of collecting attractive but unexplained screenshots.
Sources & next steps
- Google introduces Playground ↗
Product scope/access and planned Unity integration. Parcel Dash, state table and prompts are original. No gameplay test performed.
Guide history
Revisions preserve the original instructions. A source recheck alone does not create a new revision.
Revision 1 · Audit-discovered creative tool: original Parcel Dash game brief, six-state transition checklist, targeted repair prompt and playtest receipt. No game generated or executed.
Continue learning
Creative work · 8 min read
ArtCraft: plan three consistent shots before generating a film →
A practical scene-planning exercise with an asset sheet, shot brief, controlled revisions, and a continuity review. Discovered through GitHub’s changing project feed.
Updated 2026-10-16