What's per scene and what the project shares

Scenes in a project each have their own entities, but they share script files and assets. So editing a shared script in one scene can change the game in another scene. This page explains what is per scene and what is shared, and describes observed cases where AI GAME BUILDER edited a shared script and broke another scene, along with how to handle it.

How the five units contain one another is explained first in Projects, scenes, entities, components, and assets.

Per-scene data and shared data

Of the two columns, what we confirmed in tests is: script files are shared (the cases where another scene broke), uploaded files and the conversation list remain visible when you switch scenes, and the material and entity-value test below. On 2026-10-30, we duplicated a scene, then changed the color of the material Orange to blue in the original scene; when we opened the duplicate, the entities using that material also appeared blue. Conversely, changing Box's Position X to 2 in the duplicate left the original scene's Box at 0 (1 run each). Whether script attribute values are stored separately per scene is inferred from the engine's structure. Pending Test changing the same script attribute value in two scenes

Game rules span both columns. The code that implements the rules lives in script files, so the project shares it. Which entity that code is attached to, and what its attribute values are, are likely separate for each scene.

How shared data shows up on screen

• ASSETS also shows files used by other scenes. Even a file that isn't attached to any entity in the current scene may be in use by an entity in another scene.
• The AI GAME BUILDER conversation list stays the same when you switch scenes. Conversations from other scenes also appear in the current scene's conversation list.
• When you publish with Publish / Download, only the currently open scene is checked in the SCENES field by default.

Cases where a shared script broke another scene

There have been cases where AI GAME BUILDER, given a request about the currently open scene, found scripts already in the project and reused or edited them. In one check, the AI recognized livesManager.js, created earlier for another scene, and reused it without creating a new file. If another scene's entities also use the edited script, that scene runs with the changed code.

Test conditions

We created 7 scenes in the same project and, for each scene, built a star-collecting game in a new conversation using the same prompt. For some scenes, we followed up with fix prompts. Afterward, we reopened the earlier scenes and ran them with Launch.

Observed results

In the 7-scene test, another scene broke in 2 cases, and a name collided in 1 case.

Other scenes don't always break. In one check, the AI edited livesManager.js, which it shares with another scene, but that scene's game still worked. In a different project, after a new game was built in a second scene, the game in the default scene still worked (1 run). You can't know whether an edit to a shared script suits other scenes until you run them.

How to handle it

When working within one project

• Use the AI only in the scene of the game you're making. If you have the AI work again in a practice scene, the game you're making may change through shared scripts.
• When you build a new game in a new scene, start in a new conversation in the AI panel. The project shares the conversation list, so earlier conversations contain content about other scenes. All of the tests above used a new conversation for each scene.
• After each AI task, run every scene you'll keep using. Not just the current scene: open the other scenes you'll keep using in the same project from the SCENES window and check them with Launch. In case (1) above, the last line of the 6th scene's work was 자동 점검: 문제 없음 (Auto-check: no issues), but the 4th scene was broken.
• Check which scripts changed. Find the names of edited scripts in the AI's change report. In another scene's HIERARCHY, select entities marked <> and check whether their SCRIPT component has the same script. For the procedure, see Check what the AI changed.
• Don't delete unfamiliar scripts carelessly. A script in ASSETS that the current scene doesn't use may be in use by another scene.

When another scene breaks

Open the broken scene, describe the symptoms you saw in that scene exactly, and ask the AI to fix them. Don't guess at causes; describe what you saw together with the result you want. For how to write the prompt, see Send fix prompts.

Pending Once recovering a scene broken by a shared script with a fix prompt has been tested 3 or more times

Pending Once it has been tested 3 or more times whether telling the AI in the prompt not to edit other scenes' scripts prevents this problem

When you want games to be independent

Make games that must not affect each other in separate projects. Assets belong to a project, so scripts in another project are likely not shared. We haven't yet tested whether splitting into separate projects separates scripts. Splitting into scenes within the same project does not separate scripts.

Pending Add a link to the procedure once the project creation screen is finalized

Next steps

• Check what the AI changed
• Send fix prompts
• Create and switch scenes
• Run with Launch
• Change script attribute values
• Troubleshooting by symptom