2
\$\begingroup\$

By implementing peer to peer connections between clients in a client-server network model I should be able to increase the prediction fidelity as this theoretically would provide the client with other clients commands for a given tick earlier than it would receive the servers game states for the same tick.

One problem I can think of is that clients would have to be able to interpret other clients commands (usually they just have to listen for game states, not commands). This would be a little bit like an RTS model I guess. This should be solvable without any negative effects on gameplay.

Another problem is that clients could cheat by sending fake data to their peers when it is beneficial to them. This can be mitigated by having the client aware of the real commands through the server and have them immediately stop listening to any clients that fed it false data. This should therefore be solvable with different degrees of negative effect on gameplay depending on the design of the game and how impactful a few ticks of wrong command info is at the worst possible moment.

(Unfortunately, you can't have the server punish any client because it has no idea who's lying, it can only help clients themselves understand if they are being lied to by providing them with correct data).

Am I correct in assuming that this would increase prediction fidelity or is there something I'm not accounting for? The idea is that this allows the client access to some information about the other clients faster than in a traditional non peer to peer model where it would base predictions solely on its own commands.

\$\endgroup\$
1
\$\begingroup\$

I'm not aware of this ever being used, and I suspect it's because it has very limited benefit for greatly increased complexity and bandwidth use. It might make an interesting experiment, but it seems impractical.

Consider that to support such a scheme, and assuming that most traffic is generated from player actions, you would need to double the downstream traffic and multiply the upstream traffic for all clients, not to mention opening a large amount of new connections. Double downstream because now you are receiving player commands from the peers as well as the server. Multiple upstream because clients need to send their commands to all peers as well as the server.

But perhaps the biggest cost is that you run into tricky situations when you now have three points of reference. With a traditional client-server architecture, there are two: the client and the server (technically the other clients have their own points of reference but the server multiplexes them into a consistent, single one using techniques under the latency compensation umbrella). Now you have three (or more): client, server, and peer. Consider this scenario:

  • Peer tells you that they shot and killed you
  • Server later says that you weren't shot (maybe the peer->server shot packet was dropped)

What happens on your client? Do you momentarily die and revive? Do you ignore the peer's input altogether (then what's the point of having p2p)? I'm sure you can come up with many more edge cases like this.

Finally consider the limited benefit of such a scheme. It might be a boon if you and your friends are all geographically close (say, you're all in Nauru) but the nearest hosting server mandated by Modern FPS 2015 is in US West. You will have a horrible time playing each other, so p2p will make things a lot better and the server turns into a glorified command validator. In practice, such a situation is rare, as most peers will not be significantly closer to you than the server.

\$\endgroup\$
  • \$\begingroup\$ Good points. Some things that could reduce the issues you've mentioned: - Upstream traffic: The client only needs to send information to peers that are relevant. The server can tell the client when other entities become relevant and not relevant to it. This at least reduces the pressure. - Discrepancy between server and peer information: First off, the peers would only tell you that they took the shot, not that you were actually shot. Depending on travel time of bullets etc. this is more or less of an issue. There would probably be some events where the client simply only trusts the server. \$\endgroup\$ – Willem Aug 27 '14 at 11:47
  • \$\begingroup\$ - Limited benefit: Even when the peers are as far away as the server, it does save the round trip so it's twice as quick. I.e. 100ms to server and 100ms to peer. Then to get the info from the server, it actually takes 200ms because it takes 100ms from peer to server and 100ms from server to your client. While it only takes 100ms from peer to you. You effectively cut lag in half, right? \$\endgroup\$ – Willem Aug 27 '14 at 11:49
  • \$\begingroup\$ Also, what happens when a packet of command info is dropped in a server-client network model? I feel like Counter-Strike and other games that employs this architecture seem to have some kind of redundancy? Could it be that they keep telling the server what they did in old ticks to ensure that some commands get through regardless of individual packet loss? \$\endgroup\$ – Willem Aug 27 '14 at 11:54
  • \$\begingroup\$ The Source engine delays each update in the client by up to 100ms so that dropped packets can be interpolated. \$\endgroup\$ – Jephir Aug 27 '14 at 16:07
  • \$\begingroup\$ But what if a packet that contains "fire AWP" doesn't reach the server? The user only tapped his fire button for one tick, so that message should be lost forever? The gun didn't go off according to the server? \$\endgroup\$ – Willem Aug 27 '14 at 16:25
1
\$\begingroup\$

First, I haven't found any indication that another game does this.

Having said that, I'd love to try it, or find examples of it, and was looking for examples when I came across this question (hence the (somewhat) necro - but an answer hasn't been accepted, so I might as well give one).

I believe such a method would be useful, though its value would vary by genre or specific game mechanics.

A first person shooter would have little use for this, since player-player interaction and fluidity of experience are quite far removed from each other, and thus pure client-server seems to suffice. What I mean by that is: player movement is rarely inhibited by other players, and player interaction is rarely more complex than shooting (which usually will just lower their opponent's health in the case of a hit, and the opponent's health is rarely visible to the player). Often, their only awareness of lag is usually taking damage a little after getting behind cover, or dying after riddling an opponent with bullets, but those are both critical decisions that should be left to the server.

Movement, which you mentioned in a comment on another answer, is probably the best candidate for this to work. If your particular subgenre of FPS allows players to side-step quickly, zigzag, bunny-hop, or puts any value into other quick movements, some extra predictability can help players hit their target, especially with powerful weapons with a low rate of fire. At the same time, it's also a great avenue for cheating. Sure, the server will correct it, but making movement even more sporadic due to invalid information and frequent corrections from the server would certainly give me a harder time shooting you ;)


Since you tagged your question first-person-shooter, the answer could be left at that. But since the same question without that tag would likely be considered a duplicate of this, I hope you don't mind me expanding to other genres.

Other genres with more direct interaction could benefit greatly from this model as far as the end user is concerned, even though the simulation on the server is unchanged.

A brawler requires players to read each other's movements and react to each other's actions before they take impact. If a character has a 400ms power-punch animation but only sees it begin 200ms after their opponent has started the action, they're in trouble. But if the opponent's client can say "Hey, I've told the server about this action; you should start this animation while the server confirms it for you", the player could see the animation begin much sooner and have time to react, or at least be less perplexed that their character's ragdolling across the stage half a second later.

Maybe. In ideal circumstances. Worst case is more traffic and no improvement, but it won't make the experience worse.

A more physics-driven game, like a driving game, depends quite a bit on plausible motion. Being notified of a car turning and taking that into account in the client-side prediction would result in less correction when the authoritative server information comes through. Or a quick boost before a car rams into you and knocks you flying will be less jarring if you see them boost just before they hit you, rather than just after.

In the end, the server simulation should be unaffected, and there are new cheating avenues to try and take care of. But these cues could make lag less jarring for your typical player, who generally has no idea why lag happens.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.