🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
keeping track of a high rate of fire gun
Author
I am thinking of just putting the positions of the bullets, the client fires in a periodic snapshot instead of immediately sending the infomation.
however if the client is firing at someone right next to it, but by the time the snapshot gets to the server the bullet may have already passed the target the client was firing at. I really dont want to have the server back track each bullet, that will really be a pain in the ass.
any other solutions anyone?
Wait, do you mean that the client sends "my bullets are here and here and here at this moment" messages to the server? If so, I don''t think that''s a good scheme, mainly for the reason you stated.
Perhaps you can check if the "target" character intersects with a line drawn between the bullet''s position and it''s last position.
Perhaps you can check if the "target" character intersects with a line drawn between the bullet''s position and it''s last position.
The trick isn''t to change your collision detection, but rather your network setup. Before a bullet leaves a weapon, the message from the client should be recieved by the server. Then the server starts the bullets movement and tracks it. The server then confirms the bullets launch to the client.
~Michael Sikora
~Michael Sikora
Don''t use points to indicate bullets, use line segments. That way if the line segment of the bullet passes through the enemy it has been hit. The start of the line segment is the old position. The end is the new position.
Author
that isnt the problem, the problem is say I have a chain gun that fires 30 / sec, now if I send a packet for each bullet fired that means Im sending 30 packets a second. the UDP header overhead for this alone is ugly!
ah, i see...
just have your gun fire in "bursts"... that is, even the quickest click will fire 5 or 10 rounds (pick a number)... then, if the player is holding down the fire button, the client only has to send one packet for each burst... for example, with your 30 rounds per second scheme, and 5 round bursts, you send 6 packets/second (assuming the fire button is held down) instead of 30. the client program can limit the firing (as if someone out there can hit the fire button faster than 6 times a second) so that the bursts do not overlap.
hell, if you want, rather than sending "bullet fired" packets, you can send a "start firing" and "stop firing" packet (for a chain gun anyways)... that''s only two transfers! lag might lead to the waste of ammo though (although if you don''t have plenty of ammo you shouldn''t be shooting your chain gun anyways).
just have your gun fire in "bursts"... that is, even the quickest click will fire 5 or 10 rounds (pick a number)... then, if the player is holding down the fire button, the client only has to send one packet for each burst... for example, with your 30 rounds per second scheme, and 5 round bursts, you send 6 packets/second (assuming the fire button is held down) instead of 30. the client program can limit the firing (as if someone out there can hit the fire button faster than 6 times a second) so that the bursts do not overlap.
hell, if you want, rather than sending "bullet fired" packets, you can send a "start firing" and "stop firing" packet (for a chain gun anyways)... that''s only two transfers! lag might lead to the waste of ammo though (although if you don''t have plenty of ammo you shouldn''t be shooting your chain gun anyways).
Author
krez: yeah I thought about implementing a 1 click shoots a burst and it looks like Im gonna move forward with that.
or you could have one click equals one bullet. then as the chaingun speeds up, you start to cluster the bullets. so it would go:
if held for less then x milliseconds
send 1 bullet
else
send cluster
this will still allow single shots while efficently allowing you to ensure good use of network bandwidth.
if held for less then x milliseconds
send 1 bullet
else
send cluster
this will still allow single shots while efficently allowing you to ensure good use of network bandwidth.
Another effective method is by using a "cone".
I''m not sure if your bullets spread, or just fire straight the way they''re fired to, but in both cases, you might use a cone to represent all bullets. Then use a random (but still relatively accurate) method to determine how much health/hitpoints (or whatever you use) the player should lose. I believe Unreal Tournament does the same with the minigun.
I''m not sure if your bullets spread, or just fire straight the way they''re fired to, but in both cases, you might use a cone to represent all bullets. Then use a random (but still relatively accurate) method to determine how much health/hitpoints (or whatever you use) the player should lose. I believe Unreal Tournament does the same with the minigun.
Still, there''s nothing to stop you from bundling several "bullet was fired" events into a single UDP packet. True, for a chaingun there are those combining methods that several people described, but you should always try to send _all_ updates for one frame in a single packet. Otherwise the UDP overhead is just too high, just like you said.
cu,
Prefect
One line of sourcecode says more than a thousand words.
cu,
Prefect
One line of sourcecode says more than a thousand words.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
