bullets and collision detection
Author
In a network game how would you do the collision detection eg suppose there are two teams of four armed with rifles, if player 1 fires some bullets, would his pc do the collision detection with what he knows are the current enemy positions, then tell the other players (via the server) that he has hit someone and therefore decrease their health
OR
would he simply tell the server that he's fired them and let the server do the calculations and tell everyone else.
I can't work out which one would be best..
cheers
To keep cheating to a minimum id let that be handled by the server.. The client would just send a packet containing the direction in which he fired and let the server figure out if its a hit or not
Mm.. thats not a good idea if theres like, say 100 people on the server.
Instead, have the client send a packet for the gun firing, then have the server just move the bullet without checking for collision (it also tells all the other clients about the bullets initially and lets them draw the bullets) and when the client that fired the gun detects a collision (its the only one that should be monitering for them) it tells the server that it thinks the bullet hit guy x, and the server checks if this is true, if it is then do the damage, and if it isn't then keep track of how many times the client has lied. (IMPORTANT: you have to allow for some wiggle room here, because the clients calulations may not be EXACTLY the same, so just check if it's really close to true)
Instead, have the client send a packet for the gun firing, then have the server just move the bullet without checking for collision (it also tells all the other clients about the bullets initially and lets them draw the bullets) and when the client that fired the gun detects a collision (its the only one that should be monitering for them) it tells the server that it thinks the bullet hit guy x, and the server checks if this is true, if it is then do the damage, and if it isn't then keep track of how many times the client has lied. (IMPORTANT: you have to allow for some wiggle room here, because the clients calulations may not be EXACTLY the same, so just check if it's really close to true)
Hey,
How I've implemented this in my application is sort of a mix of what both previous posters have suggested. When the player fires their weapon, that keypress is logged and added to the message for that frame being sent to the server. When the server gets the message, it checks that there is sufficient ammo, etc. and spawns a bullet in the world, then notifying all client's via a reliable message at the end of the server frame. The server will take into account where it "thinks" each client will be at time X (which happens to be the current time + ( client's ping / 2 ) ) and sends it out.
When the client receives this message, it will spawn a bullet locally and then update it each and every frame based on it's velocity at the time it was spawned. If the client thinks there was a collision, I will simply perform the explosion animation, etc. but will NOT kill the player at this point.
At the same time, the server has been updating the position of the bullet frame by frame (my bullets hit the target instantly using ray tracing, i handle items such as rockets and grenades differently), or in the case of a bullet, has calculated whether or not a hit was registered. If it was, it will damage the player that got hit and send out an update informing all clients of this.
This is the overly simplified version, my client and server are both heavily dependant on prediction on both sides, which in the case of a bullet, the server can say in a gamestate update "If player X is hit with any amunition they will die". But if you're not interested in this, the best way to go about it is have the server calculate collisions and simply inform the client of events, don't have the client inform the server that it thinks client X was hit, the whole idea of a client/server architecture is to have the server govern the execution of the game to minimize the possibility of cheating as much as possible.
Permafried-
How I've implemented this in my application is sort of a mix of what both previous posters have suggested. When the player fires their weapon, that keypress is logged and added to the message for that frame being sent to the server. When the server gets the message, it checks that there is sufficient ammo, etc. and spawns a bullet in the world, then notifying all client's via a reliable message at the end of the server frame. The server will take into account where it "thinks" each client will be at time X (which happens to be the current time + ( client's ping / 2 ) ) and sends it out.
When the client receives this message, it will spawn a bullet locally and then update it each and every frame based on it's velocity at the time it was spawned. If the client thinks there was a collision, I will simply perform the explosion animation, etc. but will NOT kill the player at this point.
At the same time, the server has been updating the position of the bullet frame by frame (my bullets hit the target instantly using ray tracing, i handle items such as rockets and grenades differently), or in the case of a bullet, has calculated whether or not a hit was registered. If it was, it will damage the player that got hit and send out an update informing all clients of this.
This is the overly simplified version, my client and server are both heavily dependant on prediction on both sides, which in the case of a bullet, the server can say in a gamestate update "If player X is hit with any amunition they will die". But if you're not interested in this, the best way to go about it is have the server calculate collisions and simply inform the client of events, don't have the client inform the server that it thinks client X was hit, the whole idea of a client/server architecture is to have the server govern the execution of the game to minimize the possibility of cheating as much as possible.
Permafried-
Quote:Original post by Permafried-
don't have the client inform the server that it thinks client X was hit, the whole idea of a client/server architecture is to have the server govern the execution of the game to minimize the possibility of cheating as much as possible.
Permafried-
/me assumes that last bit was about my post
It wouldn't be possible to cheat with my method, because the server is still in control of the action, it's just distributing the workload. The only downfall to this is if the client that fired the bullets (which would be the one monitering for collision) didn't get the packet to the server saying that its bullet hit, then the server would never notice the impact, and the bullet would keep flying through the target. The odd's of this happening are slim (Possibly if the client disconnected, so to fix that you would have the server start monitering the bullets of clients that don't exist anymore) for example the client that fired the bullet could block the packets for the collision, but that would be dumb and would only help the enemy, because your tracking your own damn bullets, not his :)
So, as you can see, no way of cheating. That doesn't mean people won't try, so you should have a counter for how many attempts at cheating there have been, and increase it when the server notices that even though the client said there was a collision, there wasn't. (Also increase it with sanity checks and that junk) and when the cheat count gets too high (maybe make an option so the server can specify) then you can kick the player, and if he comes back, and cheats maybe half of the limit, just ban the lamer from the server.
This way takes alot more testing though, to make sure players aren't marked as cheaters because of things like crappy latency. It's worth it though, so you can serve a game to x (where x is alot) of clients on a highspeed connection, instead of a T3 one :P
If you tell the server you fired a bullet, then the server would know your current rotation and the bullets built in velocity already. Being said, the bullet cannot be changed via client side anyways and follows the SERVER's physics because the client only told the server, I fired. Sending info to the server that the client hit a ship should be irrelavent, because the server calculated it along with the client. That is, if the client cheated and said i hit the object the server wouldnt care because it know it didnt, therefore move forward. Less traffic this way as well... maybe im off, but this seems best for me.
The client knows where the other guy is, and what the server physics are. Thus, it could send a packet that contains the commands:
- turn so that a fire will hit player X
- fire bullet
- I think I hit X
This is basically how auto-aimers for older games like Quake used to work, AFAIK. Thus, it would be trivially simple to cheat if the client tells the server about what it thinks it hit.
- turn so that a fire will hit player X
- fire bullet
- I think I hit X
This is basically how auto-aimers for older games like Quake used to work, AFAIK. Thus, it would be trivially simple to cheat if the client tells the server about what it thinks it hit.
Flaggr, thats not a bad idea, but you're forgetting about the latency between the client saying "hey, i think i hit that guy" and when the server actually recevies that message. The server will either have to:
1) keep in its memory the last few past locations of everything (timelogged) and have to backlog through that data
2) or reverse predict targets velocity and postion based on the difference between the current server time and when the client thought it hit that person.
so, 1) might be good, but might increase the memory (RAM) usage of servers - although I cant think of any game's server at the moment that use up loads of memory on a decient server box.
2) will be inaccurate when latency is high, perhaps it'll be fine over a LAN, but it'll increase cpu requirements.
The idea does increase client upstream bandwidth and cpu requirements though. It really depends on the game if it'd actually work.
1) keep in its memory the last few past locations of everything (timelogged) and have to backlog through that data
2) or reverse predict targets velocity and postion based on the difference between the current server time and when the client thought it hit that person.
so, 1) might be good, but might increase the memory (RAM) usage of servers - although I cant think of any game's server at the moment that use up loads of memory on a decient server box.
2) will be inaccurate when latency is high, perhaps it'll be fine over a LAN, but it'll increase cpu requirements.
The idea does increase client upstream bandwidth and cpu requirements though. It really depends on the game if it'd actually work.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
