How to handle player input with fixed rate variable fps time step?

Question

I've made a system which uses the ideas from "Fix your Time Step" in order update physics. I'm having trouble finding standard methods for dealing with this when user input affects player movement outside of a time-step.

If we want to integrate player movement within the "fixed time step, variable fps" system, I guess I would have to queue up player actions somehow, when accumulation hasn't yet completed. But then how do I integrate several different player actions within said timestep? IE lets say within timestep of N milliseconds, the player executes a move forward, move right and move backwards, where there is an infinite collidable wall in front.

• I could always calculate the last input, but in this case, it wouldn't be correct to do so. The player actually should be blocked by the wall, and then moving right and back would move them to the right, and back, to the right of where only processing the last input would lead.

• Similarly, if all movement was accounted for together, it might result in a player having an impossible vector for the final position, but if all moves were taken independently, there might have been a valid path (ie around a corner).

• If I process all inputs then the player made during the time-step, it could conceivably be costly if they made a million tiny movements (collision check at each movement), though with exact physics (as far as a fixed time step simulation is concerned).

• Even if we thought the last bullet wasn't that bad, as soon as you add multiple players to the equation, it starts looking really bad, especially with a server.

Are my only options to process all actions or only process a subset of them?

Answer 1

I most often encounter this in the context of Unity, which has the following attributes:

1. Input is checked once per displayed frame, before any of that frame's fixed/variable timestep updates

2. Input is interpreted as one flat state for the entirety of the current display frame, not a queue of events

   • Each logical button has three independent boolean states:

     • Is currently down as of this input check
     • Has transitioned from up to down since last input check
     • Has transitioned from down to up since last input check

     (These are independent because a button could have been pressed & released all in the span of a single long frame)

   • Each logical analog axis has a current value as of this input check

3. Zero or more FixedUpdate & Physics steps run to account for the game time passed

   • Here we first compute new physics forces / velocities in FixedUpdate routines...

   • ...then ask the physics engine to tick the simulation forward one fixed time step, integrating accelerations & velocities into changes in position and resolving collisions

   • ...then handle any trigger/collision events that occurred as a result of that integration.

4. A variable-length Update/LateUpdate runs after the fixed steps & before rendering

   • Here we do any last-minute/display-only updates before the frame is rendered - particularly VFX, animation, and UI changes to reflect the most recent simulation state.

5. The frame is rendered and presented

In a situation like this, my usual solution is this:

1. Introduce an EarlyUpdate method that runs once for each display frame, after the input check and before any of the fixed steps (if any) and any of the variable-length updates. (In Unity when not using the scriptable game loop, I emulate this behaviour)

   Here, we process any instantaneous input events like button pressed / released - applying an upward impulse the moment the jump button is pressed is one common example. These are inputs that happen only for a moment: the button transitions from up to down in one specific frame. It doesn't keep happening on future frames, unless I release the button and press it again, in which case it's a new press.

   This way we ensure these events are processed exactly once - so we don't miss inputs on frames that get no fixed updates, or double-process inputs on frames that get multiple fixed updates.

   By handling this before the fixed steps, we minimize the perceived latency. In the example of a jump input, the outcome might be setting an upward velocity on the player. So doing this before the fixed steps gives the physics engine a chance to integrate this velocity change into a position change the player can observe when we render the frame. Even on frames where we get no fixed step, we can render a particle puff or change in the character's animation frame to give the player immediate feedback that their input was heard.

   By processing this at the very beginning of the frame, rather than interleaved between fixed updates according to the timestamp on each input event, we're being maximally charitable to the player, potentially shaving fractions of a frame off their reaction time, for the sake of making the controls feel as tight & responsive as we can.

2. Process any continuous inputs in each FixedUpdate step. These are things like button holds (including holding a jump for extra upward force after the initial launch impulse), or holding a trigger / analog stick at a particular angle.

   Here the input state is comparatively long-lived (the player will often hold it at a similar value for several display frames), so we don't miss out if we skip it on short frames where we have no fixed steps: we can safely resume handling the hold on the next frame's fixed step. And we can safely handle the same continuous value multiple times on long frames where we have multiple fixed steps - it's no worse than the player holding the trigger one fixed step longer.

   By handling these in our fixed step, we ensure the simulation behaviour does not depend on the player's display framerate. I'll move at the same speed, and fall in the same arc, at 30, 60, or 120 fps. The display framerate just determines the sampling frequency of new hold values. As long as we're rendering at 30 fps+, this will be enough temporal resolution to pull off even fairly intricate analog control inputs sequences. (Keeping in mind that human reaction time is ~5x longer than a display frame even at a low of 30 fps)

This is an approximation, of course. Arguably, we could be more "accurate" by repeatedly checking for input, time-stamping each input event, and processing the inputs in a queue within the fixed step to which each one logically belongs. The upshot of doing that though is most often going to be delaying a user's input further (since it may well have arrived while we were doing rendering work for this frame, after our next fixed step logically ended, and will now be delayed until our second or third fixed step of the next frame instead of the first) and complexifying our code, for little to no benefit to the perception of accurate sequencing of events. So I think it's a simplification worth making.

Answer 2

While Fixing your time step, you should Free your draw step so that positions are interpolated between logic frames. Input runs at the logic rate, and drawing runs at the refresh rate. Separate drawing and logic. You can have an event queue for two timers that can be set to the refresh and logic rate then monitor it for events. If logic or rendering takes too long, skip visual frames as necessary, or force game time to slow down.

Edit3 What I was getting at was that there's nothing special you need to do to handle this other than handle events in the order they occur.

Run your logic timer at whatever rate you want within reason. This is when you update the game state based on dV or dA or however you want to integrate. With overlap based collision this is also when you run collision detection. Now the difficulty I believe you were having was with "when to apply input based state changes". I believe you were questioning whether to aggregate input per logic update. Logic usually runs fast enough that you don't get more than one input event but in the case of mouse input you might get several move events within a relatively slow logic update. It seems the real question is what to do with the input events in between logic updates. Do you feel it is necessary to apply the elapsed time to them? I have never in practice needed such precision that input events can't just be applied directly and consecutively and take effect on the next logic frame.

Are your logic updates so infrequent or so expensive that this actually caused problems in real life?