collision detection security

Started by
2 comments, last by Raloth 20 years, 8 months ago
How does this sound for making bullet-player collisions secure? -player sends message to server saying ''I shot this bullet at that direction'' -server verifies that the player can do this (has the right weapon and ammo, etc...) and sends confirmation packet with a bullet id -when a collision is detected by the player, it sends the bullet id, enemy hit, and position of bullet -server verifies the collision with a rough test and sends the necessary info to other players Obviously this can still be hacked by editing bullet ids and such, but it would require a lot of work and when the data is changing all the time it would be hard to do much. I''m trying to minimize CPU usage on the server. The only (real) problem I can think of with this (blatant hackers would get banned right away) is that if the collision happens outside the range of other players that are being kept track of, the bullet is pretty much ''lost''. Is there anyway to get around that limitation? The server could send more player information if a bullet goes outside of a certain range, but I will also be on a tight bandwidth limit .
____________________________________________________________AAAAA: American Association Against Adobe AcrobatYou know you hate PDFs...
Advertisement
Looks ok to me, but the server will want to keep track of your weapons and ammo too. I wonder if bullet-based causes an ambiguous situation (which weapon was it fired from?). Here's a weapon-based approach that you could adapt to both single fire and auto fire. I just made it up and no I'm not an expert... just offering my $0.02

Single shot:

Client- (FIREWEAPON,position,weapon_id,direction)

Client- predict collision and begin "enemy staggers" animation

Server- determine collision

If out of ammo: Server- (NOAMMO,weapon_id)

If hit: Server to clients- (HIT,object_id,damage_type,damage_amount)

Client- show appropriate resulting animation

Multi shot (flame thrower, automatic fire, etc):

Client- (BEGINAUTOFIRE,position,weapon_id,rate_of_fire,position_velocity,aim_velocity)

Client- predict collisions and begin "enemy staggers" animations

Server- determine collisions

If out of ammo: Server- (NOAMMO,weapon_id)

When done firing: Client- (ENDAUTOFIRE,weapon_id)

When changing aim sweep: Client- (AUTOFIREUPDATE,new_position_velocity,new_aim_velocity)

Any hits: Server to clients- (HIT,object_id,damage_type,damage_amount)

Client- show appropriate resulting animation


Analysis:

The bullet-based is still just as good for single-shot as long as the player only has 1 weapon armed at a time (so the server can check your ammo).

I don't know how the auto weapon could be done bullet-based with low bandwidth. The position velocity could be left out if you assume the position follows the player's position. The aim velocity would include the angle of the aim and which way and how fast it is sweeping.

Using the "stagger until verified" approach doesn't look that good for instant-kill shots, but it can prevent a lot of weird behavior in a lagged network, such as an "instant kill that really wasn't" scenario.

[edited by - 5010 on August 6, 2003 9:09:07 AM]
-solo (my site)
quote:Original post by Raloth
How does this sound for making bullet-player collisions secure?

-player sends message to server saying ''I shot this bullet at that direction''
-server verifies that the player can do this (has the right weapon and ammo, etc...) and sends confirmation packet with a bullet id
-when a collision is detected by the player, it sends the bullet id, enemy hit, and position of bullet
-server verifies the collision with a rough test and sends the necessary info to other players


I think when the player says "i shot a bullet" the server should know where the bullet is going, because the server should know where they are and where they are facing. Of course it could accept the direction and verify it just to save processing time.

And the server should detect collisions, anyone can easily modify the client to stop moving bullets around, theoretically making them invournable. Then again if all the clients are sending the message to the server every time a collision is detected it will get alot of the same messages. It sucks making a real time game secure, and thats why my first online game was tile based
"And the server should detect collisions, anyone can easily modify the client to stop moving bullets around, theoretically making them invournable.

No, it would make it so they couldn''t hit anyone . Collision reports would be sent to the server by the person who shot the bullet, and the server makes sure that the collision really happened (with a simpler check to save processing - this will also give it some buffer space for lag). Now that I think of it I don''t even need to send the position of the bullet... I realize someone will find a way around this, but if they do then it will be so obvious that they will get kicked off the server in an instant. I just don''t want to ban some guy from "experimenting"...this should only get the hardcore ones who go down and disassemble the program.
____________________________________________________________AAAAA: American Association Against Adobe AcrobatYou know you hate PDFs...

This topic is closed to new replies.

Advertisement