The part I can’t make work is the math if you work out what the theoretical data sizes should be for 250 moving/rotating entities.
60 (frames) * 250 (entities) * (8 + 64 + 16 * 3 + 12 * 4 + 5)
= 2595000 bits per second… or 324375 bytes per second.
I can’t make that match with your numbers. There’s some per frame overhead but it can’t account for the difference.
Frame overhead: 208 bits per frame… * 60 = 12480 bits/frame or 1560 bytes.
Even considering that you are viewing raw network traffic and must account for the UDP header size and so on… it seems the differences are too much. But maybe I’m not looking at it right.
By the way, 64 bits for your network ID size is WAAAAAAAY too big. This is not the size of your entity IDs. It’s the size of the network objects IDs and they are reused (round robin) and mapped to your entity IDs dynamically. Really 16 bits should have been fine unless you expect to have more than 65,000 active networked entities at the same time. If you could bring that back down to 16 bits then you save 6 bytes per message.
Edit: some other message overhead I forgot about are the acks… but in this case where you aren’t losing packets then that should be pretty small. Though it could be that since your messages will be split that this increases a bit I guess.
If you get really adventurous you could add some logging to the StateWriter to count what is actually being sent. I think you can count it just in endMessage().