FPS mixed star and peer-to-peer topology

Started by
3 comments, last by Waterlimon 12 years, 2 months ago
Hi people,

I was thinking about lag issues with twitch-based games. It seems to me that it might be worthwhile to have an authoritative server, but allow nearby (in both game and geography terms) clients to interact on a peer-to-peer basis to cut down on lag. So for example, when two players are involved in an intense direct fight, use peer-to-peer position/fire updates to reduce latency. The updates would be sent to the server as well for checking purposes. One way this might work is using a peer-to-peer NAT hole-punching system such as this: http://www.brynosaurus.com/pub/net/p2pnat/

One obvious issue I see is cheating issues, e.g. Client A lies to Client B about Player A's location, but tells the truth to the server. So player B is shooting at air, and there's no proof of cheating.

Also it adds another layer of difficulty for synchronising.

Does anything do this? Any other pros/cons?
Advertisement
To be honest, is lag really a problem nowadays ? I've some issues with your sugguestion.

- First, it makes network programming more complicated.
- A real benefit should be only expected in certain situations (i.e. player up-stream must be fast enough, player down-stream needs to handle more incoming traffic etc. ).
- NAT punching is nice, but only when it works. The player often needs to configure his router and even that is not a guarantee to run the game without trouble. I personally love to play FPS games over RTS games because I always had problem with NAT punching.
- Cheating is the nemesis of current gen FPS games, not lag. Adding other options to cheat isn't the best idea.
The updates would be sent to the server as well for checking purposes.[/quote]

If they are sent to server, then server latency will determine how long authoritative state lags behind. If server has latency of 1000ms and P2P latency of 20ms, then players will go on, seeing stuff happen, only to be snapped back after 1 second.

Exactly same effect would be achieved if P2P isn't used and each client merely blindly animates stuff ahead of time. While there might be a few less bullet effects, overall experience would remain dominated by master server. So goal again becomes keeping that latency down to manageable level.

In practice, such multi-tier systems simply add too much complexity, with overall experience still dominated completely by slowest player. That player will either have a high latency that makes in unplayable or others will be handicapped/rewarded for having low latency. Either of those, regardless of technical solution, isn't desirable.
@Ashaman73:
I believe that lag is still an issue in some situations. For example, in more remote countries the local servers are often considered low prestige, or they want to play at odd times when many people in their country are asleep. Therefore they hit servers in the US or Europe. The irony is that there may be more "local" players on overseas servers than on local servers at times. I appreciate that NAT punching doesn't always work. The system would have to work correctly if it's not available. As for cheating... yeah, fair point. As always it's a tough one.

@Antheus:
I haven't fully thought it through, but I think you could limit snap-back. For example, when the server sends state you ignore what it says about the players you are directly connected to unless (a) it says the other P2P client has broken rules (b) it says another player you aren't connected to P2P interacted with a player that you are connected to P2P or (c) it says the environment etc has interacted with the P2P player.
For the cheating problem, you could make player B send the position it received from player A to be checked to the server in case player A lied to B but not the server.

o3o

This topic is closed to new replies.

Advertisement