Adds the ECS hook issues #43 and #47 named as their real dependency: a system the *engine* owns, inserted into the frame loop over a component a game merely declares and carries — no `handler` wired. - runtime/native/systems.ludic: esys_spriteanim (SpriteAnim frame advance: loop/once/pingpong) and esys_motion (Motion value tween: linear/in/out/ in-out), both on the by-name reflection ABI, integer + deterministic. - backend: emit_engine_systems_for_phase inserts the calls after every user handler in a phase (auto-loop and the drivable tick helpers alike); uses_engine_systems() drives the systems.ludic splice, the world-table force-emit, and makes a component-only game count as a systems game. - A game that declares neither component is byte-for-byte unchanged. Worked example + regression: examples/library/anim_ecs.ludic. Full suite 73 passed, self-host C-free bootstrap fixpoint intact. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
715 B
715 B
bump: minor
type: feat
Engine-owned systems over user components (#43) — the ECS hook that runs a system automatically each frame over a component a game merely declares and carries, no handler wired. Declaring the well-known SpriteAnim { ticks, fps, frames, mode, frame } gives sprite-sheet frame animation (loop / once / ping-pong) that advances frame for free; Motion { ticks, dur, from, to, ease, value, done } gives value tweening (linear / in / out / in-out) that advances value. The systems stand on the reflection ABI, resolving fields by name, so they no-op cleanly when a component or field is absent and cost nothing in a game that declares neither — that build is byte-for-byte unchanged.