feuerwerk

0 Fork 0

Term	Meaning
Account	Who you are signed in as. The editor asks for a user name and a password before it loads anything, and every project belongs to one account — see Accounts. The Account menu is at the far right of the toolbar and holds the name, Change password and Logout; signing in and out changes what the canvas draws, it never reloads the page.
Asset	Named thing with a type (`scene`, `camera`, `clip`, `sprite`, `text`, `behavior`, `collider`, `container`, `texture`, `animation`, `statemachine`, `shader`, `shaderfunction`, `font`, `sound`, `soundfx`, `instrument`, `particles`, `variables`) and typed properties. Assets have no position.
Texture	An uploaded image. Scenes, textures, animations, state machines, shaders, fonts, sounds and Variables assets are the eight types that cannot be placed: a texture has no position, it is worn by a sprite through the ordinary property `texture`. See Textures.
Font	An uploaded typeface, worn by a text through the ordinary property `font`; no font means the editor's own. Uploaded and picked exactly like a texture, and stored the same way. See Fonts.
Sound	An uploaded audio file. Uploaded, picked and stored exactly like a typeface — but nothing wears it: it is neither on screen nor in the scene, and a graph plays it with `Play sound`. Its own rows say how loud it is and whether it loops; the node scales the one and can overrule the other either way. Its tab shows the wave and cuts the sound to a stretch of its file, which is then what plays everywhere. A sound FX asset is a graph of effects (gain, pitch, EQ, mix) a `Play sound` can send it through. See Sounds. An instrument plays sounds as notes, see Instruments, and a pattern is notes for one, drawn in a piano roll, see Patterns.
State machine	A named set of states, edited as nodes in its own tab. A behavior puts it into a state with `Set state`, moves it along a named transition with `State transition` and branches on it with `State branch`. Its Scope says where the current state lives: Local gives every behavior instance one of its own, Global keeps a single one for the whole run. See State machines.
Shader	A node graph that becomes the GLSL a sprite is drawn with, edited in its own tab. A sprite, a text or a particle source wears it through `shader`; the numbers the graph declares are rows below that dropdown. A shader function is a part of such a graph kept on its own and used as a node in other shaders. See Shaders.
Particles	A node graph that says what one particle is as a function of its age and of a random number drawn once for it — no forces, no simulation. Unlike the other graph assets it is placeable: the object made from it is a source, whose rows say how many go out and for how long they live. Because a particle is a formula, the same second always draws the same picture and the tab's slider can jump to any of them exactly. See Particles.
Text	An asset that draws a line of text (`text`, `font`, `fontSize`, `letterSpacing`, `color`, `align`) — titles, HUD readouts, button labels. Its content is an ordinary property, so a `Properties` node of type Text with `text` switched to Set changes it while playing.
Enabled	Every placeable asset has the switch `enabled` (default on). A disabled object is not drawn, does not collide and its behavior does not run — and neither does anything parented below it. Switching one instance off is a normal override, which makes a container a screen: switch it on to show it, off to hide it. From a graph, `Properties` with `enabled` switched to Set does it, and `Is enabled` asks (including the parents); a behavior hears the switch as `On enable` / `On disable`.
Scene object	An asset placed into a scene: a link to the asset + a position (`x`, `y`, `z`) + sparse overrides of the asset's properties + an optional parent (another object of the scene). Drawn objects also carry transform rows (scale, rotation, mirror) — properties like any other, and they cascade to children the way a position does (see Scene editing). Scenes cannot be placed.
Container	A reusable group ("prefab"): the asset holds a template of objects (asset link, local position, overrides, parent links) centred on its origin. Placing a container stores the container object and nothing else — its content is resolved from the template on every read, so a template edit reaches every instance at once. Create container turns the current selection into such an asset: the selected objects move into the template and the scene keeps one placed container at their centre (world positions unchanged). The template is edited in the Container tab (see Containers) or from an instance through Apply to container.
Composition	Objects laid out in time: tracks, each with items (one object that lives from its start to its end) and animation clips that play on the items of their track. Edited in the Composition tab, placed in a scene like a container and played there with `Play composition`. See Compositions.
Selection	One or more scene objects. Click selects the topmost object as it is drawn, `Ctrl`/`Shift`-click adds/removes, dragging on empty scene space draws a rubber band (objects whose position lies inside are selected). A tilemap counts only where it has a tile, at the z of the highest layer with a tile there, so its empty cells are empty space. Clicking a selected object again selects the next one below it, and after the lowest the topmost again. Pressing on a selected object, even one hidden under others, and dragging moves the whole selection; `Delete` removes it; the inspector offers Create container and Remove for several objects.
Behavior	Logic as an asset: a node graph plus the variables it declares. Placed like anything else (a diamond symbol in the scene); its parent is the owner the graph acts on.
Variables asset	Declarations and nothing else — no graph, no position, never placed. A `Variables` node naming it reads and writes one value per key for the whole run, however many graphs point at it. The values start at the declared ones on every Play and are never written back, so playing cannot change the project; while a run is on the asset's inspector shows them live and an edit there reaches the run at once. Two such assets may declare the same name without meeting. A Persistent one keeps its values past the end of the run, in this browser: the next Play starts where the last one ended — the savegame. See Behaviors.
Run in editor	A switch only behaviors have (default off). With it on the behavior keeps running while the project is not playing — and unlike Play it then edits the saved model: what it moves or writes is a real change, autosaved and not on the undo stack. See Running without Play.
Run while paused	The other switch only behaviors have (default off). While a graph has paused the game (`Pause game`), only behaviors with it on are ticked — the pause menu, which is also the only thing that can resume. See The game pauses itself.
Collider	A shape (box or circle) for collision detection, placed as a child of the object it belongs to (its body). Drawn as a green outline in edit mode only; its area is tinted only while the collider itself is selected.
Collision layer	One of up to 16 named layers of the project (menu → Project settings…). A collider or tilemap names the layer it is on and the layers it collides with; two of them meet only when each one names the layer of the other. A new project has one layer, Default, which every collider is on and meets — so nothing collides differently until a layer is named. See Colliders.
Rigidbody	Placed as a child of an object, it hands that object to the physics engine while playing: it falls with the scene's gravity, bounces and rests on colliders, pushed by what it meets. At most one per object. See Physics.
Joint	Placed as a child of an object with a rigidbody, it ties that object to another one or to the scene while playing: a hinge, a spring, a rope, a fixed joint or a slider. Where it sits is the point it holds. See Physics.
Override	A per-object value that replaces the asset's value for one property. Only changed keys are stored; the inspector paints their label gold and offers a reset (↺) and an apply (↑) that writes the value into the asset instead. Both appear only where the value really differs from its base — an override carrying the asset's own value is none.
Default	Every property has a schema default. Asset values that differ from it are marked gold in the inspector and can be reset (↺) the same way an override can. The asset's name in the Assets panel carries the same gold while any of them does (`assetDeviates`, `src/core/properties/deviation.ts` — the inspector marks the rows of that same schema, so the list cannot claim a deviation the inspector then fails to show). A behavior's variables are not in it: their default is declared on the variable itself, so the asset value cannot differ from it.
Instance	An object resolved from a placed container's template. Its values can be edited — position, name, property overrides — and only what actually deviates is stored, as a sparse `instanceEdits` entry on the container object keyed by the template path. Everything else keeps following the template. Its structure cannot: it can not be removed, re-parented or given a collider, and nothing of the scene can be parented into it. ↺ ▾ resets to the nearest base, which inside a container is the template as the containers in between leave it; ↑ ▾ offers Apply to container (write the value into the template, where every other instance still at the old value picks it up) and/or Apply to asset (which drops the template's override as well). With one base left the menu collapses to a plain ↺ / ↑, with none the buttons disappear. Gold marks the same thing the buttons offer.
Unpack	Writes a placed container's content into the scene as ordinary objects (Unpack container in the right-click menu of the hierarchy or the scene view). The ids survive it, so the selection does; from then on the structure is editable and the objects no longer follow the template.
Start scene	The scene a run begins with, named on the project rather than on any asset (right-click a scene in the Assets panel → Set as start scene, `▶` marks it in the list; Clear start scene takes it back). It is a different question from which scene is active, which is the one you have open in the editor — the switch next to Play says which of the two Play asks. Without a start scene named, both are the same thing. See Scenes.
Load scene	The node that swaps the running scene for another one, inside the same run. Everything of the old scene is destroyed — its objects, their behaviors, and the sounds those behaviors were playing — while what belongs to the run carries on: the values of the Variables assets, the states of the global machines, and the clock. A top-level object with Keep on scene load switched on travels into the next scene instead, with everything below it. See Scenes.
Edit mode	The Scene tab draws the project model; panels, grid, gizmos and drag-to-move are active.
Play mode	The editor switches to a runtime copy of the project (same ids). A `World` is instantiated from the scene the switch next to Play names — the start scene, else the active one (one entity per scene object, resolved properties as mutable state) and shown in the Game tab. Systems tick it and mirror their changes into the copy; every panel stays open and edits the copy, which the world picks up immediately. Stop discards world and copy — the saved model is never touched.

