This is actually very simple to explain, he’s actually not getting 0F’s since he has a 5 input delay on the game. That 5f input delay is what makes the networking work at such large distances with what seems to be no lag whatsoever.
However the dev to make a point states that he’s getting a 0F input latency, while what he means is that, not only there’s no additional input delay, the frames are synced perfectly despite the distance. Traditionally without ggpo or while using bad rollback (sf5 cof cof) you will have some input delay to compensate for the difference or the inputs will be out of sync which causes issues. The cool thing about ggpo is that there is no delay and it forces things to be in sync, however if the rollback frames get high, let’s say 5-6 there will be a noticeable rollback, since it doesn’t fall under that built in 5f input delay protection. For reference, most games nowadays use a 3f input delay with ggpo.
It’s also important to note that that specific dev is getting guidance from a lot of known people in the ggpo community. Which leads to this comment, if OP wants, the best way to achieve this is actually to contact them. But I do have to warn you, if you’re not knowledgeable in networking and coding, they won’t respond because let’s face it, they could write you a full on PDF with a step by step, but without advanced knowledge you can’t pull it off.
I believe that’s how the Omen of Sorrow devs also pulled it off, they asked for a lot of help from the community. Specially on the UE discord in the Source code sub to switch UE4’s to a deterministic approach on physics and simulation. But they also had previous knowledge in networking, they just had to learn how UE worked.
For everyone who said here that ggpo is overkill and UE’s networking is fine, it’s not for the purpose of OP’s game genre. If companies such as Capcom tried to implement UE4’s network and failed miserably why would you do it when there’s a proven method that works flawlessly? I’m seriously glad companies finally got over that nonsense and started implementing it. Look at how praised GG Strive is atm just due to the netcode. GG XX ACR has more players than SF5 and Tekken combined just due to GGPO, and that’s a decade old game.
I’m all for GGPO’s implementation in fighting games, if it works why change it? It’s also free.
GGPO will not work with a distributed rigid body simulation. It’s a fine networking approach for games where the simulation is cheap, and where there are few actors, but if you throw a grenade at a pile of blocks, that’s not what you end up with.
In a fighter game or other such “immediate input” game, saying you have “0 frames of latency” might just mean that you predict the local actor immediately, and because you have the input-synchronous model, you will see yourself with no latency. You will see the other guy with whatever latency is in the network – information theory says you can’t do better than that! Thus, whatever wind-up animations you use, will be cut off from the beginning, for the remote player. You can, in turn, get around this by designing the wind-ups to look alright even when they’re cut off from the start.
Given this thread is what google finds when searching for GGPO in UE…
Yeah, GGPO solves really small part of the whole problem. You need to store and send inputs with the frame number and predict them on the other side. That’s basically all. If you press jump at frame 12, add net delay and it arrives at the other client at frame 15, the client deterministically reruns frame 12 with said input and recalculate frame 13, 14 and 15 from that. The bold part has nothing to do with GGPO, but with deterministic state of the world. It makes no sense to do it that way, if your underlying simulation isn’t deterministic. When you understand that, you’ll also see that the GGPO isn’t that big of a library and doesn’t solve that big of a problem.
The underlying state of the world, the ability to resimulate the game, the ability to store replays as a list of inputs and so on… these things aren’t handled by GGPO and cannot be easily made in the UE.
I’m thinking about doing something like this (for cars), but if I do, I’ll pretty much have my own positions/collisions in my own “console application” and just update actor positions each frame accordingly.
Have you had any luck in implementing deterministic physics for you car game? I’m also interested to develop a fighting game and this is the part that I’m a little hung up on.
I didn’t, because there would be an issue with collisions with track objects. As in, track object position it’s bounding box, and its collision would have to be deterministic… => at this point, it would be fully deterministic physics simulation with all bells and whistles and that’s out of my scope.
However, for a simpler fighting game, you can do it in an easier way. Your “simulation” can just track the position as integers, you could just define jump curves and so on as integers and go from that. At least, to my understanding, fighting games don’t typically have some hardcore physics, no? rather rules like "this punch will land in 4th frame, if the enemy is from here to here… Animations will just follow that.