Sign in to follow this  

questions about some game networking concepts

This topic is 2047 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

Hey guys, this is my first post in this part of the forums. I use C++ and have been reading over Beej's guide to network programming, which I think won't be terribly difficult if I make a networking class and use it to wrap networking code into functions. I also read this article on Source engine networking: [url="https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking"]https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking[/url], which is the article I have questions about. It says that the client's timestamp should be synced to the server's, but how do you do that?

Should the client set it's timestamp to the server update packet's and count up based on client OS time until the next update packet and repeat? Can there be a significant difference between the time that has passed based on the OS clock between the previous update packet's arrival and the arrival of the one just received and the amount of time that has passed between the sending of those two packets based on a subtraction of the previous update packet's timestamp from the current update packet's timestamp?

For example, if the previous update packet's timestamp is 300 milliseconds, and 70 milliseconds of OS time passes until the new update packet is received, but the new timestamp is 350, meaning there is a 20 millisecond discrepancy between the time passed between the sending of the two packets and the time passed between the client receiving them, how should that be handled? The client's rendering time (the client's time minus the 100 millisecond lerp period) would be 270, but it would be suddenly be switched to 250 and jerk the objects being rendered 20 milliseconds into the past if the new update packet's timestamp is adopted. Not only that, but unless the 4 most recent snapshots are stored on the client (which seems illogical given the 100 millisecond lerp period and the approximate 20 per second frequency of update packets), there is a possibility that the client could now longer have packet data that far in the past. Are ping fluctuations like this usually mild/infrequent enough to allow this behavior, or should it be handled in some other way?

The Source Networking document said that to calculate when a client sent a command, the following equation is used: Command Execution Time = Current Server Time - Packet Latency - Lerp Period. I know it is somewhat elementary, but how would you go about calculating packet latency, and how frequently would you have to calculate it?

The article mentions that the server simulates the game in "ticks" every 15 milliseconds. So should the timestamp being synced be in ticks or milliseconds? Also, should the timestamp ever roll over? For example (assuming the timestamp is in milliseconds), if a game has been going on for 5 minutes, should the timestamp be 300,000 milliseconds, or should it rollover after a certain amount so the number of bits the variable being sent across the network requires can be lowered? Could doing the latter pose some kind of synchronization risk?

Interpolation, and extrapolation when there are packet drops, allow networked multiplayer games to run relatively smoothly using UDP despite occasional packet drops/misordering, but what about packets that can't be dropped such as when the server tells the clients that the level is about to change, or that the match is about to start, or chat messages? Should TCP be used for such packets, or should an acknowledgement system be layered over top of UDP for them (i.e., send the change level packet several times and wait for a response from the client confirming it received at least one)?

Can floats like player positions/angles sent to clients be compressed to save bandwidth? If so, to what degree can they be compressed without significantly affecting a client's perception of players and such? How can floats and other variable types like integers be compressed?

Movement commands are mentioned in the article, it says that they are made at the same tick rate as the server, but only 30 command packets get sent to the server a second, which means packets will often contain more than one command. I read that a command is simply a bit field that provides on and off states for several buttons, but how should the packet be constructed/handled if it contains more than one command? Should the server assume that the two commands were made a certain time a part, or is the time difference small enough to be ignored and just run the commands simultaneously on the server?

One last thing. Does a player's network bandwidth in k/bits refer to the amount of data that can come in a second from the server, that can be sent out per second, or some combination?

That's about all the questions I have (unless I forgot something), it ended up being quite mouthful. Thanks in advance for any help on these questions or tips for someone making their first networked game (or at least my first networked game that will use decent lag compensation and such).

Share this post


Link to post
Share on other sites
First, you typically timestamp events by the tick number that they happen. No need to use milliseconds, because events can only ever actually "happen" on ticks.

Second, yes, you can quantize floats -- the FAQ should have some information IIRC.

Third, you send messages to the server, where each message typically is timestamped with the tick it is intended for. Multiple messages can be put into a single network packet.

Fourth, if you just hear "I have 1500 kbps internet" then generally that means download speed, and the upload speed will usually be a lot less. Often, you'll see networking speed described as "12M/768k" where the first is download and the second is upload. Also, that's generally the speed of un-framed bits during best transmission conditions. Once you add protocol overhead and some allowance for network weather (and other usage of the same channel,) you'll see less throughput for a game.

Share this post


Link to post
Share on other sites

This topic is 2047 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this