Netcode Explained: The GOAT Article for Understanding Fighting Game Netcode Now Exists; Read it 

We have time travel now thanks to accelerating playback speed

People like long videos

Dude, I watched it while washing dishes. Everybody that plays fighting games and is interested probably has time somewhere to watch this (barring they got kids or something that constantly needs their attention)

@@djhero0071 There's a video bookmarking feature. As long as you watch the video while signed in, you can watch it in small bursts of a few minutes at a time, close the window when your break's over, and then restart just a minute or so from where you stopped last so your memory can be refreshed. Where there's a will, there's a way.

Time to call in the hentai experts who learned it for their doujins

@Jonas Stattin No u

@Jonas Stattin Sugoi desu ne

The game is too far into development- GG2020 will not have rollback and will suck online just like all other Arcsys games.

@@CF565 I wish I could have the hope it has something to that degree. ;-;

Only people that would defend delay based would most likely be defensive players.

I don't think all defenders of delay based will even bother to read...

There should be a yearly meeting of every fighting game dev coming together sharing Netcode advantages

melty blood with cccaster is insanely good, imo better than netplay experience on fightcade

And online sucks on fightcade tbh

MvC2 isn't on fightcade tho, but I I think MVC1 is

SaltyLuigi fightcade is fine. Obviously it never quite lived up to the OG GGPO matchmaking client, but it still works about as intended

fightcade isn't even past 5 years? mvc2??

Damn, Sajam’s out here trying to sell a free product

@@letmeshowumypkmn He takes his job very seriously

Agreed, although as someone who can read Japanese at a mediocre level, I can say that when running the article through Google Translate it is able to gracefully handle the majority of it. It being able to convey the primary meaning as long as the reader keeps in mind it is from a translation algorithm. It can certainly be understood since the articles aim isn't to be extremely technical but convey the primary concept to all readers.

negating local input lag is an interesting use of rollback, but if im understanding correctly then 0 input latency is the best runahead can do without visual teleportation. That said, going into the negatives and allowing it to have rollback-esque visual popping could be a viable solution to make game streaming feel less gross. I'm interested to see if that's what google is planning to do.

I would be a nuissance with my Urals 70-80 ping, but I've frequently have players from Arabian Peninsula with 120-200 and played some matches with people from South Africa (and that was in Rising Star so they played decent with 200+ ping!!!), all on European servers.

it would make the game terrible. You wouldn't be able to actually react to anything on screen and everything would become a guess which is bad because there is already delay because it's a physics based game.

Thomas Vu read it bro

That is what's happening in the video examples, yes. In the case of Jago's overhead (the 0, 1, 2, 3f example), the skipped 3 frames are pretty unnoticeable but it is happening. Even the first video on the rollback page that shows Jago's MP being rolled back is pretty hard to notice, and that's 3 frames off a 7 frame move.

Same

@@dusantapavicki8241 TK 7 is 3

@@andriy_tato read carefully

@@doncinati7644 read well

Did you just?..........

Any in-engine predictive solution should be the best. Hard to say over time, but Google Stadia's negative latency won't have the benefit of being directly interfaced with the game logic, and it's likely to be a blow up until it's able to aggregate enough data to make predictions on the game being played (unless they specifically optimize it for a specific game). How long that will take, who knows.

Negative Latency™ is a Google try to cover up a delay-based netcode.

@@Amagys a later comment by pokeshark brought up the idea of "runahead," a feature in retroarch that is intended to negate local input lag. it does this by effectively treating the current gamestate as if it was just rolled back to, and resimulates forward however many frames. allowing this to simulate even further forward would introduce some visual popping, but could be a viable solution make game streaming feel closer to local play.

@@Ringating That's a cool feature for retroarch, but also has the benefit of being able to have access to the gamestate and game logic by virtue of being an emulator. I'm just taking a guess on Stadia, but they're probably not emulating their library of games; they could of course work with developers to develop such things. Also, input lag introduced by emulation is a different ball game than input delay introduced via game streaming. Which is inherently round trip based, meaning you press the button, server acknowledges it and the game interprets it--rendering to video which the server will compress and send to you. There's also factors like distance, internet speed, router hardware, and yes being on WiFi can dramatically impact these things, just like in a fighting game dropping packets or frames can ultimately cause another world of problems for Stadia than anything locally based. Their technology better be out of this world good at prediction or it's going to fall flat on it's face as marketing blow hard.

GGPO > NEGATIVE LATENCY =)

