The tick is the heartbeat interval of the engine. Every N milliseconds onTick() is called, the game logic is computed, and a new frame is sent to the board. At 80 ms that is ~12.5 frames per second.
Why not as fast as possible?
The Kilterboard receives frames via Bluetooth (BLE). A single send operation takes 50–200 ms on Android/Chrome — and this is not deterministic; it varies with the device and system load.
How the engine handles this
Tick and BLE run asynchronously side by side. While BLE is still sending, the tick already computes the next frame. A small buffer (queue) holds that frame. When the queue is full, the oldest frame is dropped — not the newest. The board always shows the most current state, never a stale one.
Why a 100 ms tick would not be more stable
BLE latency varies between 50 ms and 200 ms. Even at 100 ms drops occur when BLE happens to take longer. The drop-oldest strategy is a more robust answer to variable BLE latency than any particular tick value.
What the tick actually affects
Tick rate and game speed are independent. A ball moving 20 px per tick is just as fast at 80 ms as a ball moving 15 px at 60 ms (both: 250 px/s). What changes: higher tick rate = more intermediate positions = smoother motion — but only until BLE becomes the bottleneck (~100 ms).
Recommendation: 80 ms is the tested value (tested on Pixel 7a, Chrome Android). Values below 60 ms bring no noticeable improvement because BLE becomes the bottleneck.