There is no authority with GGPO. Every peer sends its inputs to every other peer, and that’s it. It’s a type of deterministic lockstep networking; the difference is, the input delay buffer is optional, and can be removed entirely without creating a janky play experience for the player.
Normally, in fighting games, if you played online a lot, you would have to enable some sort of lag simulation option to mimic the input delay caused by the game’s bad netcode, because that delay would alter the timing of your combo inputs relative to the action you see on-screen. GGPO allows the user to not only decide how much or how little input delay they want (in order to mask the “teleportations” rollbacks can sometimes cause for other players’ characters), but also to decide to remove it entirely. That way, the game will feel as if there is no lag at all in terms of the local player’s control over his own character, eliminating the “lag factor” entirely. Suddenly, the advantage provided by mandatory input lag goes out the window.
Rising Thunder uses GGPO 3, which, as far as I know, is not yet available for third-party use. I was given GGPO 2, which should be enough.
I’m already feeling the motivational impact of getting this working. I haven’t made much progress on my game in about a week, largely in part due to the intangibility of the research this particular task requires. I don’t have anything to “show” for the time I’ve spent working on it thus far, and I haven’t written any code at all.
Anyway, it seems like I have about 9000 lines of code to read and understand. I’ll update the thread when I figure out the solution to getting this working. At the very least, once I have this done, I’ll be able to help out anyone else who wants to use GGPO in their UE4 game, depending on how much I need to modify CharacterMovementComponent.