# Create, review & test

Open the [browser creator](/studio/create) to work on a game. New projects start with an empty canvas. For the first complete walkthrough, follow [your first game](/docs/creator-quickstart).

## Give the builder a focused task

Describe the player's action, success or failure conditions, input controls and style. In an existing game, specify what must stay unchanged. For example:

```text
Keep the current movement and scoring. Add a shield pickup that lasts
five seconds, with a visible countdown and a touch-friendly restart button.
```

Choose your available AI connection and inspect **Build options** before sending. Discussion can remain read-only until you approve a current plan; a direct request to build follows the build workflow. Read-only AI answers can still use provider allowance.

## Understand the candidate

The builder edits a candidate tied to the project, compiles supported source, gathers preview observations and requests an independent review. A guided result saves the exact accepted candidate after its checks. A failure or paused attempt can retain unfinished files without replacing the saved game.

Manual source edits require **Save files**. Terminal-produced or recovered files retain explicit review/check/keep controls. Resolve unsaved changes or another tab's updates before resuming a candidate. See [how creation works](/docs/how-creation-works).

## Play through the actual rules

Check startup and runtime observations, then test the game yourself:

- Can a new player understand the controls and start?
- Do movement, collisions, timing and scoring follow the intended rules?
- Do win/loss and restart work without leaving stale state?
- Are keyboard and touch controls usable at your target screen sizes?
- Do imported assets and sounds appear at the right time?

A short automated probe cannot prove every rule or device works. Game-reported state and observed browser behavior are different kinds of evidence; neither guarantees production quality.

## Iterate without losing the thread

Follow-up requests continue the current game and its retained unfinished work. You can queue changes while a build runs. Questions, failures, Stop or context changes can hold the queue until you explicitly resume it.

Use **Memory & docs** to retain important game rules and decisions. Export a playable copy and a private restart record as needed. [Projects and recovery](/docs/projects-and-recovery) explains which data each backup preserves.