I think thats for special cancels and stuff like if you do crouching light and then hadouken or tatsu. Ggpo has less stuff to predict bc you can only do a few things to follow up the crouching light. If you try cLK to cHK that wont work thats why rollback ignores that input bc it wont do anything even if it rollsback in time and input the cHK.

No, because those same inputs would be treated the same way if played offline. People *do* perform OSes using this stuff (that's basically what a buffer is -- the special cancel inputs are ignored by the system on a whiffed move), but there are no "rollback-specific OSes". At the best of times, rollback can do no more than simulate the offline game.

@@Infil ok, thanks for the explination :)

They are behind in game development because they are so focused on consoles and focusing on their own thing in Japan and ignoring rest of the world. this is especially noticeable in in fighting games. Just look at fighting games that you can find on PC. They are wilfully missing opportunity to make more money. New game for arcsys gran blue versus is not even confirmed for PC and they are not even looking into cross play and way to grow up their gaming communities, instead they constantly split it by releasing games at different times at different platforms and regions. t is amazing to me that fighting games never even got to try something like f2p model all these years that fact alone just goes to show how slow it is. Then they wonder why they are not making that much money in their fighting games when in reality they are not even trying to reach audience.

@@MarkoLomovic KI did f2p.

no.

it advances after rolling back in order to bring the local player back up to sync with the remote player. if it instead just rolled back and played from there, the remote player would also have to jump back in order for them to remain synchronized. In both the local and remote players' cases, they'd lose any inputs that got rolled back, which would feel gross and could very easily ruin execution on stuff that doesn't even have any player interaction, like combos. One of the main upsides of rollback is that input timings will always be the same for those types of situations.

@@Ringating What I was thinking would be to rollback both and replay the inputs in a way that they are allowed to be replaced to correct actions for the real outcome. Scenarios with no player interaction would not be a problem as per the prediction system avoiding rollbacks.

@@TomFooleryPlusR I'm not clear how your proposed system would behave. Does "rollback both" mean both clients would need to synchronize a rollback? Does "replay the inputs" mean frame-by-frame so the players can see it, or does it mean within the duration of a single frame (i.e. the same way regular rollback re-simulates forward)?

@@Ringating As you said, the remote player would also have to roll back. The replay would be frame by frame, as the goal would be to make animations you need to react to visible from the beginning.

@@TomFooleryPlusR ignoring the challenge of scheduling a synchronized rollback for both clients, it sounds like the game would have to go back and replay frames every time there's a rollback. this would mean both characters would be frequently teleporting back in time several frames, since rollbacks occur pretty much whenever inputs change state. the reason rollback simulates all the way forward again within the span of one frame is so that your own character never operates at a different rate than it would when playing normally/offline. it's true that this will often result in animations losing some of their starting frames, but for playability's sake this is preferable to teleporting back in time.

No its I, am here. Saitama shounen

reactions with rollback netcode should be no harder than they'd be with delay based netcode. with L frames of latency and R frames to react: *- delay:* attack animation starts (on frame 0), you react (on frame R), your input registers after a delay (on frame R+L) *- rollback:* attack animation starts remotely/invisibly (on frame 0), you see the shortened attack (on frame L), you react (on frame R+L), your input registers instantly (on frame R+L) this shows that the difficulty of reactions should theoretically be the same in both. in practice, a lot of attack animations aren't very noticeable in their early startup frames anyway, so with rollback you'll often be losing info that wasn't going to affect your reaction regardless.

