Input prediction

[elementbound]

✨ Description

Currently, RollbackSynchronizer doesn't simulate nodes it doesn't have input for. Once the input arrives, the game state is rolled back and the node is simulated.

It would be useful to be able to predict node behavior even if the input is missing, by predicting inputs.

Continues #54

Use case

Games could implement various input prediction mechanisms, instead of always relying on skipping simulation on missing inputs.

One common solution is input decay, where input values are weakened as the input ages. Something similar also works for racing games, where on missing inputs, the game assumes the player slowly lets go of the throttle.

Implementation notes

Rollback synchronizer should expose the following data during rollback:

• has_input() - Do we have input for the current tick?
• get_input_tick() - Which tick are we taking input from? Value differs from current tick if has_input() is false.
• get_input_age() - How old is the input data we're using? In ticks.

Games can use the above to implement their own input prediction mechanism however they'd like. To ease input prediction implementations, RollbackSynchronizer may expose a signal that's emitted after applying state and input for a given tick, but before simulating the tick. This way, input nodes can apply input prediction in their own code and expose data as necessary.

Nodes should still be able to opt-out of simulation if they determine that they can't predict anything with the current input. RollbackSynchronizer should provide a mechanism for this, e.g. by exposing a skip_recording(node). This would enable nodes to do the following:

func _rollback_tick(dt, tick, is_fresh):
    if not rollback_synchronizer.get_input_age() > 4:
        # Input too old, can't predict
        rollback_synchronizer.skip_recording(self)
        return

    # [...]

To avoid breaking games during a version upgrade, input prediction should be opt-in. A flag to toggle input prediction should be included either as a property of RollbackSynchronizer, or as a project setting.

Distribution

netfox core

[TheYellowArchitect]

get_history function is probably better to be split up, since there are only 2 buffers possible: State or Inputs, so no need to generalize the buffer parameter. With this, get_history for inputs should work with added logic to return a predicted input

P.S. You have no idea how hyped I am for this. It is the conclusion to all rollback - basically a full simulation running as if 0 ms. The only real problem with input prediction once it works, is the correction causing visual artifacts or being too snappy, but with input decay and tickinterpolator (and screen latency), it shouldn't be ever a problem, so I'm glad you brought up input decay, its a great technique

[elementbound]

get_history function is probably better to be split up, since there are only 2 buffers possible: State or Inputs, so no need to generalize the buffer parameter. With this, get_history for inputs should work with added logic to return a predicted input

Splitting _get_history into two methods, one for state and one for input, would just duplicate code. The method tries to get any state that's available in the buffer - if there's none, it will return the latest available at any given tick. So this can be used to get the latest input and predict from there.

---

P.S. You have no idea how hyped I am for this.

It's been a long time coming 😄