Hi,

over the past weeks I've been trying to get the basics of how to "fight lag" implemented. So far things are going veeery slow, and I think I might have attacked it from the wrong angle.

Here is what I have today;

The server sends a update every 1/25th of a second. This updates includes; Ack, Ackbitfield[From www.gafferongames.com], Object ID, Position, Velocity. The client wait till it has received 10 packets before it starts rendering.

Now here it all stops and I'm sitting here with all these questions... How should I render it client side? I've tried to re-implement gafferongames code but I just can't seem to get it right, I still have plenty of jitter and lag - and that is when testing locally.

Why should I re-send a "position, velocity" packet from the past? I just can understand why I would send a position, velocity packet that is already in past time.

When receiving a packet on the client, should I include a time stamp from the server or should I use the clients time? Should I synchronize the time between the client & server? If so; how?

How should I handle player input "from the past"? Since the client is rendering 1/25th * 10 later than the server, how should I handle shooting? Like the player shooting a zombie that was there 1/25th * 10 of a second ago on the server but is currently right in front of him on his screen.

1. From what I understand from GafferOnGames.com 10-30 packets per second is "common"? And while we're talking packets, should I send one packet per entity update or pack many entity updates into one packet?

2. Well, I'm _trying_ to use interpolation - and if I have gotten anything right at all the, looking at both Valve/Source Engine & GafferOnGames the clients rendering time is delayed by some amount?

Is there any book specific to this topic? The only one I found on Amazon is just talking about the different techniques, not how to implement them.

1. Pack as much relevant data per send as you can. Start to throttle back some only if you are encountering bandwidth problems.

2. You have it wrong. The renderer should render what it can as soon as it can. The only reason to force your renderer to wait is if you are purposely cutting back the framerate.

Interpolation should occur in the client side code per update. Use whatever came in from the network and do a "confirmed" position update on those entities. For the remaining entities, you will use position, time, velocities, etc. to give it an "estimated" position.

So what I should do is, the second I get some data, I chech if my interpolated entitys position isn't too far away from the position I just received. If it is; snap it in place. Then I start using the new velocity I just received?

How does this go for clients shooting at each other, or shooting at a AI?

And this method is applyable when using Box2d or some other physics engine on the server side?

Every time your client side code runs it's game loop, it should do something along these lines:

1. Get network data (which will contain information about server side entities)

2. Create and/or update entities (using the above data)

3. For every entity that was not just updated, run an approximation

4. Do other client side stuff (process input, send network data to server, render frame, etc...)

If you want to compensate for lag beyond this point (which I think you are asking) you must first have some way to measure lag. The easiest way is to send a ping message to the server and count the time it takes to get a reply to that ping. This is your "lag_time." Then when you receive an entity update from the server you take its position, velocity, and "lag_time" to estimate where that entity is at on the server (since you know you are at least "lag_time" behind). For the entities you have been approximating (as I described above) you simply add "lag_time" to the time you were using to begin with.

This has no affect on shooting or server side physics. When you press the shoot button, you should send a message to the server saying that you "request" to shoot. When the server receives a shoot request, it performs the shoot action. Your client should get entity updates to reflect this ("shooter" entity will be in a shooting animation, the "victim" be in a dying animation) as well as other supporting messages from the server (ex. a create muzzle flash here message, and create blood splash over there message, etc...). The only thing that is affected is where the client is aiming when he pressed the shoot button.

I hope this helps you understand a little better. I am trying to keep my explanation as simple as possible.