Input, Runtime, And Scripting Components

Last verified: 2026-07-09

TimerComponent

Use Timer for repeated or one-shot runtime events. Fields control enabled state, timer key, interval seconds, repeating behavior, and maximum firing count.

Gotcha: use a distinct timerKey when scripts need to tell timers apart.

ScriptComponent

Use Script to attach behavior. Fields control the script reference, enabled state, and typed exposed config payload. The script manifest/IR owns event subscriptions.

Gotcha: ScriptComponent is server-only in replication because scripts are authoritative runtime behavior, not public client state.

InputProfileComponent

The sole input component. It declares named actions, action policy, prediction mode, and action-owned bindings in one versioned profile.

Gotcha: bindings are nested under their action so an action-key mismatch cannot be represented. Use stable semantic keys such as player.move, player.jump, or player.interact.

The profile is owner-only in replication because bindings can contain player-private input data. Keyboard, mouse, gamepad, and touch are the launch device set.

The initial authored context is gameplay. Menus and other local UI contexts are pushed and popped in the client runtime and are not authored ECS state.

Removed Input Contracts

InputActionDeclarationComponent, InputBindingSetComponent, and InputContextStackComponent exist only as registered migration inputs. New authoring and steady-state runtime code must emit and consume InputProfileComponent.