HiPoyion":d30iifb9 said:
Well from what I remember isn't this how Overwatches "Favour the shooter" system works? Whatever happens on the shooters screen is what happens in game. Which is why it can seem like you got shot from around the corner sometimes.
Yah this used to be called "unlagged" back in the early 2000s, it's one of my favourite game techniques and I'd be surprised if I wasn't the one that spent an hour telling you about it.
It's become standard for FPS online games.
The server stores a history of the game state up to N frames, when a player does an action that's considered critical (such as firing a bullet) the latency between that player and the server is used to look up in those stored frames what point in history the player is actually in on their end of the connection. If their lag is between states, then the server interpolates between them to create a fake state that estimates in-between frames.
So if I have a ping of 100ms then the server looks back to see what the state was 100ms ago (because that is guaranteed to be the state I was looking at when I shot my bullet) and it fires the bullet inside that state in history - all the players in an FPS game are effectively time travellers shooting at past-snapshots of each other with the goal of killing them in the past to kill them in the future.
This guarantees that every bullet shot across planet Earth, as long as your ping is within the N frames threshold, will take exactly the effect that the player sees on their client.
In cases where you get shot around corners - if you were to freeze time then you'd find that the enemy really did shoot you before you got around the corner. Bullets are more important than movement, so the shooter always wins.
What this boils down to is; you need to actually hit enemies if you want to do damage, and if you get shot then it really is because they shot first. No one player has an advantage over another, however you may still see weird things happen and if you don't know how this system works you'll say "this is bullshit!" when in reality it's a level, very fair playing field.
All that said, client-side prediction can create some issues. If your client is heavily predicting frames (poor connection to server, maybe you're on WiFi) then you're more likely to be shooting at a false lerp'd player - as your client hasn't received latest updates so it is generating simulated updates based on previous frames. In these cases, if you shoot an enemy in this circumstance the server may respond "hang on, when you fired that bullet the enemy weren't there, so therefore you hit nothing".
In Source engine this is made very obvious with client-side blood splatters - the client will happily splat out blood on the walls and floor as if you hit the enemy, but when that bullet travels back in time to the server's history the server may still say "your client made up that simulated frame, the bullet hit nothing" and then you shout "Bullshit! The blood splattered everywhere!".
So a bad connection can still put you at a disadvantage. Bad connection is packet loss/rate inconsistency, it's not ping (which is time between you and server, AKA how far into the past your client's uninterpolated state is).
EDIT: Stadia won't benefit from this system at all. It would mean Google would need to simulate a few hundred copies of the same game, all with the exact same state, only each on is 1 frame in the past compared to the other. And Google would need to modify the future game states as critical actions occur. That would require an insane amount of computer power for a single player and it would require access to modifying the game's core run-time to change the states around. It would also need a game that can be reliably simulated - stuff like GPU particles are not reliably simulated so these would be an utter mess.
I considered this kind of network technique for emulators, I was doing a small bit of research into the idea not too long ago. The thing is; emulators do store and restore state, so being able to look into the past and figure out the action the player took is easy. The hard part is quickly simulating the future frames of the current state. And then doing that for 4 players on a SNES game.
The fighting game scene has had some pretty good network technologies come from it. I think Skull Girls had a famous network engine that got used in a few other projects. Not sure how they work, pretty sure it's based on actions rather than button inputs (Ryu used "hadouken", rather than Ryu rolls the joystick scroll N1..3 frames and hit punch at N+4 frame). That kind of thing can probably be unlagged, also (a punch or using a special move is a critical action).