GGPO Netcode in a source port

Coming from a fighting game background, the use of GGPO ("a rollback netcode"), is preferred by most people. How do modern source ports handle the latency (if at all?)

Has anyone looked into this to license or test it in a Doom port?

The website is down and I have no idea how long it's been that way. The technology is being included in more and more games now particularly with Capcom so I wonder if they just bought the license out.


https://en.wikipedia.org/wiki/GGPO


This article states it's designed for critical millisecond timing games
http://www.gamasutra.com/view/news/177508/The_lagfighting_techniques_behind_GGPOs_netcode.php

"I wrote GGPO to try to do a better job of solving the lag problem, without sacrificing all the other great properties of this method. Instead of adding an input delay to the entire simulation, GGPO gives the local player immediate control over his avatar by hiding the latency of the connection in the start-up of each remote player's action. This does a much better job of faithfully reproducing the offline experience in the online game.

GGPO uses speculative execution to eliminate the perceived input delay for each local player. Instead of waiting for all inputs to reach a player's simulation before executing a frame, GGPO will guess what remote players will do based on their previous actions. This eliminates the lag experienced by the local player created by the traditional frame-delay method. The local player's avatar is just as responsive as when playing offline. Though the actions of the other players cannot be known until their inputs arrive, the prediction mechanism used by GGPO ensures that the game simulation is correct most of the time.

When GGPO receives the remote inputs from the network, it compares the predicted inputs to the actual ones. If it finds a discrepancy, it rewinds the simulation back to the first incorrect frame, repredicts the inputs for each player based on the updated input stream, and advances the simulation to the current frame using the new prediction."

Wikipedia says that GGPO is proprietary, which puts it right out of inclusion for any GPL ports.

That doesn't mean anything, you would have to reimplement it from scratch regardless.

The basic idea (predict behavior, then compare and if prediction is wrong, rewind and adjust) is already implemented in ports like Zandronum at least for things more predictable than players (projectiles, monsters).

Predicting player behavior is more difficult. I think a game like Doom is at a disadvantage over the classical Mortal Street of Tekken Fury clone because the game scene is generally more complicated -- distances between players change more, movement is more complex, there are interactions with the environment like picking up medikits or weapons or taking cover or activating switches, etc.

ZDaemon also uses a server-side "arbitrage" to solve lag-induced situations. E.g. if a player shoots at a certain (client-side) time, the server then uses that packet's timestamp and compares it with the position that a potential target should have had at that timestamp, so "outrunning" a lagging player will no longer make a "low ping bastard" invincible. It may however be somewhat abused the other way.

Maes said:

ZDaemon also uses a server-side "arbitrage" to solve lag-induced situations. E.g. if a player shoots at a certain (client-side) time, the server then uses that packet's timestamp and compares it with the position that a potential target should have had at that timestamp, so "outrunning" a lagging player will no longer make a "low ping bastard" invincible. It may however be somewhat abused the other way.

I used to kick ass on 56k in ZDaemon, but once I got cable I sucked. On 56k one has to think ahead of yourself and your enemy. However the lower pings have the advantage so against a good player on a cable connection, I considered half their kills good for the massive delay I got.

There is one main problem with packet based ports is your input commands getting lost, so bad packet dropping connections you basically look like you are walking instead of running, and you might not even fire your gun.

Yeah this is basically the same kind of thing to what multiplayer source ports like Zandronum etc. do. Not exactly identical but in principle it's the same kind of thing.

This specifically looks like a way to support old games that aren't designed for long distance netplay. It's probably not going to be as good as you can do with a source port with dedicated netgame code that's designed to do this kind of thing. The most interesting thing you might be able to do is make a source port capable of recording vanilla demos that uses it.

There are at least two open-source implementations of GGPO-style rollback netplay available: ShobuNetwork (C++) and RetroArch's stock netplay implementation (C)

Jittering caused by packet loss can be at least slightly compensated for by including several frames of the player's input history in each packet sent by that player, but I'm not sure how well GGPO's approach would scale beyond two players in a match of Doom for at least two reasons:
- Rollback is supported in GGPO by taking snapshots of every recent past frame potentially up to a few seconds back which can pile up, though to be fair "RAM is cheap" applies here and I imagine those could be stored far more space-efficiently with a source port than anything a typical emulator could pull off, no longer having to snapshot the entire state of emulated RAM (GGPO already had to use some trickery to drop certain information from state snapshots in order to make 3rd Strike decently playable and sometimes it suffers for it--ever get the Venetian blinds effect during a match in 3S?)
- In a situation with more than two players, a misprediction for only one player would (as far as I understand) demand that every player rolls back to the first mispredicted frame of that player's input history, and this would be exacerbated by mouse/analog input being more susceptible to tiny prediction errors than D-pad/buttons--they're all the same to GGPO and all demand a rollback if they're even slightly mispredicted (I know vanilla Doom's turning precision in netplay packets is limited but for sourceports that increase this precision or add freelook this could be a greater issue)