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

91–100 of 107 posts

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

#91

Post by gameswithgo »

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…

human can learn what the ai will think they will do and act differently to maximize the reality dissonance for the other player.

this is not fundamentally different than what we already do in these games though, which is to choose tactics that work to your advantage given how the game deals with lag.

client side hit detection? be the aggressor and do the moving into view and get milliseconds advantage to start shooting.

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

#92

Post by whateveracct »

CarVac wrote: post #89
zucker42 wrote: post #27

Earlier quoted context omitted.

AFAIK they didn't do anything special to save two frames, just a CRT (which is what's used on LAN) has 2 frames of lag.

Melee has 3 frames of lag on a CRT, none of which come from the CRT. They managed to pare it down to only one frame.

In a way, Melee shows that a couple of artificial frames of lag can be beneficial and allow for seamless online play on-par with LAN. Since the game is already one of the fastest & most reaction-oriented out there.

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

#93

Post by whateveracct »

DixieDev wrote: post #80
whateveracct wrote: post #15

Relevant: GGPO, the age-old gold standard of rollback netcode, was recently open-sourced! https://github.com/pond3r/ggpo I haven't used it myself yet - mostly because I'd want Haskell bindings first hah

Around the time GGPO's source was published, I wrote a very, very simple fighting game to test how to use it. Maybe of interest to those in here: https://gitlab.com/DixieDev/ggpo_example/-/blob/master/main....

This is a great example! Thanks for sharing.

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

#95

Post by formerly_proven »

esturk wrote: post #63

Does anyone know if rollback netcode works well in a 20+ player shooter game? I curious because the current craze of Battle Royals seems really taxing to the whole re-simulation of multiple frames within the window of a single frame. Without being any less subtle, games like Apex Legends is known for really bad server performance, latency, and among other things.

I didn't know the term rollback before, but it seems to be exactly the same thing as lag-compensation which is what's the standard in shooter games since Quake. These are usually not peer-to-peer, but use a central server instead; the server retroactively applies inputs from all players (within their latency window for obvious anti-cheating reasons) which are not dead, though some games don't have the latter restriction, which enables players to trade kills even with instantaneous hitscan.

It results in the usual problems (peeker's advantage and being teleported backwards when a high-ping player kills you while you are moving) though it is not obvious how you can work around these.

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

#96

Post by hrishi »

It's amazing how many comments suggest training a neutral net for prediction. Additional fitting through elo ratings I believe are suggested, as is dynamic tuning.

To me, having played games with rollback, this takes away one of the key benefits of simplistic rollback: predictability and consistency. Sure it's not the same as offline, but your brain gets pretty good at understanding when it happens and even at predicting it. If an opponent is stationary a few more frames than feels right, or keeps moving, you know to correct for an actions they've already sent - and it's a good estimation most of the time.

Over fitting with neural nets IMO removes this consistency without providing much benefit, plus if you've got a strong neural net you might as well train locally against that first.

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

#97

Post by Galanwe »

hrktb wrote: post #53
Galanwe wrote: post #40

Earlier quoted context omitted.

Not sure you would want the prediction to take non-dumb actions. You need to maintain the hypothesis of least surprise for the local player, otherwise you local player could start to act based on the wrongly predicted actions of the remote player, and that's even worst than nothing. For instance, say the local player tries to hit the remote one. If the prediction for the remote player is to evade, the local player ca…

> 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 repeated inputs does seem like a good strategy in this situation.

An other way of seeing it, is that if a player with 180APM realistically can only change inputs every 333ms, then with a remote input lag of 25ms (50ms ping / 2) there is just a 1/13 chance that an input change would occur in this time slice.

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

#98

Post by nightowl_games »

superjan wrote: post #61

It sounds like rollback could be used to cheat by artificially delaying your outgoing network traffic: the other player has less time to respond. But I doubt I’m the first to get that idea.

If your input is delayed then you have less time to respond too.

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

#100

Post by shaharz195 »

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 illegal game state of local player executing the move against opponent in state B.

The situation is similar to a write-write conflict in a multi-leader DB.

Post reply on HN