Jump to content
  • Advertisement
Sign in to follow this  
Garra

Sending game data with winsock

This topic is 2773 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm creating a client/server winsock FPS arena type game and have been debating on the most efficient way to send all of the data to and from the client. There is a lot of information that needs to be kept up with such as player positions, rather or not someone is alive, etc. Should i just put everything in a large structure and send it? Is there a better way? Any advice would be appreciated. In the past I have sent the data inside of a structure, but this game requires me to send a lot more information at a time. I just want to do my best to send it as efficient as I can to prevent lag.

Share this post


Link to post
Share on other sites
Advertisement

I'm creating a client/server winsock FPS arena type game and have been debating on the most efficient way to send all of the data to and from the client. There is a lot of information that needs to be kept up with such as player positions, rather or not someone is alive, etc. Should i just put everything in a large structure and send it? Is there a better way? Any advice would be appreciated. In the past I have sent the data inside of a structure, but this game requires me to send a lot more information at a time. I just want to do my best to send it as efficient as I can to prevent lag.


The FAQ talks a lot about this. You can play with how often you send the data, as well as how you encode the data -- for example, you can encode a float in the range -1000 ... 1000 with a precision of 1/64 as a short (half size) divided by 64. You can also send data at a slow rate -- say, 10 times a second -- and forward extrapolate (or delay) display of entities.
Another approach is to send only input -- direction and movement keys -- and simulate forward; send a "baseline" snapshot once every five seconds or so to "fix" if something goes out of sync.

Share this post


Link to post
Share on other sites
so does that mean sending the structure is still the way to go? I can separate some of the data cause not everything needs to be sent as fast as other data. I read up into the FAQ, it said to look up how they do things in quake/tribes etc. I'll do some research on how the packets are sent in those games as well.

Share this post


Link to post
Share on other sites
could someone explain the concept of delta compression? From what I understand by doing some research on quake3's network architecture it's basically the difference between two different packets. So one packet is sent normally, and then the next time the differences in the two packets are sent? I'm not sure if I have the general idea or I'm way off. In the quake 3 source they implement delta compression to a large structure that has to be sent back and forth from the client and server. The structure basically holds a vector for the player pos and integers that define the weapon the player has etc. This is basically what I'm trying to accomplish I just don't have the full grasp on it yet.

Share this post


Link to post
Share on other sites

could someone explain the concept of delta compression? From what I understand by doing some research on quake3's network architecture it's basically the difference between two different packets. So one packet is sent normally, and then the next time the differences in the two packets are sent? I'm not sure if I have the general idea or I'm way off. In the quake 3 source they implement delta compression to a large structure that has to be sent back and forth from the client and server. The structure basically holds a vector for the player pos and integers that define the weapon the player has etc. This is basically what I'm trying to accomplish I just don't have the full grasp on it yet.


It's more complex than that.

First, split the state you want to send into different pieces: position, movement, orientation, weapon state, hit points, ...

Second, number each packet you send, and send back an acknowledgement for the latest packet number you've received.

Third, keep the last N packets around after you send them. N should cover your expected range of latency -- 1 to 2 seconds, say.

Fourth, when you update state, you compare the state you want to send with the state you sent in the latest acknowledged packet. Send only the state that is different between what you want to send, and what was in that packet. Send a reference to that packet, and a bit mask of what pieces of state you will include in the new packet, plus that state.

Now, on the receiving side, it knows how to generate the state that you sent -- look back to the state in the packet it references, copy that, then overlay whatever the other state is that's included in the new packet. Send back an acknowledgement that you received this new packet.

Whenever you get a new packet referencing a "later" packet than what you've previously used, you know you can discard any saved state for earlier packets, because those will no longer be used, as the other end now has a later copy to work off of.

Share this post


Link to post
Share on other sites
Thank you for explaining all of this, I'm slowly catching on with your help and studying quake3. Another thing i don't quite understand is the concept on how states work in regards to networking, and what you mean by splitting the state into pieces.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!