Advertisement

Sending bullet positions?

Started by January 14, 2006 01:43 PM
11 comments, last by BeanDog 19 years ago
Hi, is it a good idea to send bullet positions for all players in a FPS game? The information is only needed for display, so it is not absolutely necessary. Or better let the client interpolate bullet positions with dead reckoning and save some traffic?
--
In my game I send bullet position to all other players and the positions of players I send with accord of distance betwen players alternating the frequency of position packets in server...
If player is near the server send packets whith more frequency(1pack/50 ms) else if player so far other the server send (1 pack/100 ms or 1 pack/200ms)

=\ bad english but I tried to help
Programming is my life!
Advertisement
Whatever you do, only send the position once w/ the velocity. I've never worked on an FPS, but I don't see why there would ever be a reason to send constant updates of a projectile.
FTA, my 2D futuristic action MMORPG
Quote:
Original post by graveyard filla
Whatever you do, only send the position once w/ the velocity. I've never worked on an FPS, but I don't see why there would ever be a reason to send constant updates of a projectile.

Bouncing rockets or grenades are just one example ;)
In my game, the server is the only authority for collision detection and response, so he has to handle this and tell it the clients.
But now I am not sure anymore, if this is a good idea...

@Napalm: What type is your game? How many players?
--
I would send the data required to make a somewhat realistic simulation, for example if we have a bullet with 50 feet/second (have no idea if that is realistic) and which weight 0.5 pound, also it is shot from 0,0,0 against 0,1,1. Then I would send all the data once let the client predict what happens, when the bullet collides with anything I would send a message to the client, also if the bullet bounces of new data should be sent.

If you need a lot of data to represent the path the bullet will take I would only send the most important data, for example a normal bullet's weight might not be necessary since the path will be almost the same if the bullet traveled in a straight line, therefore that could save some traffic.
Quote:
Original post by Enrico
Quote:
Original post by graveyard filla
Whatever you do, only send the position once w/ the velocity. I've never worked on an FPS, but I don't see why there would ever be a reason to send constant updates of a projectile.

Bouncing rockets or grenades are just one example ;)
In my game, the server is the only authority for collision detection and response, so he has to handle this and tell it the clients.
But now I am not sure anymore, if this is a good idea...

@Napalm: What type is your game? How many players?


Well, if the client / server both had the same starting position and velocity, it should bounce off the wall at the same time..... interacting with moving objects though would obviously be more complicated... anyway, just spewing out ideas, like I said I have no experience w/ FPS's.
FTA, my 2D futuristic action MMORPG
Advertisement
When I made a simple 3d fps I did the same thing, I had the client as a rendering proxy...so I wonder, if your server does all the collision/response logic why do the clients need a projectiles velocity? shouldn't you just be sending position and orientation information for rendering.

In my case projectiles were 'bullets' so I modeled them as rays/line segments, however for a bouncing grenade, you'll probably need to do some client-side prediction to make it look smooth (I believe)...I know there's in article on the prediction topic...let me know if you're interested and i'll to my best to find it.
With velocity information, you can do better interpolation/extrapolation when rendering. Thus, even if the client is only a "rendering proxy," you can better support high frame rates if you update with velocity.
enum Bool { True, False, FileNotFound };
Quote:
Original post by hplus0603
With velocity information, you can do better interpolation/extrapolation when rendering. Thus, even if the client is only a "rendering proxy," you can better support high frame rates if you update with velocity.


Since were on the topic...

So is client side prediction needed? I will be facing this problem soon (networked bouncing grenades) and just wondering if you need to predict the 'physics' or just use the position/velocity and interpolation/extrapolation to make all the clients look smooth? thx
Quote:
Original post by valgalder
So is client side prediction needed? I will be facing this problem soon (networked bouncing grenades) and just wondering if you need to predict the 'physics' or just use the position/velocity and interpolation/extrapolation to make all the clients look smooth? thx

Without client side prediction the object movement (players, vehicles, animals, etc.) will be very erratic.
When my webspace is up again, I can show you the difference with two demos ;-)

Before I decide what to do, I will collect some statistics... But updating the bullets only, when an collision occures, sounds quite good :-)
--

This topic is closed to new replies.

Advertisement