Pure client side collision detection with server as the referee?
Author
The environment involves 64 players in light FPS combat.
#1 - Is there anyway to avoid collision detection on the server and leave it all on the clients machine?
#2 - Is there a known method that is widely used that I can google or research?
If you do that, then your clients will need to send the position, orientation, ect... of the local player to the host (instead of inputs), who would relay them to the other clients.
It's basically client-side prediction without the server as authority, so opened to abuse (think Counterstrike speed hacks).
Why do you want to not do the calculations on the server? If it is because of input lag, then you can do the tried and tested client-side prediction, and server corrections, like most FPS do. The technique is best explained here.
If it is because of performance issues, I'd try to see if optimising the physics code would make it possible, because you do not want the clients to have complete authority over their physics. If you are thinking of doing simple sanity checks on the server to detect cheating, that can be quite complicated and 'flaky', prone to false positives and negatives.
another good source for multiplayer physics is the Source Network Physics Article.
It's basically client-side prediction without the server as authority, so opened to abuse (think Counterstrike speed hacks).
Why do you want to not do the calculations on the server? If it is because of input lag, then you can do the tried and tested client-side prediction, and server corrections, like most FPS do. The technique is best explained here.
If it is because of performance issues, I'd try to see if optimising the physics code would make it possible, because you do not want the clients to have complete authority over their physics. If you are thinking of doing simple sanity checks on the server to detect cheating, that can be quite complicated and 'flaky', prone to false positives and negatives.
another good source for multiplayer physics is the Source Network Physics Article.
Author
Good read.
It seems to me the practice is simply not done. Everyone seems to be using an authoritative server for collision detection.
It seems to me the practice is simply not done. Everyone seems to be using an authoritative server for collision detection.
In general yes. The problem of running physics on the server is minimal compared to keeping the game hack-free and keeping a level playing field.
But, you know, horses for courses.
But, you know, horses for courses.
Author
I'm still wondering. What if you want to house 200-400 players in one small area? Wouldn't doing everything client side take a HUGE load off the server?
Quote:Original post by luzarius
I'm still wondering. What if you want to house 200-400 players in one small area? Wouldn't doing everything client side take a HUGE load off the server?
You don't, bandwidth becomes too much of a problem when you try.
if all players are in a small area you get quadratic bandwidth usage for the server (going from 50 to 100 players doubles the data you need to send to each player and also doubles the number of players you need to send the data to), even if you only send 28 bytes per player each update (position vector + orientation quaternion) you'd hit 28*199*30*8 / 1024 = 1305 kbps per player with 200 players and a 30hz update frequency. (actually you'd need a bit more due to ip overhead, but we'll ignore that for now)
That basically means that each player needs to have atleast 1.3Mbps bandwidth downstream, and the server needs a bit over 260Mbps upstream.
If you throw in a bit of fighting and other events things will quickly get alot worse, going to 400 players would push server bandwidth above the 1Gbps point, you can reduce the update rate and compress the data, but the scalability issues are pretty much a fact of life, keeping the players separated is necessary.
As it is today the main limiting factor is bandwidth, both on the client side and the server, trying to save cpu cycles on the server is pretty much a waste of efforts since bandwidth is what costs money.
Quote:Original post by luzarius...Everyone seems to be using an authoritative server for collision detection...
I'm still wondering...What if you want to house 200-400 players in one small area? Wouldn't doing everything client side take a HUGE load off the server?
It seems you still don't understand the implications of why collision calculations have to be done server side to stay authorative and in addition to what SimonForsman already said, take the following use case as an example.
Your client does compute collision detection. He is in front of a wall and wants to go through that wall. You said, your server is authorative over the obviously happened collision, but your server just got the move command from the client. No hints that a collision happend. So how the server knows that there should happen a collision if it doesn't do the calculations itself?
The server can't!
But how the server can detect that hack than? There has to be a third entity involved to verify the clients movement. Now that third entity can be another client, independent from the first. But that client can send false commands too. Remember, we just can't trust each client. Now we are screwed, or we let the server itself be that third entity.
That means the server has to do collision checks, and it needs all relevant information to do that. So there is no way around to server side collision detection and the involved computation in case you want a cheatfree multiplayer architecture (if you take the distributed approach of a peer-to-peer architecture there isn't that one authorative master peer, otherwise you are back to a client-server architecture).
And that means for your example of 200-400 players in one small area a lot of physical computation for the server if you want happy players, or a lag free experience if you want happy cheaters ;-)
Quote:Now that third entity can be another client, independent from the first. But that client can send false commands too. Remember, we just can't trust each client
What about choosing that other client randomly, or at least having it change over time ?
This way, the only durable cheating possibility is that all the players on the server cheat.
If your game is just about competition between players, that could be enough (it would not be enough if the game is cooperative and you record the players' achievements).
The server either validates the positioning, or doesn't. If the server validates positions, then the server has to simulate the physics. Otherwise, the server has no way of knowing what the state of the world is without relying on the clients. But the client already cannot be trusted, so if they are hacking their position, they will just hack the validation, too. Having the server keep track of its own world state also removes the issue of two clients having contradicting physic simulation results. A common example is in FPSes. Player B sees in their screen that they just finished running past a wall out of Player A's site, but then player A still gets the shot and kills them. Player A's state says they got it, Player B's says they did not, and both states are correct as far as the client is concerned.
Don't over-complicate it. Just do it, or don't. If you want it to be a fair game, then just do it. Physic simulations are not often THAT expensive. Its more important for a server to be scalable than run slightly faster.
Don't over-complicate it. Just do it, or don't. If you want it to be a fair game, then just do it. Physic simulations are not often THAT expensive. Its more important for a server to be scalable than run slightly faster.
Quote:Original post by SimonForsmanQuote:Original post by luzarius
I'm still wondering. What if you want to house 200-400 players in one small area? Wouldn't doing everything client side take a HUGE load off the server?
You don't, bandwidth becomes too much of a problem when you try.
if all players are in a small area you get quadratic bandwidth usage for the server (going from 50 to 100 players doubles the data you need to send to each player and also doubles the number of players you need to send the data to), even if you only send 28 bytes per player each update (position vector + orientation quaternion) you'd hit 28*199*30*8 / 1024 = 1305 kbps per player with 200 players and a 30hz update frequency. (actually you'd need a bit more due to ip overhead, but we'll ignore that for now)
That basically means that each player needs to have atleast 1.3Mbps bandwidth downstream, and the server needs a bit over 260Mbps upstream.
If you throw in a bit of fighting and other events things will quickly get alot worse, going to 400 players would push server bandwidth above the 1Gbps point, you can reduce the update rate and compress the data, but the scalability issues are pretty much a fact of life, keeping the players separated is necessary.
That's not necessary the case. You do not need to broadcast peer-to-peer, but you can send to server that will relay the information to other clients. In that case, the client bandwidth requirement is constant.
The good thing with the current server correction / client-prediction technique, is that can actually very easily change the authority from server to client, but having the client ignoring the correction packets, and the server not actually processing the client predictions, but taking them as they come. Then you change the 'mode' of operation by simply flicking a switch.
That also means that a hacker could hack your code and always switch server authority 'off' if you are not careful. :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