There's no teleporting at all in delay-based; the game is either visually smooth when inputs arrive on time, or it pauses and chugs when they don't. Teleporting only happens in rollback when a prediction is incorrect and the new inputs change the game state somehow. This usually happens on movement (we predicted he would keep walking forward, but he didn't, so we roll back and change his movement a bit), and if you combine delay + rollback as all modern rollback games do, you'll only get this teleporting when the lag exceeds some threshold.

how far can you move in like 3 frames bro. it will only teleport if you timed changing directions with a lag spike

pedro avila the problem plagues both communities.... Nintendo is a Japanese developer

Smash Ultimate and Smash 4 in particular are partially developed by Bandai Namco, no doubt also responsible for the delay netcode in recent Tekken games including 7.

that would be 6 fps

16.6 IT'S 1000/60 =)

While you're correct, I think the distinction between the *inputs* never being lost (vs the intended effect if your input sometimes being rolled back) is really important. Inputs being straight up lost is so much more detrimental. Also, think about the scenario where you press MP but get counter hit by a jab. Since neither of these moves are reactable, in an offline game you just see the end result of you being counter hit. In a rollback game, you might see your MP make contact with your opponent (block or hit) for 1 or 2 frames before a rollback occurs into you getting hit. But because rollback works off a single clock sync, the reality is, both these situations are the same. You actually pressed your MP too late according to the "global sync", even if your game temporarily lied to you about that, so you deserve to be counter hit. This would only suck if your reactions changed your inputs, which can happen on rare occasions, but definitely does not happen in the vast majority of rollback cases.

@@Infil I agree with the idea that both players are beholden to the same "single clock sync," but these scenarios where the rollback could result in the player reacting to the wrong visual feedback are the concerning/interesting ones (though I'm not arguing that pure delay handles them any better). One potentially common scenario is hit-confirming. If the defender blocks during the last handful of frames where it's possible, the attacker will briefly see their attack hit. The moment of impact is when the most visual feedback occurs, which makes it even more likely that good players will have made their reaction/decision to hit-confirm before they can recognize that the hit didn't actually connect. One solution to this is to add startup frames to blocking. Though it would make defense slightly harder, it would increase the range of latencies that will never have to deal with rolled-back hit impact effects. This would have far reaching balance implications, ofc, but it may be worth considering in games that are designed for primarily online play. edit: also, sajam's first video that brought up netcode (around the end of august) led to me watching NRS's gdc talk on rollback, which led to me making a prototype to test out the concept. check it out if you like: whiffpunish.com/netcode

If you properly code the games rules into rollback then it shouldn't.

No, why would it be different

Were truer words ever spoken?

I noticed something though. Disregarding fightcade, I noticed most games that have rollback that have released to public tend to be games in which there's target combos or revolver combos. Not so much games with strict single button press combos. Not trying to doubt rollback, just its ease of implementation. Would rollback work in games like Tekken where there's strict juggle timing and punishment after certain blockstun? I like to think recent MKs but those have a certain height to 'em that works and particular buffering. 28:10 probably answers my question.

@@MoldMonkey93 if the defender is currently incapable of influencing the state of the game (in hitstun, being juggled, etc) then, as far as the attacker is concerned, rollback should look and feel the same as playing offline. I'm not super familiar with tekken's specific mechanics, but hitting strict timings in combos shouldn't be any harder on rollback than it would be offline (unless ofc there's suddenly some extreme network issues that exceed what can be handled by rollback).

Some things like frame perfect inputs could get messed up by lag like taunt jet upper and perfect electrics. But lag still just fucks up Tekken anyway so it would probably be better overall. Block punishment for the most part wouldn't be too poorly affected unless you're going for perfect electrics and some of the other more difficult punishment options, typically ones which punish moves with pushback. For most block punishment you can mash the input but some characters will be more disadvantaged by lag than others. Some combos will get affected but these are usually ones you wouldn't attempt online anyway as it is. There are projectiles in Tekken now though so that might be a problem for them being inputted in the prediction frames.

They won't listen "to you", but hopefully if all of us (including you) complain loud enough, they'll take notice

Skullgirls also has bursting to stop infinites or when the same move is repeated too much and its up to the player to control that and works perfectly. You also have combo breaking in killer instinc where its a rock paper scissor battle where you want to guess the right button the opponent press to escape the combo and it also works totally fine. Both of this games run on rollback and are among the best ones in how it was implemented.

Wifi for life... come catch my Poison outside👻

@@lesleylindsay7871 I just want you to know that you are why there is war

Sad reality is not everyone can get wired.

GGPO/rollback may not be able to solve all of the problems of a WiFi connection, but you might as well choose the netcode solution that handles them the best. I think WiFi is here to stay, whether we like it or not, so games can at least do their best to help.

⁠@@InfilMost definitely, fighting games should be accessible and the history of gear gating people with controllers is bad enough. I always play wired personally but you never know what someone's situation is. You did a fantastic job with this article!

adding a server as a middle man in a 1v1 game would likely increase latency in most cases, just due to the larger geographic distance the data would have to travel. There wouldn't be any anti-cheat benefits either, since the only data being sent between clients is input data. The only upside I can think of is that true desyncs wouldn't have to terminate the match, since a server could revert both players to its last valid state (but this is uncommon anyway, and imo not worth the potential extra latency).

There's a brief discussion about it in the Iron Galaxy interview section on page 6.