Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How fighting games use delay-based and rollback netcode (2019)

ki.infil.net

Post reply on HN
Print view View original

101–107 of 107 posts

Re: How fighting games use delay-based and rollback netcode (2019)

#101

Post by Kinrany »

shaharz195 wrote: post #100

Article didn’t mention conflicts with the rollback approach, but aren’t there are cases where a history re-write causes the local player’s past input to be illegal? For example, game rules state a player can only make a move when opponents is in state A. Local player sees a prediction of Remote player in state A and executes the move, but really the player was in state B. When the rollback happens, there is an illega…

I think the inputs should be sent at the level independent from context: "player pressed SPACE", not "player jumped".

Re: How fighting games use delay-based and rollback netcode (2019)

#102

Post by hrktb »

Galanwe wrote: post #97
hrktb wrote: post #53

Earlier quoted context omitted.

> Since players don't change inputs very fast, just replicating the last input is in fact 99.9% accurate. Sadly, fighting games, and to the same extent FPS casually break that assumption. 1s is an eternity in a close fight, and players don’t just react, they also read ahead and align inputs based on the situation they expect, regardless of the speed of the game. Commands will be entered in as low as one to three fram…

> Sadly, fighting games, and to the same extent FPS casually break that assumption. 1s is an eternity in a close fight. Sure, but that's nothing compared to the speed of just polling inputs. I would assume a pro player in a fighting game to have what, say 180 APM at peak ? That's 3 actions per second, so if we assume a uniform holding time and a 60 FPS game that's 1 input change every 20 polled inputs. Assuming repea…

I actually agree that assuming input didn’t change is the most pragmatical course of action, as even if the input changed I’d assume there’s just no way to efficiently anticipate it at this point. With that strategy the best case scenario is optimal, and worse case scenario is not worse than for any other option.

On the 1 change every 20 polls calculation, it’s true locally, but for a ping of 200ms for instance, 333ms of loss is ‘only’ 3 times the one way trip time. I think momentarily losing 3 times the connection speed happens often enough, and of course the bar for losing an actual action due to lag is yet lower for intercontinental games.

Re: How fighting games use delay-based and rollback netcode (2019)

#103

Post by firedark60 »

thewarrior wrote: post #29

This piece was really interesting. That you can hide network delays by building a “fake” model of the other player that replicates what a real player would do and rolling back when this prediction fails. So you can train some neural nets on what players do in such situations and you get a certain accuracy. And yet you can keep making this “fake” player better and better until it’s indistinguishable from fighting a hu…

You also have the issue of performance. If you have a NN churning predicting every frame what your remote player would do, it would add even more load to that 16ms loop of calculating and rendering everything else. At best maybe some very basic ML might help, but the "assume no input changed" seems to be best guess from the sounds of empirical testing in the article.

Re: How fighting games use delay-based and rollback netcode (2019)

#104

Post by nwmcsween »

All these comments and this article relies on things that will actively break user experience, why not just limit the players to 'good' connections and have somewhat simple netcode? Having another player 'fast forward' with variable animations sounds like a recipe for frustration

Re: How fighting games use delay-based and rollback netcode (2019)

#105

Post by mold-monkey »

chupasaurus wrote: post #88
meheleventyone wrote: post #83

Earlier quoted context omitted.

Yes but the game is deterministic and trades inputs which are rewound and resimulated. I don’t think the interesting part of rollback net code in fighting games is that it’s usually peer-to-peer. There’s a GDC talk on how it works here: https://www.youtube.com/watch?v=W3aieHjyNvw

I know how it works. The only major difference for FPS is that there are multiple inputs inside a frame which have to be precisely timed. All the prediction models are either deceiving for a false reaction or the same "keep doing the previous action".

What you described is how sensitive a fighting game is. Which need to be 60FPS because moves are made within that limit with startup frames, active frames and move recovery on block vs whiff. The only FPSs that come close to FG levels of reaction/inputs is Quake, Unreal and maybe CSGO.

Re: How fighting games use delay-based and rollback netcode (2019)

#106

Post by setr »

thaumasiotes wrote: post #71
shalmanese wrote: post #49

Earlier quoted context omitted.

There's only a few key moments where players need to be unpredictable to win a game. Almost all the rest of the time they are executing predictable consequences of those unpredictable choices. ie: imagine a player running to a ledge spanning a gap. The "naive" interpolation would be they continue running and fall off the ledge and die. A smarter system would realize that almost all the times they've run to the edge o…

> They could even jump at the median of all of your previous jumping choices and then lerp your position over time so you land at the correct point based on your actual jump. I assume the interpolation relates to something displayed on the screen? The idea makes me kind of uncomfortable, because it seems like it would confuse players by causing identical jumps to display different results. If you only learn about jum…

This is intended for viewing some other (remote) player's jump (during a disconnect). It wouldn't touch your own (local) jump.

It's the equivalent of letting an AI take over the player when the player drops out, with the AI intended to replicate the dropped-player's playstyle until he rejoins. In short enough time-spans (disconnect-duration) you have some hope of being exactly correct.

And if you were 100% correct at predicting the remove player, all of the time, you don't even need the other player --- you could just run the AI and stay offline, and just "pretend" there's another player.

Re: How fighting games use delay-based and rollback netcode (2019)

#107

Post by ashkankiani »

thewarrior wrote: post #29

This piece was really interesting. That you can hide network delays by building a “fake” model of the other player that replicates what a real player would do and rolling back when this prediction fails. So you can train some neural nets on what players do in such situations and you get a certain accuracy. And yet you can keep making this “fake” player better and better until it’s indistinguishable from fighting a hu…

Why would you bother training neural nets? They already found a solution that can be computed in literally 0 cpu time that works for >90% of the cases (their theoretical model was an above average active player moving 5 times in a second, which is 5 frames of input you can't predict as being the same as the previous, which is 8% of the time).

Why would you waste time trying to shove neural nets into a solution which has such amazing properties? It really terrifies me that that's the first place you went to.

Post reply on HN