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 to understand backups, memory and interrupted usage.
Need a hand with this workflow? Find help or contact support.