Orkuncakilkaya
3c7ec9b016
All checks were successful
docs / build-and-deploy (push) Successful in 2s
Rebuild the API Reference around one page per symbol and richer, verified content.
Pages & navigation
- One HTML page per symbol (kw-*, type-*, phase-*, screen-*, fn-*, annot-*, op-*)
instead of a single scrolling page; namespace overview pages (ns-screen …
ns-color) and a searchable index (api.html) with client-side fuzzy search.
- Sticky-header scroll offset (scroll-margin) so a jumped-to entry/param/color is
never hidden, plus a flash highlight on the scrolled-to target.
Deep linking in every snippet & example
- Namespace members split: `Screen`→namespace page, `fill_rectangle`→method page;
`Color`→palette page, `Charcoal`→its swatch — separately.
- Named arguments (`width:`) link to that parameter's anchor on the method page.
- Hover any token for a summary card built from the real API data (symbols.json).
Content & coverage
- Full authoritative surface documented from the compiler: every keyword, type,
the 6 phases (Start/Input/FixedUpdate/Update/LateUpdate/Render, each its own
page), all 22 annotations, namespace methods with parameter docs, builtins,
the world_* reflection ABI, networking, operators — 155 symbols.
- Longer, clearer explanations; "model"/"model instance" terminology, not "entity";
descriptive identifiers in every example (Position{column,row}, Velocity{delta_x,
delta_y}, Health{current,maximum}, Player/Enemy) — no Pos/Seg/x/dx.
- Accuracy fixes from compiler ground-truth: world_count() takes no arg,
world_query_next(property, cursor) arg order, event fields bind by name; dropped
`when` and `module` (not in the self-hosted parser).
Tooling
- inventory.json + check.py: coverage guard (every symbol has a page), duplicate-
token guard, and broken-link guard — fail CI so docs can't drift.
- validate.py: compiles every ```ludic example against bin/ludicc (158 compile).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1.6 KiB
1.6 KiB
| id | name | category | kind | tokens | sig | tip | order |
|---|---|---|---|---|---|---|---|
| kw-handler | handler | structure | keyword | handler | handler Name phase P { … } | A named block the engine runs each frame during phase P. | 3 |
A handler is a named block of behavior that the engine runs automatically during a given phase — the unit that turns your data into a game. A handler with no query runs once per phase tick; a handler with a @Queries annotation (or an inline for (…) in query […] loop) runs its body once per matching model instance, with each property bound by name and self() giving the current instance. Handlers are registered implicitly just by being declared, and you can pause one at runtime with disable Handler and bring it back with enable Handler. Keep behavior in handlers and keep data plain in properties — that separation is the whole point.
program Runner {
property Position { column: int = 0, row: int = 0 }
property Velocity { delta_x: int = 0, delta_y: int = 0 }
model Player { Position, Velocity }
handler Boot phase Start {
spawn Hero { Position { column: 0, row: 6 }; Velocity { delta_x: 1 } }
}
handler AdvancePositions phase Update {
for (position, velocity) in query [Position, Velocity, {Player}] {
position.column = position.column + velocity.delta_x
}
}
handler DrawWorld phase Render {
Screen.clear(Color.MidnightBlue)
for (position) in query [Position, {Player}] {
Screen.fill_rectangle(x: position.column * 16, y: position.row * 16, width: 16, height: 16, color: Color.LimeGreen)
}
Screen.show()
}
}