🔒 Locked

Who handles collision detection/response?

Started by SGreth Jan 18, 2004 at 11:17 AM 13 replies 1.7k views

Original Post

Jan 18, 2004 at 11:17 AM

In a client/server archetecture who should handle the collision detection? Consider the following, somewhat complicated, solution. -Each client does their own collision detection of their object (say the space ship they''re flying). -The server does collision detection for all AI objects. -The server does collision detection for all weapons to help prevent client-side hacking. Any comments/ideas on this solution? More importantly, I''m interested to see how everyone else is doing collision detection and response in a client/server environment. Thanks, ~S''Greth

liquiddark

Jan 18, 2004 at 12:19 PM

In the Unreal Engine, as an example, both sides do it. The server does it authoritatively, however, so the client is just giving the player an approximation of the actual result.

ld

SGreth

Jan 18, 2004 at 12:19 PM

I was originally going to use that approach but my concerns were the following.

1) If the server doesn''t do collision, how can AI objects do any pre-emptive collision checking.

2) Is it secure to have clients doing their own weapon hit-checking. I could see a quick hack where the client just sends out messages saying "I hit obejct X" even if they didn''t. Of course you could *try* and previent this with encrypted packets and other preventative measures, but they aren''t foolproof.

SGreth

Jan 18, 2004 at 12:26 PM

quote:
Original post by liquiddark
In the Unreal Engine, as an example, both sides do it. The server does it authoritatively, however, so the client is just giving the player an approximation of the actual result.

ld

That was kind of the approach that I was thinking about. Each client does collision detection for it''s body/hull/object, but when it comes to weapons the server should be the authoritative testing agent for those objects.

psykr

Jan 18, 2004 at 12:27 PM

I think that the client should do all of its own collision detection so that it can render the game even when the connection is laggy, but the server should do its own collision detection to prevent hacking, and override the client if the results differ.

SGreth

Jan 18, 2004 at 12:30 PM

quote:
Original post by psykr
I think that the client should do all of its own collision detection so that it can render the game even when the connection is laggy, but the server should do its own collision detection to prevent hacking, and override the client if the results differ.

As an example...
With this approach a client would do the collision detection for weapons (to display the special effect of a laser hitting an object...) but the actual damage would be dealt out when the server detects the collision.

this sounds like a good way to do things.

BarnyardMessiah

Jan 18, 2004 at 12:46 PM

It''s how the Torque Game Engine works,

and it was good enough for Tribes.

SGreth

Jan 18, 2004 at 12:55 PM

quote:
Original post by BarnyardMessiah
It''s how the Torque Game Engine works,

and it was good enough for Tribes.

If that''s how Tribes did it then it''s good enoguh for me!
Long live Tribes

what a great game.

Taulin

Jan 18, 2004 at 1:41 PM

Any time the client is allowed to make world state changes, it leads to cheating and stabability problems, much like a peer to peer network game works, and why most people choose client-server now.

The server should do world calculations like hit detection and such to keep the game world data accurate, and send out delta info. The client should do only the amount needed for prediction (i.e. starting with QuakeWorld). Again, it is good if you can let the client do some of the work, but be carefull of cheating.

interNEKO

SGreth

Jan 18, 2004 at 6:28 PM

quote:
Original post by Taulin
Any time the client is allowed to make world state changes, it leads to cheating and stabability problems, much like a peer to peer network game works, and why most people choose client-server now.

The server should do world calculations like hit detection and such to keep the game world data accurate, and send out delta info. The client should do only the amount needed for prediction (i.e. starting with QuakeWorld). Again, it is good if you can let the client do some of the work, but be carefull of cheating.

interNEKO

Do you have any reccomendations as to how much processing the client should actually do? How laggy/appropriate would it be for the clients to only report delta''s in speed and orientation and then have the server relay that info to all other clients?

BarnyardMessiah

Jan 18, 2004 at 6:57 PM

The Torque handled it by using warps.

Both client and server ran the physics, the server would then send object "states" to the clients.

So, if there''s network lag, the client would keep the objects moving to their physical properties. If a player is falling in an arc from the last state update, then between state updates chances are its still falling in an arc.

When the state frame arrives to the client, then the client warps the objects to match the server state frame.

Inmate2993

Jan 18, 2004 at 11:00 PM

One important reason for having it server side. Bots, Patches, Hacks, Clones. If the collisions are client side, the client can be hacked to remove the collision detection.

Taulin

Jan 18, 2004 at 11:11 PM

quote:
Original post by SGreth
Do you have any reccomendations as to how much processing the client should actually do? How laggy/appropriate would it be for the clients to only report delta''s in speed and orientation and then have the server relay that info to all other clients?

Sorry, I didn''t mean it that way. The server reports deltas TO the client. It is important that the client recieves them though, so you might consider sending whole world states ever X seconds for full sync (depending on game,and importance priority).

Think of it this way. The client''s screen is a window to the server. The client''s controls are only inputs to the server.

As I said, and Inmate confirmed, anytime the client does calculations that change the real world state, you are opened for hacks.

interNEKO

SGreth

Jan 19, 2004 at 6:55 AM

quote:
Original post by Taulin
quote:
Original post by SGreth
Do you have any reccomendations as to how much processing the client should actually do? How laggy/appropriate would it be for the clients to only report delta''s in speed and orientation and then have the server relay that info to all other clients?

Sorry, I didn''t mean it that way. The server reports deltas TO the client. It is important that the client recieves them though, so you might consider sending whole world states ever X seconds for full sync (depending on game,and importance priority).

Think of it this way. The client''s screen is a window to the server. The client''s controls are only inputs to the server.

As I said, and Inmate confirmed, anytime the client does calculations that change the real world state, you are opened for hacks.

interNEKO

I follow you on that one. It sounds as though doing all collision on both the client and server is the best way to go. The server is the ''authoritative'' peer in the network though. The clients just do their own collision for the gaps where their interpolation of the objects last state says they hit something. When the server updates the object it can be warped back into place if it''s really out of sync.

Thanks!

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.