Prediction (Rollback Netcode)
The speed of light is not as fast as we would like.
In a simple world, a game would be able to wait until all inputs are received before simulating the next tick. However, when players are far away from each other, there is a delay between when the player sends an action and when another receives it. This delay is called latency, and it can make games feel unresponsive. Imaging pressing the jump button and your character not jumping immediately. Many techniques exist to try to make games feel responsive even when there is latency. Easel uses rollback netcode.
Rollback netcode
Rollback netcode allows the game to present a predicted game state, before all inputs have been received. Your character can be shown to jump immediately, without needing to wait for all inputs to arrive. Later on when all inputs finally arrive, the game will correct itself. It does this by rolling back the game to the point where the missing inputs occurred, and then re-simulating the game with the complete set of inputs.
It turns out that, in practice, the game can predict the future quite accurately. This is because while many games are simulated at 60 ticks per second, players only really provide input a few times a second. This makes rollback netcode a good fit for many games.
Rubberbanding
Easel uses rubberbanding to smooth out the differences between the predicted game state and the actual game state. Instead of sudden jumps which may be jarring, characters will smoothly move to their correct positions. These corrections sometimes are so subtle they become unnoticeable.
To ensure Easel can rubberband all graphics in your game,
make sure to assign an Entity with a Body, rather than a Vector,
to the pos parameter when using Spark, Streak or Swoop.
This way the graphics can track the position of the entity which may be smoothed out by Easel.
Determinism
One of the greatest barriers to achieving rollback netcode is that a game must be deterministic. That means, given the same sequence of inputs, the game must always produce the same series of states. If the developer fails to make even a single part of the game deterministic, the game will desynchronize, and so it is easy to make a mistake when implementing rollback netcode. However, because Easel games are written in the Easel programming language, Easel controls the execution of your game and ensures all game logic is executed in a deterministic way, without any additional effort from the developer.
Easel games are sometimes made up of thousands of concurrently-executing behaviors. Normally concurrent programming models are difficult to synchronize as all the concurrent threads must be deterministically executed, and they must also be part of the snapshot and rollback process. Easel makes this all possible because Easel games are made in the Easel programming language which was designed from the ground up to support determinism and rollback.