Goal
A level designer makes a level do things without writing code: walk into this volume and the red siren starts turning, its light flashes and a sound plays; press this switch and that door opens; when the timer runs out, spawn the zombies at the marked points. Today that logic is written in Swift, either in game code or through USCBuilder, the fluent API of the built-in script system (USC): events (OnStart, OnUpdate, OnCollision:Tag, custom events), conditions, loops and delays, float, vector and bool math, and entity actions (translate, rotate, look at, play and stop animation, camera moves, key input), attached to an entity as a ScriptComponent with its script files saved with the scene. The editor lists the attached scripts with a trigger and a mode, and its feature flags already anticipate a "visual scripting / Blueprint-like system".
The goal has two parts. First, the script system grows the vocabulary a level needs and does not have: trigger volumes, timers, spawn and destroy, lights and materials, sound, entity references and tags, variables that belong to the level, events sent between entities, and a faster interpreter (it compares instruction strings per script per entity per frame today). Second, a visual way to author it in the editor, like Unreal's Blueprints in spirit but deliberately smaller: a level designer connects a trigger to conditions and actions on a canvas, sees the graph light up while the scene plays, and the graph compiles to USC so the runtime stays the same on macOS, iOS and visionOS. Research first: we want the simplest model that covers level logic (an event sheet like Construct or GDevelop, a small node graph, or both), not Unreal's generality.
Status
| Step |
Plan |
Status |
| Research |
Survey Blueprints, Unity Visual Scripting, Godot's VisualScript retirement, Construct and GDevelop event sheets; list the level-logic cases from the game; pick the authoring model and the node or event set; decide how a graph compiles to USC |
Not started |
| Script vocabulary |
Trigger volumes, timers, spawn and destroy, light and material actions, sound (needs the audio system, issue #1242), entity references and tags, level variables, events between entities |
Not started |
| Interpreter |
Pre-resolve event names and variables, cache per script; measure on the benchmark |
Not started |
| Graph editor |
Canvas with nodes or event rows, wiring, entity and asset pickers, undo, saved next to the scene |
Not started |
| Live debugging |
Active nodes highlighted while the scene plays; breakpoints on events |
Not started |
| Sample |
The red siren: a trigger volume starts a rotation, a flashing light and a sound; a switch opens a door |
Not started |
Next steps
- Research note with the level-logic cases from the game and a recommendation, then the vocabulary in the runtime first so the graph has something to compile to.
Goal
A level designer makes a level do things without writing code: walk into this volume and the red siren starts turning, its light flashes and a sound plays; press this switch and that door opens; when the timer runs out, spawn the zombies at the marked points. Today that logic is written in Swift, either in game code or through
USCBuilder, the fluent API of the built-in script system (USC): events (OnStart,OnUpdate,OnCollision:Tag, custom events), conditions, loops and delays, float, vector and bool math, and entity actions (translate, rotate, look at, play and stop animation, camera moves, key input), attached to an entity as aScriptComponentwith its script files saved with the scene. The editor lists the attached scripts with a trigger and a mode, and its feature flags already anticipate a "visual scripting / Blueprint-like system".The goal has two parts. First, the script system grows the vocabulary a level needs and does not have: trigger volumes, timers, spawn and destroy, lights and materials, sound, entity references and tags, variables that belong to the level, events sent between entities, and a faster interpreter (it compares instruction strings per script per entity per frame today). Second, a visual way to author it in the editor, like Unreal's Blueprints in spirit but deliberately smaller: a level designer connects a trigger to conditions and actions on a canvas, sees the graph light up while the scene plays, and the graph compiles to USC so the runtime stays the same on macOS, iOS and visionOS. Research first: we want the simplest model that covers level logic (an event sheet like Construct or GDevelop, a small node graph, or both), not Unreal's generality.
Status
Next steps