Orkuncakilkaya
377b6d1186
The two ideas the input revamp leads with, built in Ludic over the single-key poll every target already provides: - Action maps: gameplay reads named actions, not physical keys, so keys are rebindable and a scheme is data. Input.bind(action, key), Input.down/pressed(action), Input.rebind(action, from, to). - Deterministic record/replay: Input.poll() is the one per-frame input read; Input.record() captures the key each frame and Input.replay() feeds the tape back, so a run reproduces exactly — the seed of lockstep netcode. "Read input" and "read a recorded snapshot" are the same call. runtime/native/input.ludic (spliced when the new Input.* methods are used; pulls in core.ludic for rt_poll). emit_ns_call routes the methods to the @fn_input_* runtime; parse.ludic gates the splice. Seven docs/language pages; worked example + regression examples/library/input_actions.ludic (1 0 1 1 0 1 0). Full suite 75 passed, self-host fixpoint intact, no golden drift. The device layer (multi-key held, gamepads, touch, analog) needs a platform key-state backend and is tracked separately. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1 KiB
1 KiB
id: input-bind name: Input.bind category: input kind: namespace-method tokens: Input.bind sig: Input.bind(action: str, key: int) -> void tip: Bind a physical key to a named action, so gameplay reads the action, not the key. order: 1 ns: Input member: bind
Binds a physical key (a character code such as 'w' or ' ') to a named action, creating the action the first time it is named. Gameplay then reads the action with Input.down / Input.pressed instead of a raw key, which is what makes rebinding and alternate control schemes clean. Call it more than once with the same action to bind several keys to it; binding a key already on the action is a no-op. Actions are advanced once per frame by Input.poll.
program Bindings {
entry {
Input.bind("jump", ' ')
Input.bind("up", 'w')
Input.poll()
if Input.down("jump") { print(1) }
}
}