-
Ever wanted an RSS feed of all your favorite gaming news sites? Go check out our new Gaming Headlines feed! Read more about it here.
Under Night In-Birth Game Director inquires about GGPO netcode, GGPO creator responds
- Thread starter Jaded Alyx
- Start date
I just want Tekken 7 netcode for everything as it's been perfect for me for YEARS! SF5 netcode tho, that's kinda crap in my experience and not cool to play. Therefore, fuck rollback !
OP
OP
Everyone knows SFV is poorly implemented rollback. Watch the video posted above for the details on that.
Have you tried rollback netcode elsewhere? Skullgirls? MK11? Power Rangers? It is hands down better overall than any delay-based method.
No, never tried a good rollback netcode to be honest. I have Skullgirl but never played online, I'll have a look !
OP
OP
Looks like the website is back. Hopefully they translate it and all documentation into Japanese.
Yeah kinda pointless if it's not in a language the Developers have an easy time with.
OP
OP
I refuse to believe Tekken 7's netcode is perfect for anyone.
Gotta wonder how much support they can provide given that they're Riot employees.
Last edited:
I know very well that GGPO is vaunted by the community, but it might be worthwhile to point out that it is dependent on the game that it runs within being serialised and deterministic.
What this means is that the state of a game has to be describable by the engine it is running on, you need to be able to go back to a specific frame and resume activity given a change to the state that has already happened and that given a certain set of inputs it will have the same outcome each time. Even the generation of random factors in play has to be at some level predictable.
This works well within emulators because a shared state can be synchronised at the beginning of play, with only player inputs shared between the two emulated machines. The state can be rolled back to a point where the emulator had a true set of both inputs available and the emulator can catch up to what should be currently occurring. RNG will match on both machines and they have enough processing headroom to process all the new frames that are being skipped.
The NRS GDC talk goes into very specific detail as to why implementing rollback netcode in an already shipping game is a costly procedure. This can be because the game may not be serialised, it may not be deterministic and it is very likely using all the headroom it has.
This might be surprising to fighting game players because we take the factors that are being managed by rollback netcode to only be the actual playing state of the characters that we are using. The point here is that all other factors of the game have to be serialised.
This means that your sound, your effects particles and every other factor in the game needs to be built in such a way that it is possible to roll back to an earlier state, then resume a number of frames later with the same, correct result on both clients.
This was difficult for NRS because they hadn't built the game to be able to do that, they didn't have enough headroom to suddenly push out a different result than what was previously being rendered. So they had to engineer their rollback netcode with that constraint and they had to change their existing rendering pipeline to give them back some headroom.
This is part of the reason as to why rollback netcode on cross Tekken caused audio issues and why it is not just a factor of licensing someone else's work for use on an existing product.
Given the right support and with the assumption that UNIST has a lot more headroom than NRS games I would expect they have a pretty good chance of being able to implement it, but it is not a question of simply dropping it in to an existing game.
What I would be really interested to know is whether we would be better off pushing for rollback netcode in UE4, given that would mean it was baked into the middleware and taken out of the hands of the game developers. Why do we keep on having to rebuild the same thing when different developers use the same tools?
What this means is that the state of a game has to be describable by the engine it is running on, you need to be able to go back to a specific frame and resume activity given a change to the state that has already happened and that given a certain set of inputs it will have the same outcome each time. Even the generation of random factors in play has to be at some level predictable.
This works well within emulators because a shared state can be synchronised at the beginning of play, with only player inputs shared between the two emulated machines. The state can be rolled back to a point where the emulator had a true set of both inputs available and the emulator can catch up to what should be currently occurring. RNG will match on both machines and they have enough processing headroom to process all the new frames that are being skipped.
The NRS GDC talk goes into very specific detail as to why implementing rollback netcode in an already shipping game is a costly procedure. This can be because the game may not be serialised, it may not be deterministic and it is very likely using all the headroom it has.
This might be surprising to fighting game players because we take the factors that are being managed by rollback netcode to only be the actual playing state of the characters that we are using. The point here is that all other factors of the game have to be serialised.
This means that your sound, your effects particles and every other factor in the game needs to be built in such a way that it is possible to roll back to an earlier state, then resume a number of frames later with the same, correct result on both clients.
This was difficult for NRS because they hadn't built the game to be able to do that, they didn't have enough headroom to suddenly push out a different result than what was previously being rendered. So they had to engineer their rollback netcode with that constraint and they had to change their existing rendering pipeline to give them back some headroom.
This is part of the reason as to why rollback netcode on cross Tekken caused audio issues and why it is not just a factor of licensing someone else's work for use on an existing product.
Given the right support and with the assumption that UNIST has a lot more headroom than NRS games I would expect they have a pretty good chance of being able to implement it, but it is not a question of simply dropping it in to an existing game.
What I would be really interested to know is whether we would be better off pushing for rollback netcode in UE4, given that would mean it was baked into the middleware and taken out of the hands of the game developers. Why do we keep on having to rebuild the same thing when different developers use the same tools?
You would think Capcom, having the license to GGPO and creating their own with expired milk, they could work with other developers implementing rollback netcode like how they work with Bamco in a cross license agreement.
OP
OP
Yep yep, found myself nodding to myself as I read this, good post and summary.
I hadn't considered UE like that though. That's an interesting thing.
OP
OP
It's better than SFV (which is held together by school glue and balsa wood), about on par or slightly below Tekken, and worse than MK11/I2. I love Unist so getting ggpo would be amazing!
I remember playing Fighting Herds and Brawlhalla vs a friend who lives on the other side of the world and it being playable. I also remember playing Street Fighter, Tekken and Smash 4/5 vs other people in my own region and somehow feeling laggier than that. The only Japanese game that felt playable internationally was Pokken, and that's because the games slower pace (but at least it doesn't chug).
free? id donate money for an effort to make it more accessible
free? id donate money for an effort to make it more accessible
Indeed GGPO isn't a silver bullet, neither is all rollback netcode built the same. As a layman, from what I understood from NRS's GDC talk is that their rollback netcode works very differently from GGPO. They don't record game states, just player inputs. And even just rolling back to player inputs meant they had to a lot of optimization. Like a heck of a lot according to their talk. I imagine what they developed is way lighter on the CPU than GGPO, which had to be to fit their needs. Which is also why Capcom couldn't just drop GGPO into SFV even if they wanted to. We know for a fact the game's framerate on PS4 struggles when it goes online as it is, or at least it did at launch.
It's a shame fighting games are as niche as they are, I doubt Epic would bother doing what you suggested.
It's too late for Guilty Gear 2020.
Best hope this makes it in time for the next generation of fighting games from Japan.
Best hope this makes it in time for the next generation of fighting games from Japan.
Have you ever tried Arms? That had surprisingly good netcode. Up to 4 player online with items and it always ran well for me with very occasional lag likely due to playing someone with bad connection.
Granted, like Pokken, it is a slower paced game than most fighters
Genuinely feeling it's the best for me. I had like 10 really unplayable matches in 200h of online play. Maybe it's a regional thing? I'm in france and get matched with uk, germany, Italy and spain.
I have 1 laggy match every time I play sf5 tho.
OP
OP
I believe it's because fighting games are peer to peer connections.
Most other genres are server based.
Using UE4's built in multiplayer as an example, players are clients that connect to a server. A server could be dedicated or could be one of the clients in the match being played.
The game state is updated from the server to the clients based on the individual 'actors' in the game, actors being anything that does something in the game. Even if the game runs at 60fps or higher these actors might only refresh their activity twenty times a second or so. The server only needs to update based on actors that have actually changed state since the server last checked. Each client holds an approximation of what is on the server, they don't actually hold the full state of the game. The server holds the truth.
This allows certain things to be done around predicting the state of the game or mitigating the amount of data that needs to be sent and received at each moment since you generally know certain things about how the game runs.
The main distinction between that and fighting games is that fighting games don't normally work in a server model, instead they are peer to peer so both clients have to hold the full state of the game. In addition to that they don't send details of the state of the game to each other, they send and receive the player's inputs, and they have to do this 60 times a second.
What I mean by that is that the fighting game netcode doesn't know that you've thrown a fireball, just that you've done a quarter circle input followed by a punch button. Whereas an FPS multiplayer server knows that you've fired your weapon at X angle whilst standing at Y coordinate whilst moving in Z direction at whatever speed, but they don't need to know what buttons you were pressing to do that. For a well designed piece of software that could be a pretty simple thing to send on a regular basis.
Last edited:
I didn't realise Mortal Kombat 11 was a form of rollback. I feel like I get just as many bad games in MK as other games but MK bad games are like unplayable. Like legitmate full freezes at time. It doesn't quite feel like the saviour of online play but obviously it's their own version I suppose.
Also sounds like the original guy was speaking tounge in cheek probably because of the amount of requests they get for rollback like it's some garage indie job that the big boys don't need to entertain.
Also sounds like the original guy was speaking tounge in cheek probably because of the amount of requests they get for rollback like it's some garage indie job that the big boys don't need to entertain.
GGPO works by essentially predicting the timeline of inputs, then rolling it back to the last correct result as more inputs arrive from the opponent. This is a concept that only scales well to fighting games because there's only such a limited number of results that can occur. Trying to make, say, and entire FPS arena shooter work on such a system means you are suddenly rolling back not just the players but the level environments themselves which can become a chaotic mess and fast.
There was a branch of RetroArch recently that added a rollback system that you could use to eliminate input lag induced by emulation by having the emulator predict ahead several frames from the inputs it was actually receiving. If this value was set high enough, or heck even if you were just frame perfect, you could have instances where the player were to briefly die or live in the predicted environment, because their inputs were drastically altering the environment they were in. Now imagine that on a larger time scale with even more players thrown into the mix.
Though as crazyfunster mentioned, there are elements of it that exist in other netcode deployments, but they aren't quite on the scale of what GGPO does. Rocket League for example predicts ahead the players and ball on the client side simulation, and if there's a miss-predict it'll reset and run all the frames again. It's like rollback but the server isn't doing it at all, it all depends on what the client thinks is true. This is something that only barely works in Rocket League (player's dodging just before they touch the ball basically makes the ball impossible to track for a brief moment, among other problems with dodging), trying to do the same thing in a Quake3 styled game, for example, would be hell for any player with even a reasonable amount of latency, where players change inputs and direction incredibly frequently, and mispredictions would be frequently and make the players impossible to track on the client's side.
Last edited:
OP
OP
Very interesting. Thanks for taking the time to share!
I don't disagree with you, your analysis of rollback netcode is fairly spot on...
...but that's realistically only an issue with developers that choose to bolt on rollback netcode after the fact, rather than designing their game with the netcode in mind. Which is a major architectural design issue, considering that for fighting games a good netcode is incredibly critical. I'd sort of liken it to designing your entire system around sending everything in unencrypted plaintext. You can get away with it, but it's still a terrible idea and one of those things that any developer should immediately slap down.
GGPO is, as you've essentially mentioned, the fighting game scene's way of attempting to normalize rollback netcode. But it's also the more expensive option because of the additional design constraints, so it's often quicker and easier to use something with input delay. Which is why we're here in 2019 with many fighting games still having half-baked netcode, because it's easier to hammer some mediocre netplay into a badly designed system than it is to write the system with the netplay in mind.
It was never about Under Night [cl-r] having rollback on launch, as it was already way too late for that and French-Bread is an incredibly small development team, but the game they put out after [cl-r], be it another Under Night iteration or something new, may very well see GGPO or some other rollback netcode solution implemented.