We are building a first person shooter on UNREAL that is similar to Q3 and Quake Live - but trying to address the common issues.
I have been doing some research on what’s out there to help with adopting better performance based on netcode taking into consideration the ping/lag issues that seem to be, to this day, a major issue with most-all online game-play.
What is the best solution for a possible licensable netcode plug in we can use for prediction code?
Something I came across is called GGPO that was developed more for fighting games. GGPO is also used in FPS online games and is something we can license, but does anyone know if this is a good or bad solution for prediction software/netcode?
The developers of Quake 3, Live, Unreal Tournament, and similar games, have spent a lot of time trying to overcome the latency problem as much as possible. In the end, latency is a physical phenomenon, kind of like wind drag or tire/road friction when trying to run a car fast.
For the local player, you have a choice between: - Show immediate feedback, but risk that you'll be "snapped" when that turned out to be "wrong" - or delay feedback until you've gotten a response from the server, which introduces command lag
For the remote players, you have a choice between: - Forward extrapolate those players, showing them approximately where they "would be," with the drawback that when they change their commands/inputs, you showed them in the wrong position - Show the actual positions of those players, delayed by the server round-trip
For hit detection, you have a choice between: - Hit detect what the local player saw on his/her screen. This seems "fair" to the local player, but leads to easy cheating, and seeming unfairness when a player gets "shot around a corner." - Hit detect the actual situation on the server. This is more resistant to cheating and unfairness, but means that players must compensate for whatever the extrapolation/prediction algorithm is.
These are not limitations in software -- the game designers of existing FPS games have tried all the different combinations to get something that plays as well as possible. These limitations are based on the laws of physics. Your choice, as a game designer, is to pick one of the trade-offs for each of the situations, to make a cohesive game that feels as good as possible given the limitations.
The reason GGPO works is that simulation for those games is actually very cheap, and it can keep a full log of previous points in time, and snap/fix-up players when discrepancies are noted. This is an implementation of approximately the first of the options for each of the choices above. For reference, I shipped a similar system, for 3D networked physics, in the early 2000's as part of the There.com virtual world. If I had to do it again, I'd probably choose a slightly different trade-off.
A little something from Antic over at the ROTN forum:
Yea, far as netcode/prediction, it all works essentially the same, but with specific differences in the way it’s handled.
“- Hit detect the actual situation on the server. This is more resistant to cheating and unfairness, but means that players must compensate for whatever the extrapolation/prediction algorithm is.”
For sure you want hit detection to be handled by the server, client-side dictated hit detection is easily hackable as many games have seen, as is any client-side dictated data (borderlands hacked guns for example). Basically you have to represent what the server sees to the client, which means they have to compensate for your prediction code.
Any “unlagged” mods use a form of client-side prediction by drawing the client and other clients where they’re “going to be” by predicting where they will end up based on their trajectories and speeds, etc. Problem is, they can and probably will change based on client input, like suddenly changing direction to dodge a shot.
To represent the moment when the client’s perception of object positions is updated to match the server’s actual positioning of objects, you usually run into 2 possibilities. One, is snapping or rubber-banding of an object from it’s current drawn position to its “real” position. The other is using no prediction whatsoever and running into more client-side “lag”.
If you had to compare the 2 systems, prediction code and realistic positioning, QL and games like Diablo 3 or Path of Exile are examples of different kinds of prediction code. Q3 vanilla or Q3 osp mod would be examples of little to no prediction code, and thus lag.
It’s almost impossible to run no prediction code whatsoever, but you have to be careful how you choose to implement it as it can totally ruin the feel of what players think they’re shooting at / hits registering “correctly”.
In Diablo 3, rubber-banding is frustrating because you run forward a good ways then all of a sudden, Bam, you never left, you’re right back in the shit. Path of Exile’s “Desync” is basically giving the client free reign over prediction, leading to issues where you think you’re somewhere and you’re not, then the server eventually syncs up and the invisible damage you were taking turns out to be 3 monsters that were hitting you the whole time on the server. Path’s system would actually work decently if the servers could handle CONSTANT updates or refreshes to the clients, but it doesn’t, and at best they resync every 10 seconds. A lot can happen in 10 seconds. Run into a monster or a wall on the server, when your client showed no problem, and on your screen you’re running free, on the server you stopped dead because you were blocked.
QLive’s prediction code is evidenced in the fact that the model is almost always drawn ahead of the actual player based on their current trajectory, thus aiming behind the model becomes efficient in hitting them. When the game was first released/beta, this was complained about heavily. This also leads to many “around corner” shots, when someone thinks they strafed around the corner, but in fact their real model was still out in the open. This also leads to the mythical “shoot-thru”, where the player shoots the model on their screen, but in fact they were missing the real player, leading to a feeling of being cheated. Shoot-thrus don’t really happen, they’re simply a player’s mistaking their client version for the real location of their target, when the system has been designed this way from the start.