The camera defines what is rendered. A camera asset has a view size (width x height, default 640x360) and a zoom; the frame it covers in world units is size / zoom. The Scene tab draws that frame as an outline. The Game tab renders only that frame, with black letterboxing around it, and objects outside it are culled. Of several cameras the first one in hierarchy order that is switched on (enabled, its parents included) is the active one, so switching it off hands the view to the next; with none on the tab stays empty and says No active camera. Without playing the tab previews the scene through that same camera, so it shows what Play would show, minus the editor symbols. Play has no built-in behaviour (no input, no movement): everything that happens is defined by behavior graphs.

Render layers and overlay cameras (#302). A project has up to 16 named render layers, edited in Project settings… next to the collision layers and kept apart from them: what meets and what is seen are two questions. Sprites, texts, tilemaps, particle sources and containers carry a Render layer row under their switches. Its default Inherit puts the object on its parent's layer, and at the top on the first one, so a HUD container on UI takes everything in it along. A camera's Sees ticks the layers it shows, all of them by default. A camera with Overlay switched on is never the main camera; every overlay camera that is switched on draws over the main one, in hierarchy order, see-through. Each camera draws a picture of its own: only its layers, sorted by z among themselves. The pictures are then laid on top of each other, so z never sorts across cameras. A sprite of an overlay camera at z -1 lies above a sprite of the main camera at z 0. Something meant to lie below the world goes to a camera of its own that is made the main one, with the game camera as an overlay. The main camera decides the size of the picture and the zoom of the tab; an overlay camera is fitted into that picture without distortion, so one of the same size and zoom covers it exactly. The mouse is reported through the main camera; Mouse position and Is hovered ask another one through their camera input (#304, see Mouse in Behaviors). A graph changes both while the game runs (#305): a Properties node of the object's type with Render layer switched to Set moves it (a number, or -1 for Inherit), one of type Camera with Sees changes what a camera shows, and the next picture follows. Render layer of answers the layer an object is drawn on, inherited or its own, by name and number; for an object that is not drawn the name is empty and the number -1. Two cameras switched on without Overlay draw as before: through the first one only. The Scene tab shows every layer. A camera can also wear a shader over its picture (#299, see Wearing a shader in Shaders); it works on that camera's picture alone, before the pictures are laid on top of each other. Measured in the checks (step 63): a green sprite of an overlay camera at z -10 covers a red one of the main camera at z 1000, a UI sprite in front of the main camera and a Default one in front of the overlay stay away, and the same holds in the running game. With the overlay camera zoomed 2x, the real mouse 30 units right of the centre of the picture lies 15 units right of the overlay camera's centre (2015 at a camera on 2000): Is hovered through it finds the green sprite, through the main camera not. Moved onto UI by a graph on start, the red sprite leaves the main camera's picture, and Render layer of names it UI and 1.

A clip area cuts what is below it (#260). It is an object of its own (Clip area, + menu) with a width x height, and it turns, scales and mirrors with its parent like a sprite. Everything parented below it, at any depth, is drawn only inside its rectangle, in the Scene tab as in the game, and a click or hover on the part it cuts off hits nothing (On click, Is hovered, On mouse wheel). Clip areas above one another intersect. In the game the area itself is invisible; the Scene tab draws it as a dashed outline, which the eye hides under Shape and which is also where it is grabbed, so a click inside still reaches its content. While an object, or anything above it, is selected (the area itself, one row of a list, the window around the area), the Scene tab shows its cut-off part faintly if it is a sprite or a text, and it can be grabbed there. That is how content that scrolled out of view is found again. Tilemaps and particles below an area are cut the same way, only without that faint rest. A list that scrolls is a clip area with the list below it, moved by a graph, for example from On mouse wheel.

Game view scale (#225). The picker in the Game tab's header sets how large the camera's picture (its width x height) is drawn:

Choice	Screen pixels per camera pixel
100% (default)	1. 25%, 50%, 200%, 300%, 400%, 500% and 600% likewise draw exactly that factor.
Auto	The largest of those eight steps at which the whole picture still fits. Below 25% it stays at 25%.
Fit	Whatever fills the view on its tighter side, the way the tab always drew before.

The camera's zoom magnifies the world on top: a 640x360 camera at zoom 2 shows 320x180 world units, and at 100% still fills 640x360 screen pixels. Auto and Fit name the factor they came to (Auto · 100%, Fit · 105%) and follow the view when it changes size. A picture larger than the view is cut to it, the camera stays in the middle. Fixed steps start on a whole screen pixel, so pixel art at 100% stays sharp. The steps count device pixels: with Windows display scaling at 125%, 100% is still one screen pixel per camera pixel, and Fit then names the factor in screen pixels (Fit · 156%). The choice is saved with the project, like Play starts, but it is no undo step: Ctrl+Z undoes edits, not a look at the game.

Pixel perfect, a switch on the camera, off by default. On, the game view draws on its own pixel grid: one step per screen pixel a world unit gets, so at 100% on whole units and at 500% on fifths. The world's origin lands on a whole screen pixel, and every sprite, text and tilemap on a step of the grid, however the camera moves. Positions keep their fractions: only where things are drawn snaps, so a camera that follows smoothly still moves smoothly in the model. An unturned object snaps its top left corner, so a 15 px wide sprite is as sharp as a 16 px one; a turned one snaps its centre. Under a camera shader the grid is the shader picture's: with Camera pixels one step per camera pixel. The switch does nothing at Fit, where a camera pixel is no whole number of screen pixels anyway, and nothing in the Scene tab, where one works with the fractions. Particles are drawn where they are. An overlay camera has a switch of its own.

Fullscreen (#267). The button at the right end of the Game tab's header puts the game view on its own into fullscreen: no toolbar, no panels, no tab header, no console, at the scale the picker holds. A run goes on as before and the keys still go to the game. A button in the top right corner leaves fullscreen, and so does Esc, the browser's own key; the view is back in its tab as it was. Over a running game that corner button steps aside once the mouse has rested for 2 s and comes back with the next move. Stopping the run ends fullscreen too, since Stop goes back to the Scene tab.

While playing (#265). How closely the editor follows a running game is one preset in Menu → Project settings…. The game itself runs every frame in each of them, and so does the picture of it on screen; only the panels are held back. With hundreds of objects spawning and dying, rebuilding the hierarchy for every one of them cost more than the game.

Preset	Hierarchy	Inspector and other values	Graph highlights	Scene view behind the Game tab
Live	every frame	every frame	every frame	keeps drawing
Balanced (default)	4 times a second	4 times a second	every frame	waits until its tab is shown
Minimal	on pause	on pause	4 times a second	waits until its tab is shown

A change in between is kept, not lost: the next update carries it. Pausing (the toolbar, Ctrl+Enter or a Pause game node) brings every panel up to date at once, and picking an object during a run lists it in the hierarchy at once. The graph and state machine tabs only draw while they are on screen, so Balanced lets them keep up with every frame. Under Minimal they are held back too, but a pulse glows for 0.35 s, longer than the gap between two updates, so every pulse still shows. Balanced is also what a project written before there was a choice plays with. The preset is saved with the project and is an undo step.

Performance (#275). The Performance button in the Game tab's header switches an overlay in the top left corner of the game view. It shows while a game runs, and only then: the frame rate, how many entities the world has, and where the time of a frame goes, in milliseconds per frame averaged over half a second:

Line	What it counts
Behaviors	The behavior graphs and state machines
Physics	The physics step and the contacts it finds
Animation	Advancing the animations
Drawing	Building the game's picture and handing the frame to the GPU
Editor	Everything else the editor does in the frame: writing the run into the model, the panels, the console

The top line, Possible, is the frame rate the measured time would allow if nothing waited for the display: a second divided by the five times added up. The frame rate below it stops at the display's rate (60 on most screens), this one does not. Because the GPU's time is not in it, it is an upper bound, and the editor's share is in it, so a released game can do a little better.

A dash stands for what has not been measured yet, in the first half second of a run. The numbers are what the main thread spends; the GPU works on after that, and its time is not in them. The switch is not saved and stays as it is until the page is loaded again. A released game has no overlay.

Snapshots (#231). Menu → Snapshots… lists the snapshots of the open project, newest first, with the local time each was made. Create snapshot copies the project as the server has it stored, under the name typed or, left blank, under the date and time; the autosave is written first, and while anything is still unsaved (a run with edits waiting, a failed save, a conflict) no snapshot is made. Restore asks first, then keeps the project as it is now as a snapshot of its own, Before restoring <name>, and writes the snapshot back as a new revision — so a restore can itself be taken back. The project is loaded again, which starts the undo history over, and a second tab still on the old revision is told the project was changed elsewhere. Delete asks, then removes the one picked. Cancel on either question, or Esc, leads back to the list. A snapshot is only a copy of the project document: images, fonts, sounds and pixel art are stored by their content and never removed, so everything it names is still there. Deleting the project deletes its snapshots. Whoever can open a project can use its snapshots, an administrator included.

Release (#266). Menu → Release… turns the project into a link that plays only the game: no editor, no sign-in, the game view over the whole browser window on the page colour. Publish copies the project as the server has it stored — the autosave is written first, and nothing is published while anything is unsaved, the same rule as for a snapshot. The copy is frozen: what is changed in the editor afterwards reaches players only with Update release, which replaces the copy and keeps the link. The dialog says when the copy was taken and whether the saved project has moved on since, and shows the link with Copy link and Open. Take down asks, then makes the link dead; publishing again afterwards hands out a new one. Deleting the project takes its release down. The link is play.html?game=<token>, the token 128 random bits and the only key.

The game on the link always starts in the start scene (the Active scene switch is the editor's alone). How it is zoomed is the project's Link zoom in Menu → Project settings… (#279): Auto, the default, is the game view's Auto — the largest zoom step at which the whole camera fits, never a scale between the steps, which keeps pixel art sharp. Fit fills the window in one direction at whatever factor that takes, like the game view's Fit. The setting is its own and not the scale of the Game tab, which is how the editor looks at the game; fixed steps such as 100% are not offered, since nobody knows the size of a player's window. It is an undo step, and like every other change it reaches the link only with Update release. The game waits for a click or Enter before it starts — browsers play no sound before one, and the keyboard would have nowhere to go. Every key belongs to the game, Tab included. A game that stops itself (Stop game) offers to play again; Restart game and Load scene work as in the editor. Persistent variables are saved in the player's browser under the link, apart from the editor's own saves. Plugins are not loaded on the link; the dialog warns when the project uses any, and when it has no scene to play. The page has the same fullscreen button as the Game tab in its top right corner (#267); a click on it never reaches the game.

Toolbar and panels. The toolbar carries five icon buttons and no captions (#183): the menu (three bars) on the left with New project, Open project…, Snapshots…, Release… and Project settings…, undo and redo beside it, and play and pause in the middle — on the middle of the window, not of the space the row has left over — where play turns into a stop square while a run is on, and pause into a second play sign while it is held. Rest the pointer on one of them and a tooltip says what it does and which keys do the same (#209); undo and redo name the step they would take, as in Undo Paint tiles (Ctrl+Z). Every other button that carries a picture instead of words has one too, and a tab whose name was cut short shows the whole name. On the right stand the notice line, the save status, the frame rate and the Account menu. What the bar used to spell out lives in the menu now: the project list in Open project…, the project name, the start-scene switch (Start scene / Active scene, see Start scene), the While playing preset (see above), the Link zoom of the released game (see above), the symbol scale of the scene view's icons (see Scene editing), the collision layers and the render layers in Project settings…. What is about the person at the screen rather than the project is in General settings… (#309), kept in this browser and the same in every project: the zoom transition (see below), whether the asset panel shows empty categories and types (see below) and the custom mouse pointer: on by default, the editor shows the pointer an editor recording draws (see Videos) instead of the system's. A project is deleted in Open project…: Delete asks first, and Cancel, Esc and the deletion itself all lead back to the project list. The active scene is picked where the scenes are — by double-clicking one in the Assets panel. The Assets panel's + creates an asset and opens its tab; its menu lists the categories of the panel (Basics, Visuals, Logics, Physics, Audio), and each opens a submenu beside it with the types of that category, sorted by name — the same filing as in the panel, so a new asset turns up where you looked for its kind. A submenu opens as soon as the pointer rests on its category or on a click; moving on to another category swaps it after a short wait, so a pointer crossing the rows on its way into a submenu does not take it away. Picking a type closes both, and so do Escape and a click beside them. (Until then the menu was one list in two groups, placeable types and library ones, #43.) A right-click on the empty space below the rows opens the same menu (#244). On a category heading it offers only the types of that category, without the submenu, and on a type heading only that type (#361). Each of these menus says Create asset in a muted line above its entries, so a click on a type reads as making one. A right-click on an asset keeps its own menu. Every type has an icon of its own, the same wherever the type shows: in the + menu, on the asset panel's groups, on a document's tab and at the end of a row in Scene objects (#176). The asset panel groups by category and type (#176). On top are the categories Basics, Visuals, Logics, Physics and Audio, always in that order. Under each is one heading per type that has assets, named like its + menu entry (Scene, Sprite, Sound FX), with its icon and the count at the right. Groups and the assets inside them are sorted by name. Which category a type belongs to is set in ASSET_GROUPS (editor/panels/assetGroups.ts). When a project opens, every category is open and every group folded; a click anywhere on a heading folds or unfolds it, and a heading is never selected. Selecting an asset from elsewhere (a picker, a graph, a new asset) unfolds its category and its group; folding the category or group the selected asset sits in lets go of the selection. With Show empty asset categories and types in General settings… (off by default, #361) the panel lists every category with every type, also those without assets. They stand faint, with a count of 0, and an empty type has no chevron, since there is nothing to unfold. A right-click on such a heading creates the first asset of that type. A sound or a video with clips has a chevron of its own (#425): it unfolds one row per clip under it, folded when the project opens. A clip row is dragged like an asset, onto a track of a song or a composition. A click on it shows the clip in the inspector without moving a tab, a double-click opens its sound or video with the clip picked. Folding the clips keeps a clip picked in its tab. A texture with frames, and pixel art with more than one frame, unfold their frames the same way (#430), the frames of pixel art named Frame 1, Frame 2 ... as in the Texture picker. A frame row is dragged onto a track of a composition. A click on a texture's frame shows it in the inspector, a double-click opens the texture with the frame picked. A frame of pixel art has nothing of its own to show, so a click selects the pixel art and its tab, if open, paints on that frame; a double-click opens the tab on it. The label of a Texture row naming a frame links the frame itself: a click lights up its row, a double-click opens it. A click on a row only selects (the inspector shows it, no tab moves); a double-click opens the asset as a document in a tab of its own (see The tab row) — a behavior, state machine, shader, particles, sound, texture, animation, tile or container — and on a scene switches to the Scene tab and makes it the active one. Enter does the same once the list has keyboard focus (Tab). A sprite, camera, text or collider has no tab of its own, so a double-click on one does nothing. Right-clicking a row offers Set as active scene, Set as start scene / Clear start scene, Create sprite from texture, Create animation from texture, Duplicate and Delete…. Duplicate puts a copy right below the original, named the way a new asset would be ("Crate 2"), selects it and opens its tab where it has one (a copied scene does not become the active one); one undo takes it out again. The copy has its own values, graph, frames and objects, so editing it leaves the original alone. Whatever pointed at the original (a sprite wearing it, an animation's root, a placed object) keeps pointing at the original. In Scene objects it offers Select asset, Open asset (the same as double-clicking the asset in the asset panel, or the object's row since #353; greyed out for a kind that has no editor of its own, such as a sprite or a camera), Add collider…, Add rigidbody… and Add joint… (each opens a searchable menu: a new one or one the project has, see Colliders and Physics), Fit to sprite on a collider, Create container, Unpack container, Unparent, Expand all / Collapse all and Remove. The scene view's right-click menu is the same. Both menus also offer one Open … entry per asset the values point at (#221): a sprite wearing a picture and a shader has Open texture and Open shader, in the asset panel at the top, for a placed object right below Open asset. They read the object's own values, so an object that overrides its shader opens that one. A frame opens the texture or pixel art it was cut from. An empty or dangling reference, or one to a kind without a tab (a palette, a font), gets no entry.

Links in the inspector (#221). A row that picks an asset from a dropdown (Texture, Shader, Font, Palette, a node's Behavior, …) shows its label as a link while it names one: blue and underlined, or gold and underlined while it is an override. A click pings that asset, the way Unity does: the asset panel unfolds its group, scrolls to its row and lets the row light up for a second. Nothing is selected, so the inspector stays on the object you are working on. A double-click opens the asset like a double-click in the asset panel. A frame pings and opens the texture or pixel art it was cut from. A clip of a sound or a video (#425) is a link to the clip itself: a click unfolds its sound or video and lights up the clip's row, a double-click opens the sound or video with the clip picked. A row that names nothing is plain text again. A placed object's Asset row (and Part of for content of a container) works the same: the label is the link, the field beside it shows the asset's name and only reads. So does the Plays row of an audio item in a composition, which links the clip where it plays one. It follows a rename of the asset right away.

Groups in the inspector (#290). The rows stand in groups, and each group has a band as its head: from edge to edge of the panel, in the header colour, with the title in it and a mark in front that says whether the group is open. A placed object shows its name, asset and parent first, then Switches (Enabled, Keep on scene load, and a behavior's Run in editor and Run while paused), Position, Transform, Editor offset and Properties (a behavior: Variables). An asset shows its name, then Switches and Properties; a group without rows is left out.

A click on a band folds its group: the rows go, the band stays, and the next band moves up against it. Another click brings the rows back. A control in the band (Open, + Variable, + Property) does its own job and folds nothing, also while it is greyed out.
A fold is remembered by title, per panel, in this browser. Transform folded once is folded for every object and asset, and after a reload. A number in a title does not count, so Key at frame 12 and Key at frame 3 are one group. The inspector, the tilemap panel, the Variables tab and the side of the Pixel art tab each keep their own.
The same bands head the other columns built this way: the tilemap panel (Painting, Tiles, Layers), the Variables tab, the side of the Pixel art tab (Tools, Colors, Layers, Frames, View, Preview) and the shape list of vector art in the inspector. A list with a header of its own (Layers, Frames, Shapes) folds with a click on that header, clear of its plus, and takes the notes and buttons under it along.

Sprite preview. A sprite, placed or as an asset, ends its inspector with a Preview group: the sprite as the scene draws it, with its picture or frame, nine-slice, tint and shader, on the scene's background. A placed sprite shows its own overrides. An edit shows at once, also while a value is dragged, and a shader with a Time node keeps moving while the group is open. The picture is fitted into the group and magnified by whole device pixels at most 8 times, so pixel art stays sharp; a sprite larger than the group is shrunk to fit.

The asset panel and Scene objects share the left column; the divider between them drags the height from one to the other, and dragged all the way either keeps its header. The split is a share of the column, so a taller or shorter window keeps it. Both lists glide on a wheel step instead of jumping, as long as the zoom transition takes (see below); quick steps add up and go on at the pace the list had, and dragging the bar or a jump to a row ends the glide where it is. Below the last row the asset panel always keeps room for six more, so its end can be scrolled up away from the bottom edge; clicks and the context menu there work as on any empty part of the list. Folding a group leaves the list where it stands: the heading clicked stays under the pointer, and rows that fold away near the end leave their room below until the list is scrolled up. Only a new selection scrolls the list to its row.

Panel sizes are remembered. Every divider stays where it was dragged, after a reload too: the ones left and right of the centre column, the one above the console, the one in the left column, the one beside the tilemap panel, the one beside the preview of the Shader, Particles and Pixel art tabs (each tab its own), and the one in the user management. The sizes are kept in the browser, like the folded groups, not in the project: they hold for every project opened in this browser, and another browser starts with the sizes the editor comes with.

The tab row. A tab is an open document, as in an IDE (#171). Scene and Game are fixed and cannot be closed; a plugin's own tab follows them for as long as the plugin is on. The plugins themselves, and for an administrator the accounts, are in a tab that opens from the menu and closes like a document (Menu → Plugins or User management, #179, see Accounts). Everything else opens as a document: double-click (or Enter) an asset in the asset panel, create one, or open a list from its row. An open document only comes up again, a new one gets its tab right of the document on screen (or last, from a fixed tab). Several assets of one kind can be open at once — two textures, three behaviors — each with its own tab.

The tab shows the icon of its kind, then the name, so a behavior and a texture both called Player stay apart; the » menu lists hidden documents the same way. Scene and Game carry an icon too (#176) — the scene one from the asset panel, a play sign for the Game tab. The plugins' tab shows a puzzle piece (#119), or two people when it holds the user management (#179). Only a plugin's own tab goes without one, as it brings no picture of its own. A long name is cut with an ellipsis. Renaming an asset renames its tab.
A document tab always shows its own asset. Selecting something elsewhere never changes it; there is no picker in the tab's header any more. Selecting what lives only inside a document — a node, a frame, an object of a container — brings that document up.
The close cross at the end of the tab, or a middle click, closes it; nothing is lost, every edit is in the project already. Closing the tab on screen shows its left neighbour (the right one when it was first), the Scene tab when none is left. Deleting an asset closes its tab.
Each document keeps its zoom and scroll for the session: switch between two textures and both are where you left them.
A wheel step and Fit are shown as a short zoom transition (#309) wherever the editor zooms: the Scene and Container tabs, the Texture, Curve, Pixel art and Vector art tabs, the Animation tab's preview and timeline, the graph, the Tile tab's board and a plugin's node board, the time of the Video tab, and in the music tabs (#377) the Pattern, Song and Sound tabs and a Parametric EQ's curve. There the time across and the rows, tracks or height down zoom apart, and each goes its own way; the EQ's dB lines slide to their new place already labelled with the range it is heading for. How long it takes is set in Menu → General settings… in milliseconds, 200 by default; 0 jumps at once. The steps are the same as without it: quick wheel steps add up to exactly as many steps, and the point under the pointer stays under it all the way. A step that comes in on the way goes on at the pace the view already had, so a run of quick steps moves in one stroke instead of kicking at each. A pan during the transition takes it along: the zoom goes on, and the view lands where it was heading, moved by the pan. Another document or a new size of the view ends the transition on the step it was heading for. Following a call node into another behavior stays in the same tab, and the breadcrumb stays with that tab.
A tab can float (#371): right-click it and pick Float, and the document leaves the row for a window of its own above the editor. Its title bar moves the window, the lower right corner sizes it, Dock puts the document back into the row, showing, and the close button closes it. Only documents float, never Scene or Game. A window is at least 320x200 px. A tab that needs more, like a Compressor's with its knobs (#378), holds its window at that size.
- Every kind has one editor, so it has one window: with a texture in a window, opening another texture shows it there and closes the one it had. Windows of different kinds can be open side by side, a sound FX beside its Parametric EQ for instance.
- Delete, Copy and Paste go to the window after a press in it, and back to the tab showing after a press in the editor.
- Nothing of a window is remembered: it opens in the middle of the screen every time, and a loaded project closes it.
Open tabs are not remembered: a loaded project starts on the Scene tab.
Tabs are drawn as index cards (#176): the one showing is a light grey card with rounded upper corners standing on the line the row ends with, the others only take a colour under the pointer. Both write their name in plain weight — the fill says which document is on screen — and pressing the card that is already showing does not change its colour.

When the column is too narrow to hold every tab — a small window, many documents, or the side panels dragged wide — the ones that do not fit move behind a » button at the end of the row, which lists them by kind and name; picking one opens it and brings it into the row. The tab you are editing is always in the row: if it has to, the row gives up every other tab to keep it there. Nothing is ever drawn past the column's edge, where it would sit under the inspector and take clicks meant for it.

The console. Under whichever centre tab is showing sits the Console panel, always visible and resized by the divider above it — dragged all the way shut it keeps its own header to be dragged open by. It mirrors everything that reaches the browser console: a Log node's message, Pixi's warnings, an uncaught error, and the editor's own notices (a failure in red, a hint in plain text; the Playing · … status line is a mode rather than an event and stays out). Each line carries the clock time of its call (HH:MM:SS, muted, in its own column, so the message stays exactly what was logged). The newest 500 lines are kept, Clear empties them, and new lines follow the tail only while the tail is what you are looking at.

Editing while playing. Play opens the Game tab but leaves the editor fully usable: the Scene tab shows the live positions (symbols, gizmos and dragging included), the hierarchy and inspector show and edit the running objects, the graph can be changed, undo/redo work on the play session's own history. All of it happens in the runtime copy: values a behavior changes appear as overrides (gold, ↺ resets to the asset value), objects a graph destroys vanish from the lists, objects a graph spawns (Spawn node) appear in them — selectable, editable, still only in the runtime copy —, and Esc/Stop brings back exactly what was saved. Autosave pauses while playing.

Pausing. The toolbar's Pause button (or Ctrl+Enter) holds the running world: it is no longer ticked, so behaviors, timers and collisions stand still and the world clock stops with them. It is a sub-state of play mode, not a third mode — the runtime copy, the panels and the keyboard behave exactly as while playing, and everything the editor can do during play it can do during a hold. Keys and clicks that arrive while it is held are dropped rather than queued, so resuming does not fire a frame's worth of input at once. Stop clears the hold, so a paused game can never outlive its run. A hold is the global time scale at 0 (see Architecture), and that scale reaches everything that moves by itself: particle sprays, time shaders and the Animation tab's preview stand still with the world rather than carrying on beside it. That clock starts a run at second 0 and goes back to 0 when the run ends, which is why the scene view looks freshly loaded after Stop.

Starting paused, stepping and breaking. Before Play the Pause button is a switch: pressed in, every Play starts held, until it is switched off again. A Restart game keeps whatever the run had. While held, Next frame (the button beside Pause, or Ctrl+Shift+Enter) runs exactly one frame of 1/60 s game time, whatever the frame took on screen, and holds again. The panels are up to date after every step. A Break node in a graph holds the run the same way, once the frame it ran in is over. The status line then names the behavior object it ran in (Break in Player). Break is the editor's pause, not the game's: a released game and the editor run go past it.

The game pauses itself. The toolbar's hold is the editor's: nothing runs under it, not even a graph. A game that wants a pause menu, a slow motion or a frozen moment during a dialog does it from its own graphs (#167):

Node	What it does
`Pause game`	From the next frame on the world time, physics, animations, particles and shader time stand still, and only behaviors with Run while paused are ticked. They get their keys, clicks, timers and `On update` as usual; collisions are not reported, because nothing moves that could collide. Sounds play on.
`Resume game`	Lets it run on from where it stood, from the next frame.
`Is game paused`	True while it is paused, so one key can do both (`Is game paused` → `Branch` → `Resume game` / `Pause game`).
`Set time scale`	How fast the game runs: 1 is real time, 0.5 slow motion, 2 twice as fast. Movement, physics, animations, particles and shader time follow it. At 0 everything is frozen, but the graphs keep running with a `dt` of 0 — that is the difference to a pause.
`Time scale`	The scale as it was last set.

The two are kept apart on purpose: a pause stops the game but not its menu, a time scale of 0 stops time but no graph. A pause belongs to the scene, so a Load scene from a pause menu arrives in an unpaused level, and so does a Restart game. The time scale belongs to the run: it carries over a Load scene, and Play and Stop set it back to 1 — also for the editor's previews, which share the clock. The toolbar's hold works on top of either one and leaves both as they are. In the editor run both are ignored with a line in the console: an edited scene that stops for no visible reason, or an editor whose previews crawl, would help nobody.

Running without Play. A behavior switched to Run in editor goes on running while the project is not playing (src/editor/EditorRun.ts, ticked by the Editor next to the play session). The switch is an ordinary property, so it can be set on the behavior asset and overridden per object. What it runs is a World over the saved model, and that is the whole difference to Play: a position or variable it changes is a real edit — it is autosaved, the panels show it, and undo does not take it back. Which is why the switch is off by default and why it belongs on behaviors that arrange or build content rather than on ones that simulate.

Editing the graph while it runs. A change to the graph of a running behavior — a node setting, a link, a node added or removed, an undo — is what the behavior runs from the next frame on (#216). The behavior carries on, it does not start over: its variables and timers stand where they stood, and On start does not fire a second time, so what it wrote or spawned is not written again into the saved scene. To start it over, switch Run in editor off and on (or press Play).

Input goes to the tab you are looking at. While the Scene tab is on screen the keyboard and the mouse are the editor's — typing a name or walking the hierarchy with the arrow keys must not steer a game at the same time. In the Game tab, where no key means anything to the editor, they reach the run instead: On key …, Key is down and On click work there, and the tab says so in its top-left corner. Leaving the tab (or focusing a field in it) hands the keyboard back and lets every held key go, so nothing keeps walking with nobody pressing anything. What the run does not get:

structural changes to the content of a placed container — such content is resolved from the template, not stored (see Containers), and the editor run must not bake it out, since that is itself an edit. Its behaviors do run, and what they move or set is kept as an instanceEdits entry on the instance; but a Destroy of resolved content is dropped from the running world without being saved, and comes back the next time the world is rebuilt.
a second life — only the behaviors of the loaded scene run, and only in edit mode; Play stops the editor run, since that world runs every behavior anyway. An exception in a graph, or a Stop game node, ends the run and puts the reason in the notice line instead of repeating it every frame.

Using the editor

Working on the code