Jump to content
Posted 23 May 2014 - 09:05 PM
Posted 24 May 2014 - 02:07 AM
They would most certainly be combined into a single update packet. The way you do that is by putting all the entities, and their properties, in a list inside the packet. This includes any other properties an entity may need to convey an update about. You would have a byte telling the recipient how many entities are listed, and at the beginning of each entity have a byte that describes what entity properties are described. Then you can easily sift through each incoming packet to pull out the data that needs to be applied to entities locally.
Posted 24 May 2014 - 10:46 AM
Posted 24 May 2014 - 11:46 AM
You would include other things just the same way, so the first part of your packet is something like (for example) 3 bytes, one byte for how many entities are in the packet, one for how many events are in the packet, and one for effects.
Then the first byte of each entity (after an entity ID) is which properties of that entity follow.
After all the entities, and their info are in the packet, you move on to listing the events, then effects and their properties.
Posted 24 May 2014 - 01:08 PM
There are many different ways of handling your packets. I tend to define a header as the size of the packet contents, then its protocol. That is it. This helps avoid errors within a single packet from causing off-by-n errors elsewhere. So an entity update packet might involve sending the number of repeated entities, then packing their data, and appending the header to that packet.
Edited by Angus Hollands, 24 May 2014 - 01:08 PM.
Posted 24 May 2014 - 04:55 PM
Posted 24 May 2014 - 05:35 PM
How about the "some packets to player A, some to player B" issue? How is that dealt with?
Posted 25 May 2014 - 12:26 PM