# How creation works

The creator keeps a conversation, editable files and a playable preview together. It uses your current project and requirements when deciding what to build, then checks the candidate before accepting a guided result.

## Discuss, then approve

Ordinary project questions use a read-only conversation path. You can explore a mechanic, ask about available resources or clarify an approach without authorizing file changes. AI-backed answers can still use provider allowance; read-only does not mean every answer is free.

An explicit build request starts creation. If the assistant first proposes a plan, your fresh approval starts that plan with your actual answers and current project context. A stale offer, quoted approval or queued “yes” cannot automatically authorize a different later plan.

## Build against the current game

The builder reads relevant files and project memory, chooses an appropriate game foundation, edits a candidate and runs the available checks. Browser games can use Canvas or Three.js, with supported assets included in the project.

Follow-up requests continue the current game's unfinished candidate where one exists. Changed files, limits, account state and prior spending remain relevant. EoC does not silently start a new game to escape a failed build. Use **New game** to create another project.

## Check and review

Compilation and preview checks look for supported startup, runtime and gameplay observations. The creator also requests an independent review of the candidate against the task. “Independent” describes a separate review step; it is not a human security audit or a guarantee of game quality.

Only the exact candidate associated with successful checks and an accepted guided review can be saved through that workflow. If a required observation is missing, the check must not present it as proven. Failures may lead to a bounded repair attempt, a question or a pause.

Playtesting remains essential. Test rules, difficulty, input, sound, end states and restart on your target devices. Automated observations cannot establish every mechanic, performance characteristic or browser combination.

## Know when work is saved

| Work you are doing | How it is kept |
| --- | --- |
| Successful guided build | The accepted, checked candidate is saved automatically |
| Manual file or asset edits | Review the draft and explicitly use **Save files** |
| Recovered or terminal-produced work | Follow the review, checking and keep controls shown |
| Interrupted build | An unfinished candidate can be retained for continuation; it is distinct from the saved game |

Unsaved edits or changes from another tab can hold a save or continuation. Resolve the visible conflict instead of assuming the older version is current.

## Queue your next changes

You can type and queue follow-ups while a build runs, then edit or remove waiting messages. Each retains its chosen AI and limits. An uninterrupted accepted save can advance the queue in order. A question, failed review, error, Stop, or changed connection/context holds waiting work. **Send next** explicitly resumes it under the displayed settings. Reloading restores waiting intent without automatically starting paid requests.

Continue with [projects and recovery](/docs/projects-and-recovery) to understand backups, memory and interrupted usage.