6/ Save the .luau and every running instance picks up the change in place, no restart. No compiler in the loop. Pre-alpha, solo dev.

Get notified at launch → ereshengine.org?utm_source=b...

#rustlang #luau #indietech

5/ Limits, plainly: a runtime error stops that script instance until you save the file again, nothing else goes down. No file or network access from scripts. No new component types either: Rust owns those, scripts read and write them.

4/ A write from a script is a real ECS write: it marks the component changed, so change detection, transform propagation and physics react as if a Rust system had done it. One shortcut only: self.transform is resolved by type, because every script touches it every frame.

3/ The part I like: self.entity:get("Light") looks up "Light" in the reflection registry, the same registry the inspector, the scene file and undo use. Add a Health component in Rust and scripts can use it right away. No glue code per component, anywhere.

2/ The script declares its own inspector fields. speed_deg = 45 and axis = vec3(0, 1, 0) in its properties block become two editable fields in the inspector, saved per instance in the scene. Tweak the speed without opening the file.

1/ A script is a .luau file that returns a few callbacks: on_start, on_update, on_fixed_update. You attach it to an entity the way you attach a Mesh or a Light: Add Component → Script, pick the file. It is saved in the scene file with everything else.

Get notified at launch → ereshengine.org?utm_source=b...

6/ This is live in Eresh for keyboard and mouse. Gamepad support and runtime rebinding are still planned. Pre-alpha means saying that plainly. Action-first already makes gameplay much less tied to a device.

#gamedev #indiedev #rustlang #indietech

5/ Physics runs on fixed ticks, display frames do not: one frame can drive zero physics steps or several. Eresh latches action edges across that gap, so a quick Jump press lands exactly once. It neither vanishes on a zero-step frame nor fires twice on a multi-step one.

4/ Contexts make modes explicit. Gameplay can be the base context; a higher-priority pause menu can consume controls or block lower contexts. A key press then does one intentional thing.

3/ One Move action can use a WASD composite without making movement code assemble four keys. Modifiers live with the binding too, so normalizing diagonal movement is data, not a patch in every controller.

2/ An action model names intent once: Move, Jump, Fire. Bindings translate physical controls into typed values, such as a button for Jump or a 2D vector for Move. Game code reads actions, not hardware.

1/ Binding a movement system to W means that system knows about one keyboard key, not the player's intent. The moment controls change, gameplay code has to change too.