Sign in to follow this  

Does this sound reasonable for a packet entry size?

This topic is 1988 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 everyone! I'm now using construct (a form of the struct library) for python so that I have better packing control over my packets.
It looks like its going to be a lot smaller overall, but I just wanted to ask a few things:

Assuming that I'm using standard floats, each is 4 bytes. Therefore, an X,Y,Z coordinate would be 12 bytes. Adding on rotation, as two floats again at 4 bytes each, that's 20 bytes. Then, adding any state data like shooting, etc which can be used as flags (in a bitmask) I would add another byte. Add one more byte for an 8 bit integer representing delta tick (from packet tick) and another to represent the packet 'type'
Thus, looking at 27 bytes per player, after adding the 4 bytes for a 32 bit integer representing the current sending game tick,
Then, If one were to have 10 players, that's 270 bytes. Is that a lot / little in terms of network throughput?

Share this post


Link to post
Share on other sites
270 bytes is tiny - but that also depends on how [i]often[/i] you send those 270 bytes. It's much more useful to think of throughput in terms of rate (since that's what it is) rather than just a pure volume number.


Assuming 30 ticks per second at 270 bytes per tick, you're talking about a tiny fraction more than 8KB per second. That's almost compact enough to run on a 56K modem, for reference.

Share this post


Link to post
Share on other sites
[quote name='ApochPiQ' timestamp='1341525499' post='4956120']
270 bytes is tiny - but that also depends on how [i]often[/i] you send those 270 bytes. It's much more useful to think of throughput in terms of rate (since that's what it is) rather than just a pure volume number.


Assuming 30 ticks per second at 270 bytes per tick, you're talking about a tiny fraction more than 8KB per second. That's almost compact enough to run on a 56K modem, for reference.
[/quote]

Thanks ApochPiQ.
I find that a lot of my problems aren't so much the implementation, but the actual history and mechanics behind multiplayer itself.
+1 for help :)

Share this post


Link to post
Share on other sites
That sounds like it could work.

Things to consider:

If you're running a server, you have to send data about all 10 players (or at least 9 of them) TO 10 players, so server bandwidth grows by n-squared. Thus, at 20 Hz net rate, you have to send 27 bytes times 10 players times 10 players time 20 packets per second, which would be about 54 kilobytes per second, or about half a megabit.

Position may be sendable using smaller data types. If your entire level is 1km across in each direction, quantizing position to a 16-bit integer still gives you 1/64th of a meter of resolution (about half an inch.) Heading (what you call "rotation") can similarly be quantized to two 16-bit values with very little loss of resolution. On the other hand, you probably want to add velocity as a three-vector to the update packet, which wasn't in the initially described packet.

"ticks" can be the lowest X bits of the master clock, and each recipient can use the local clock estimate to inflate it. If the value is more than 127 ticks ahead of estimated master, assume it's behind master. Or you can send a single tick value up front, and then send delta to that tick value as a single byte for each user.

If you worry about bit packing, you can pack multiple values into single bytes. For heading and attitude, you can pack two 12-bit values into 3 bytes. If X and Y are a kilometer in size, but Z is only 20 meters from low to high, you can borrow a few bits from the Z to give better resolution to the X and Y. There are lots of such tricks you will want to pull once you start worrying about what happens when you want to serve 32 players on a 1.5 megabit connection :-)

Share this post


Link to post
Share on other sites
If you want to know more about bit packing outside of just flags you can view the code in my [url="http://sirisian.com/blog/binary-packet/"]article[/url] on the subject. Designing a binary writer/reader can abstract away a lot of the complexity as you write networking packets. Hplus hinted at this. Basically if you need to send data it's often good to look at the resolution of the data. The article goes into this in terms of things like updating minimap data. The code includes helper functions for things like WriteCustomResolutionSingle(value, min, max, bits) which automatically calculates an encoding based on the properties of the value you're encoding. Tons of strategies along those lines.

Share this post


Link to post
Share on other sites
You can further cut rotations down to a single byte by mapping 0 to 255 to 0 to 360. Rotating from 1 to 2 degrees is so small that you don't need anything really less than that for precision.

Share this post


Link to post
Share on other sites

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