Comment by _--__--__
I'm curious how your engine decides to trigger rollbacks without explicit knowledge of which parts of the game state each input can actually affect. Naively rolling back on every missed input can and will be abused - in early versions of Street Fighter V players found out that while being comboed you could churn out inputs as fast as possible to cause rollbacks for your opponent, even though none of those inputs could actually do anything (this was made worse by other issues with that game's inability to keep opponent game clocks synced and constant one-sided rollbacks).
Yes, it's true Easel does rollback on every input. I may be able to improve this. One great thing about controlling the programming language is there are a lot more places I can hook into for things like this. For example, Easel does detect at compile time which types inputs are used somewhere in the codebase and only sends those across the network.
Easel constantly synchronises the clocks (there's an interesting algorithm for this which I will write up at some point). It also adaptively assigns two different kinds of delay to every client - command delay and display delay. Command delay is related to how much lag you are introducing into the game. Basically people take on their own lag. It can be different amounts for different people in the game. The display delay is where the rollback netcode kicks in. It keeps track of how much rollback your computer can handle imperceptibly. If your computer can't handle it, then you won't get as much rollback (and will just experience more input latency). But in either case, whatever number it picks, it should be smooth.