Sending bullet positions?

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

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.

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.

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.

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 :-)

In my oppinion a normal bullet/laser/rocket needs only following informations to be synchronized:
- Position: x0, y0, z
- Direction: dx0, dy0, dz0 (or a quaterion, whatever you use)
- Velocity: v0
- Acceleration: a (if needed eg. for rockets)
If you got granades, that physicaly interact, the situation is a little diffrent, since the correct physical properties (position, reflection, velocity) can depend on the framerate of the client(s) - depending on the physics engine implementation. Now you will have to choices:
1. The server tells where the granade will detonate and deal damage to the surrounding objects. Don't care about where the client realy draws the granade. Worst Case: A granade will seem to by far away but actualy is nearer.
2. More synchronization work for a bouncing granade

Point2: You could think about only sending informations of the granade only if it's position,direction or velocity changes (synchronize on change). If you would like to have granades like in Quake, which bounce on the floor and loose movement energy so their bouncing and the hops get smaller you can decide to not send all bouncings, since with small movmenent energy also the inaccurancy of the granade will become smaller.

Hope this helps a little,
patrick

Quote:

- Direction: dx0, dy0, dz0 (or a quaterion, whatever you use) - Velocity: v0 - Acceleration: a0

Actually, if you know the type of the bullet, then the acceleration can be a function of the type and time since launch, so you don't need to send that. For directly and velocity, you just need to send a velocity vector with magnitude == speed; orient the bullet mesh in the direction of travel, and with world up. Thus, five values reduced to three!

In my game, I had mostly rapid-fire weapons. So the server just let everyone know when a player started and stopped firing. No information about the projectiles whatsoever was sent over the network. It was just assumed that the clients' displays would be good enough that the visual would match any corresponding health decreases.

It worked very well.