Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#ActualDeortuka

Posted 23 March 2013 - 11:43 AM

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.


#6Deortuka

Posted 23 March 2013 - 11:41 AM

The second you get some data about a server side entity, you update your client side entity with that data. You don't check anything. The server has literally just told you where to place that entity.

 

Keep in mind that you do that when you receive network data. That might not necessarily be every frame on the client side. This is where the approximation comes into play.

 

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.


#5Deortuka

Posted 23 March 2013 - 11:39 AM

The second you get some data about a server side entity, you update your client side entity with that data. You don't check anything. The server has literally just told you where to place that entity.

 

Keep in mind that you do that when you receive network data. That might not necessarily be every frame on the client side. This is where the approximation comes into play.

 

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.


#4Deortuka

Posted 23 March 2013 - 11:38 AM

The second you get some data about a server side entity, you update your client side entity with that data. You don't check anything. The server has literally just told you where to place that entity.

 

Keep in mind that you do that when you receive network data. That might not necessarily be every frame on the client side. This is where the approximation comes into play.

 

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. 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.


#3Deortuka

Posted 23 March 2013 - 11:37 AM

The second you get some data about a server side entity, you update your client side entity with that data. You don't check anything. The server has literally just told you where to place that entity.

 

Keep in mind that you do that when you receive network data. That might not necessarily be every frame on the client side. This is where the approximation comes into play.

 

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

 

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

 

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. 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.


#2Deortuka

Posted 23 March 2013 - 11:18 AM

The second you get some data about a server side entity, you update your client side entity with that data. You don't check anything. The server has literally just told you where to place that entity.

 

Keep in mind that you do that when you receive network data. That might not necessarily be every frame on the client side. This is where the approximation comes into play.

 

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

 

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

 

In it's simplest form, the client is nothing but a picture viewer. The server describes the picture using network messages. The client reads these messages, updates all entities in the picture, then draws that picture to the screen. The only calculations done on the client should be visual related (ex. spark generation, particle physics, user interface updates, etc...).


PARTNERS