Respond to input

A press is a request. The game chooses what that request does to movement. Start with a rule that changes velocity immediately, then compare speed without introducing acceleration.

Both ships receive the same input. Changing the slider resets them. Open “Inspect one update” to pause and trace a single step. This is a browser model, not a measurement of a particular retro computer.

Movement rule source (JavaScript)

Move, release, reverse

Hold right, then let go. Both ships stop at once. Hold left while moving right: both reverse on the next update. Use Run same input to compare a recorded sequence; it sends the same directions for the same durations to both ships.

The reference travels at 120 units per second. Your ship starts at 240. Change its top speed and repeat. You are changing how far it travels in a given time, while keeping the response rule the same.

Give the request a number

Use −1 for left, 0 for released, and +1 for right. If both directions are held, this experiment treats them as released. Velocity combines speed and direction: +240 means right at 240 units per second; −240 means left at the same speed.

LET velocity = input * topSpeed
LET position = position + velocity * elapsedSeconds

The experiment updates in steps of 1/60 second. With right held and a top speed of 240, each update adds 240 × 1/60 = 4 units to position. From x = 120, the next position is 124.

Open Inspect one update, leave Next input set to Right, and step once after resetting. The trace shows your ship’s old and new values. Choose Released and step again: velocity becomes zero, so position stays at 124.

Choose what immediate means

A cursor or a tightly controlled paddle may benefit from stopping exactly when the player releases. A vehicle may need momentum to make steering interesting. Neither choice follows automatically from the input device.

“Immediate” here means the next simulation update. Input hardware, browser scheduling and drawing still take time. This comparison is about the movement rule, not a claim of zero end-to-end latency.

The 1/60-second step is this experiment’s simulation clock. It is not a promise that the screen refreshes, input arrives or sound updates at that same rate. In a small machine game we may start with one update per display frame; we separate those jobs when a real timing requirement calls for it. The elapsedSeconds here is a fixed step, not a requirement to use variable elapsed time in every game.

The next lesson changes acceleration while retaining instant stopping, so we can identify which difference it causes.