Hacker News Reader

Comment by _--__--__ | Hacker News Reader

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).

View on HN

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.

Theres some missing information here. A "rollback that doesn't do anything" shouldn't be noticeable to the user. It would only be noticeable if the game simulation can't keep up with the # of frames it's being asked to simulate. And in street fighter, the simulation is ridiculously simple. There should be no reason why street fighter wouldn't be able to "rollback and resimulate" dozens if not hundreds of times per frame. There's no way that game is CPU bound... Am I missing something?

I think you are underestimating the per frame computation cost or massively overestimating the base model PS4. Remember that all fighting games have to lock 60fps, 16ms is not a ton of time for the handoff from input interpreter (SF has to parse backwards over the past several frames to see if a forward input is completing a quarter circle, double quarter circle, dash, etc) > game state update tick > graphical and sfx update pipeline. The issue with clock syncing meant that the worse your machine was, the more your opponent would roll back and the bigger the rollback windows would be because every single frame of your inputs would come late.

Here's an example of the constant one sided rollback: https://www.youtube.com/watch?v=aSB_JlJK_Ks

and an example of how players were aware that mashing caused frequent rollbacks: https://youtu.be/_jpg-ZiE70c?t=105

Eventually PC players learned that they could "fix" this by alt-tabbing out of the game, taking away dedicated GPU processing so they could be the peer that was falling behind.

I can't really speak for Street Fighter V, but I can say that Easel would assign command delay to the person who is introducing it. So if a person is somehow forcing their inputs to arrive later than they should, they would be assigned more input latency so that the other players would be unaffected. Easel also has a lag spike protection system where the server will just forcibly reschedule inputs if they arrive really late for some reason.

Yeah, most of these are relatively solved problems, but they are nontrivial enough that one of the industry giants couldn't get it right on its first few tries.

I don't think I am underestimating anything. Think about how simple SFV's simulation is compared to Battlefield 4. Way more players, dynamic objects, huge map, players leaving and joining, shooting projectiles, etc. SFV's simulation is so basic, is fundamentally the same game as SF2 that ran on the super Nintendo.

As far as overestimating the base model PS4, I've shipped rollback multiplayer games that support 32 players that run on Android Web Browsers. I would love to see a frame profiler of SFV. I have years of experience optimizing multiplayer games to run on far worse platforms than the PS4. 16ms is a lot of time.

I bet I could make SFV's simulation run in less than a millisecond on an Android phone from Walmart. It couldn't render on that device, but it could run the raw simulation.

I wonder if SAT solvers could prove the maximum "reach" of inputs into the state...

Reply on news.ycombinator.com