PokerInput

Tap F to fold, V to call, R to raise — but only when it's actually your turn. PokerInput turns the keyboard into the same bus intent the HUD buttons emit, gated so a stray keypress between turns does nothing.

What it does

PokerInput is the human seat's keyboard. A keypress should fire an action only when it's the player's turn AND that action is on the table — so the core (PokerInput.core) owns two pure things: a configurable KeyboardEvent.code → intent map, and a tiny turn-gate state machine.

resolveKey(code, gate, bindings) is the whole decision. The deal code always resolves to a deal — ungated, since the director ignores a deal when it isn't awaiting one. An action code resolves only when that action is in the live allowed set. Everything else swallows the key.

The gate is fed by the PACED prompt poker.display.actionRequired from the TurnPacer — not the raw poker.actionRequired — so the keyboard goes live only after the opponents have visibly acted. openGate records the seat and its offered actions; the gate closes the instant the human's turn ends: a paced poker.display.turn handoff, the director's poker.currentTurn going null or to another seat, a poker.actionTaken for the human, or the key the System itself just submitted.

The thin PokerInputSystem is the driver. It attaches a window keydown listener in onInitialize (guarded by typeof window, detached in onShutdown — the PlayerInput pattern), feeds those signals into the gate, and emits poker.actionSubmitted { type } for a legal action key — the exact event PokerBetting consumes from the HUD buttons — or pokerTable.deal {} for the deal key. No 3D imports: only the browser keyboard and the bus.

Use it in a scene

Seat one PokerInput per table and name the human's seat id.

{
  "UI": {
    "components": {
      "PokerInput": { "humanSeatId": "player" }
    }
  }
}

It wires itself — once the TurnPacer's prompt reaches the human, the keys go live.

Default keys

The reference game maps Space to bet; here Space is reserved for the deal, so bet moves to B.

Props

Events

Notes

• The Component holds the serializable config; the System holds the live gate. So serialize() round-trips { enabled, humanSeatId, keyBindings } and nothing transient.
• enabled is the inherited Component accessor (it emits the enabled/disabled events on change) — the constructor assigns through the setter rather than shadowing it.
• After a legal action emits, the System closes the gate immediately, so the same key can't double-submit before the next paced prompt arrives.