feuerwerk

0 Fork 0

Table of Contents

Active scene, start scene
Load scene
Keep on scene load
Restart, stop, load — what each one keeps

A project holds as many scenes as it likes. One of them is the one you are editing, one of them is the one a game begins with, and a graph can swap the one that is running for another. Those are three different questions, and this page is about keeping them apart.

Active scene, start scene

The active scene is what the editor shows: the Scene tab draws it, the hierarchy lists it, a dropped asset lands in it. It is set by double-clicking a scene in the Assets panel, or through Set as active scene in its context menu — the toolbar has no scene picker since #183. A dot marks it in the list. Both ways stay open while a run is on: they only move the editor's view and never touch the running world.

The start scene is where a run begins — the title screen, the first level, whatever a player would see first. It is named on the project, not on the scene asset: right-click a scene in the Assets panel → Set as start scene. The play triangle marks it, and the same place offers Clear start scene to take the name back. A project that never names one has none, and then the two questions have the same answer.

Which of the two Play uses is the Play starts switch in menu → Project settings…:

Switch	What Play builds its world from
Start scene (default)	The named start scene; the active one while none is named.
Active scene	Whatever scene is open in the editor, whatever the project says.

The switch is saved with the project (#226), so whoever opens it gets the same answer, and changing it is an undo step like every other project setting. It stands in the settings dialog beside the project name, the While playing preset (see Concepts), the symbol scale and the collision layers. It is captioned with the mode it stands in — Start scene or Active scene, worded exactly like the entries of its own menu, so that what you picked and what you read back are the same words. The start scene is marked with the play triangle in the Assets panel, the active one with a dot.

The point of the two modes is that a game with a title screen is otherwise tedious to work on: every run would begin at the title, three clicks away from the level you are editing. Active scene is the mode for building, Start scene the mode for playing what you built.

Deleting the start scene leaves a name nothing answers to, and that reads exactly like no name at all — the run falls back to the active scene. Undoing the deletion brings the start scene back with it, because nothing was cleaned up behind your back.

Load scene

Load scene swaps the running scene for another one, from inside a graph — a level ending, a door, a game-over screen. Its scene input takes a scene the way Play sound takes a sound; a Scene literal feeds it through an edge.

On collision (Exit) → Load scene (Level 2)

What ends. Everything of the old scene that is not kept (see below): its objects, the behaviors on them, and the sounds those behaviors were playing. That last one is not a rule of its own — a voice belongs to the behavior that started it (see Sounds), and those behaviors are destroyed like everything else in the scene. Music that should carry across a swap is played by a kept object, started again in the new scene, or played detached.

What carries on. What belongs to the run rather than to the scene:

the values of the Variables assets — the score that survives the next level,
where the global state machines stand (see State machines),
the clock: Time keeps counting, only a restart puts it back to zero.

A local machine's state does not: it belongs to a behavior instance, and that instance is gone — unless its object is kept. An object travels only with Keep on scene load switched on; everything else that has to get from one scene to the next travels as a shared variable.

When it happens. Once the frame is over, never mid-flow: the graph that asked runs to its end first, in the world it is still standing in. Half a frame in the old world and half in the new one is the kind of thing nobody can debug. Asked twice in one frame, the last ask is the one that happens.

Loading the scene that is already running rebuilds it. That is reset this level — the same picture as a restart, except that the shared variables are kept, which is what makes a life counter work.

A scene is always built as it is stored. Whatever the run did in it on an earlier visit — moved a box, destroyed a coin, spawned an enemy — is gone when the scene is loaded again, whether that is the scene it is in or one it comes back to. Until #165 a run in the editor built it from what it had left behind instead. The same holds for what you edit in a scene while playing: such an edit was never saved, and the next load of that scene does not have it either.

An id naming no scene does nothing and says so in the console, rather than tearing down the world it is standing in half way through.

In the editor run it is ignored (a warning in the console). The editor run is the scene you are looking at, brought to life; swapping it would mean editing a scene you are not looking at.

Keep on scene load

A top-level object with Keep on scene load switched on is not destroyed by a Load scene. It moves into the next scene as it is, with everything below it:

the same objects, where the run has them: position, every property and variable. An object held in a variable somewhere still names it,
its behaviors, running on: no On destroy in the old scene and no second On start in the new one, timers, variables and local machines stand where they stood, and a sound such a behavior plays is not cut off,
its animations, playing on from where they are,
how its body moves: a dynamic rigidbody arrives with the velocity and spin it had.

The switch sits right under Enabled in the group Switches, on the asset and on a placed object, so a Player asset can say it once for all its placements. Like every property it can be set while the game runs, with a Properties node whose port is on Set.

Only a top-level object of a scene can be kept. A child would arrive without the parent it is placed in, so the inspector shows the switch on top-level objects only, and a value an asset brings to an object further down counts for nothing. What hangs below a kept object comes along whatever its own switch says.

Duplicates: the one that was brought along wins. A kept object lands in the next scene after that scene's own objects. Two kinds of the scene's own objects are then not built, each with everything below it:

an object with the same id. That is the scene the object came from, loaded again: coming back to level 1 gives one player, not the travelled one plus the stored one,
a top-level object of the same asset that is kept itself. That is what lets every level place its own Player — so each level can be played on its own from the editor — and still hold exactly one after a swap. An object of that asset that is not kept is built as usual: five placed crates stay five, whatever crate was brought along.

Whatever in the scene named its own object by a reference — an Object variable picked in the inspector, a row of a scene animation — finds the object that came instead. That covers the object itself, not what hung below the one left out.

What does not travel. Collisions are found anew: a kept object that touches something in the new scene gets an Enter for it, also for what it brought along itself. Ignore one-way ends with the scene. The picture of a moving body stands still for the one frame the new scene starts in. An object the run kept is back where it was stored once the run stops, like everything a run does.

Restart, stop, load — what each one keeps

	Objects	Shared variables	Global machines	Clock	Time scale	Pause game	Sounds
Load scene	rebuilt as stored, kept ones travel	kept	kept	keeps running	kept	lifted	end with their behavior
Restart game	rebuilt	back to declared	back to their start state	back to 0	back to 1	lifted	all end
Stop (`Esc`)	gone	discarded	discarded	back to 0	back to 1	lifted	all end

Using the editor

Working on the code