I'd like some opinions as to whether you think that I should pursue collsion on the client end or the server end of a persistant world space sim. Here's the advantages I'm seeing for each side: Server- * Prevents possible cheating by clients * Only one reporting of a particular collision to deal with (where as if a client did reported it, and two client's ran into each other, I'd get the collision report from each client) Client- * Takes load off the server * More 'instant' response; latency won't make the client bounce around Any input would be great!

The server should definitely handle anything and everything that can affect the game state, not just to prevent cheating but also to maintain synchronization across different clients so everyone is playing the same game. But latency is also a big issue, so you'd also want to perform some sort of client-side prediction. A common method is to run the same code on both client and server so that the game appears responsive to all clients, and have the server update and override the clients' game states every now so that all states are in sync. Since both client and server are running the same code, the updated states won't be that far off from the predicated states, unless something really drastic happens in-between updates or a client has a particular high latency.

The server will of course have a higher load since they're processing all the clients, but that's a necessary evil. You could try splitting the game up into several zones, and have multiple servers handling different areas of the game. Then have something like a portal server that acts as gateways between zones, connecting players to the different servers as they travel through your game world. Or you could opt to have entirely separate instances of the game altogether, and players need to chose which instance of the game they want to join when they register. At any rate, the client load should be low since the server only "tells" the client the minimum amount of information it needs. For instance, no need to tell the client about players on the opposite side of the world if they can't interact.

Bumping over to MP/N.

Actually there are conditions for doing the work on the client - providing game state isn't affected.

Say for example your explosions produce random clouds of debris fragments which bounce off ships / other objects but will never do damage or block firing. These could best be done on the client (since they don't affect game state at all) where you could throw much more complicated physics at them, without having to distribute results. Similarly ragdoll physics (should you use it) can be done on the client, with overall position of the object forced to a simple point based physics system updated from the server. This can save a lot of CPU at present, but be aware that physics accelerators are on the rise, so this paradigm might change, depending on how well the industry adopts them.

But for anything state critical (shot paths, actual 'entity' positions) the server should be authoritative.

Basically what was said above. Anything that can affect the actual playing experience has to be done on the server so it's synchronised – collisions definitely come uder that category! But clients can predict major interactions so the game seems more responsive; with action games this is standard practice and with a ping of 200 or more is essential to avoid making the game jerk.

But as winterdyne says, visual effects which don't make much difference can be done on the client. Who cares if the smoke field on my screen doesn't precisely match that on another player's ... ?

Thanks for the input, everyone. What you've said is pretty well inline with what I was thinking already, so thanks for the confirmation!

Particles, junk flying around, rocks on the ground, all that stuff that doesn't effect the actual game, do it just client side and don't even consider it as being processed on the server side. All that was already said though.

But as for actual terrain collision detection, personally have found it best to do anything that is just required for graphic representation only client side[like in a rts, who cares if the server correctly manages the exact [y]height of every unit, so long as it's position on the x-z plane is correct, and just use the height for vision, ect.]. Do anything that is required for actual game processing on both [like the x-z plane object collision tests on the above example], and optimize the server to assume that collisions nearly never take place, becuase the only time when they DO take place, is when the player is a cheatin'. Do dynamic object collision on both also, assume no collisions on server, but don't just jump to the conclusion that the player is up to no good in the case of a collision, but instead take it as an instance when you need to re-sync that player. Stuff like bullets shot and such, calculate only against what the game logic actually considers [like a bounding box] in the actual server checking, and leave the details to be fleshed out by the client [tell the client that player X was hit in the bounding box registering a hit on the left leg from direction v or something, and let the client decide that means a blood spot on the left knee and a spat of blood on the wall behind it and a cloud of blood mist coming out, and the bullet making dust as it hits the wall behind him and throwing little pebbles.]

It's too obvious probably so it was not mentioned yet but one thing you have to ensure is that you run the same fixed update rate on all peers. Any reasonably fast simulation will give different results with varying update rates. Here are a few more things to consider. Updating a physics simulation to take an event into account that has happened in the past is very hard or impossible so it is required to update the motion state of all actors that have been affected rather then simply sending the event. A very subtle difference in a simulation may cause or not cause a collision to happen and a collision is an event that likely creates large differences in a very short amount of time. Almost any physics engine uses a concept of simulation groups (Actors may belong to a specific group because they are spatialy related or connected by a constraint, ...), you may exploit that to your advantage. If you have groups of single actors those may be predicted by a client with high accuracy and may be synced lazily. For groups with more actors the server should be authorative and you may consider using non coliding, driven or predicted actors on the client and update the motion state from their fully dynamic peers on the server. Depending on the level of access and complexity of the simulation you may exploit further optimizations already in place to save additional bandwith or create more stable solutions.

In my current game I have a different approach...

This is a high action game, so waiting for the result when you act going to the server and back is impossible.

There are four players, and you play with a ball... All systems run the physics simulations, and the syncronization is done truogh a couple of rules:

The server tells the clients when the ball is affected by a wall or a player.
The client is alowed to ignore the messages from the server if the ball is realy close to this clients player.
The client sends updates about the ball the the server when he hits it.

Its not hacker safe, but my game is small, so I hope that this problem will be small...

After adding some smothing on the syncronisation, and then design the game on the serverpart so that the ball can do some jumps, I manage to get alsmos instant reactions with wery little penalties...

What happens when the ball hits something, and all other gamestate stuff is done on the server, exept the high speed ball, and the players pads...

-anders

for my action game, i run all collision detection on both client and server.
the only difference are the collision handlers: on the client no hit will do damage. that means shields of spaceships will flicker when hit by some laser, even if it wasnt hit on the server. it also means when you have lag, you can fly through other ships and planets. but those cases are rare and hard to notice. i think this method is pretty easy.