I know this has been asked before but I never saw a thread that really gave a solid answer. how often should packets be sent for a multi-player game. I am making a multi-player space shooter where you can go around the universe shooting all the other players......there is much more to the game but that is all that is important for my question. What happens in my game is that the motion is choppy. In the data packet, I send x, y positions and x, y velocities and i have each computer interpolate the other players positions in between packets by using their current position, their velocity, and the time elapsed. And then when a packet arrives, I update the other players position to be the position in the packet. So the reason why it is choppy is because the interpolated position on the computer may not exactly corespond to the actual position received in the data packet and therefore the image on the screen will jump from the interpolated position to the actual position in the data packet. What should I do ? Will just sending data packets more often solve the problem ? Right now I am sending 5 per second. "Now go away or I shall taunt you a second time" - Monty Python and the Holy Grail themGames Productions

There''s a technique called cubic dead-reckoning (there''s an article on gamedev about it). You do the same thing you are now, except add acceleration & jerk to the packets as well.

The trick is in how you calculate those coefficients. I''m not sure which of the two following methods is better: Just use the last 4 position points and creating a perfect poly fit, or use the last 6 or 8 or so points and creating a best-fit poly.

I''m not quite to the point that I need this code yet, so that''s all I can offer for now.

...
Also, how did you syncronize the time on the computers?

i am not sure what you mean by synchronizing the time. All my movement is time based. I just calulate how much time has passed since the last time I drew the screen and see how much the player should have moved during that period of time. So it doesnt matter if one computer is running faster then another.


"Now go away or I shall taunt you a second time"
- Monty Python and the Holy Grail
themGames Productions

C3P0, Are you accounting for lag with your scheme? If you come up with a scheme to synchronize with the server, you should see a couple different ideas for how to deal with lag. Cubic dead reckoning isn''t so much a method of dealing with it, as a way to predict client motion so that it''s not so much an issue.

Well ncsu121978, There are several possilbities for your choppyness.

-packet clumping could cause you to update several packets on a tick.

-at 5 ups its about 200 ms per update. Assuming that your framerate is more than 5 fps, you could be reciving updates slightly out of step with your frame rate. Lets say your framerate is at 30 fps, in a perfect world you would recive the update packet at frame 6,12,... etc. If you recive a packet slightly after a frames update, you incure the penalty of waiting for that frame to render, which at for 30 fps can be from 1 - 33 ms. So there is a 1-33ms lag slapped onto your update data which you might not have accounted for, and this could be the cause of the jerkyness.

-If you have a variable frame rate (fluxates alot) then this would exacerbrate the problem above, as it could be many times more than the minimal update lag mentioned above.

-Lost packets results in miss of a critical update packet which then is corrected by the latest correct packet. Packet loss comes in 2 falvors, the loss through the communication and the loss of packets rejected by the simulation for what ever reason (time out mostly).

To handle these problems you''ll need :

-a way to sychronize timmers so you can reasonably tell how much time as past since a packet was created on the mutal simulation.

-a time tag for packets so you can do above

-bundle previous update state packets with the current packet to compenstate for loss. (remeber bandwidth is always increasing, latency isnt getting much better), i suggest 1 update state history.

-simulate the current state of the entity based upon the most accurate data aviable, even if its old (timed out packets), new packets on the queue but whose current client time has not yet reached (future packets!).

Paradoxically you dont need to update more, though a higher update rate will reduce the update latency and bring it closer to the therotical optimal latency imposed by the communcations, to get a smoother simulation. 5 ups if fine for simulation of smooth motion, if you use these techniques.

Good Luck

-ddn

sorry, but i really didnt understand much of what you put above this post. I just didnt understand it. But I do know why I have the choppiness.
Right now I am testing this on a LAN whose connection speed is at T3. I am sending 5 times/sec. What happens is this:
I send a packet containing the x, y position and the x and y velocities. Now in between sent packets, a computer will interpolate the position of the other player by
xPos += xVelocity * deltaTime;
yPos += yVelocity * deltaTime;

where deltaTime is the amount of time passed since the last frame was drawn so that the movement will be independant of frame rate.
Now when a player changes directions (and therefore his velocities) in between packets, his position changes but on the other computer ihs ship appears to still be going in a straight line, b/c that other computer is interpolating his position according to the last velocities that were sent. Now at the arrival of the next packet, the position sent with the packet is going to be a little different then the position that your computer interpolated, and from X number of milliseconds ago. What I was doing is just setting the otherShips position on your screen equal to the position reported in the latest packet received, and thus the jump from where your computer thought where he was going to be to where he really is (about 20 to 100 ms ago on our LAN).
What should I do ?


"Now go away or I shall taunt you a second time"
- Monty Python and the Holy Grail
themGames Productions

Update more often?

You may want to try buffering incoming packets. That way you always have the last ten(whatever number you decide) player packets being processed. This helps reduce jerky effects.

Many games interpolate such as you have been doing but they do not do a "hard" update of players positions. If the player in the case you talked about was moving in a straight line, then turned, you would just alter the players course to be approximately what it should. Only do an absolute update if the player is "way" out of sync. Starsiege Tribes does something like this. Players move smoothly but sometimes you can see them "pop" into place.

You will end up with the effect of the opponent following a loose spline-like approximate of where they "really" are.

-AG

It doesn''t sound like the replies so far have helped too much. Basicly, there are two ways you can fix your "choppiness":

a) Better interpolation. -- You''re currently linearly interpolating, you can create a more accurate interpolation using various numerical methods.

b) Making sure the times match up. You might not be accounting properly for the time-gap between sending, receiving, and estimating the position.. especially if your comment about sending 5 times per second is an estimation and you''re actually sending every n frames.

Timestamping just means you add some info about when the object was at that position/velocity: the number of the 1/5 second intervals since the beginning of the game could work. Then you keep a history of the past couple positions and use those to interpolate, updating your history when you get a timestamped packet.

The advantage of this scheme is it leads directly to more complex spline-based interpolation schemes. Good luck -- sorry if I misunderstood your posts and all of this was already clear.

what are other numerical methods that I could use to interpolate ?


"Now go away or I shall taunt you a second time"
- Monty Python and the Holy Grail
themGames Productions