[ENet-discuss] Optimising the packets

[Ben Johnson]

I certainly want the fancy approach!

I'm halfway there, now. Well.. halfway getting the user inputs onto the
server.
Getting the gamestate back to the clients can wait.

I read your link above, and I'm going with the final option.
There are just a few things I'm not sure about. Possible optimisations, etc.

How exactly does the delta compression work? Because at the moment my
average message is 5/6bytes - not a few bits. I'm just sending 1 bit for
each
boolean value (~12), 24 bits for the mouse position (12 for x, 12 for y),
and very rarely
I'll add on an additional 8bits to show what weapon was selected, etc..
If you're sending a change, then don't you have to allocate space to say
what changed?
As opposed to just sending the state of each bool, where you can
predetermine what bit
corresponds to what boolean value.

Also, how many bits do you allocate to the packetID counter? Surely just the
value of the
counter alone is going to be a lot. You'd want to make it big, wouldn't you?
So you could leave
the game running all night without it going weird. Unless there's some way
to loop it back to 0 safely.

I was wondering if I even needed to include my own counter.. Afterall, Enet
uses counters to sequence packets anyway, doesn't it? Would it be possible
to just use
them instead? Saving a bit of bandwidth. If so, how would I access it?

Good article though. Very helpful :)

Ben





"For things like reloading, shooting, etc. the dead simplest thing to do
is just send them reliably on a second stream, keep movement and such on
an unreliable stream just sending over positions. Reliable stuff needs
to be tagged with its own positions where necessary, since it is not
synchronized with the movement.

But if you want a fancier approach that is less prone to cheating, you
need to keep an event history that synchronizes all movement, shooting,
etc. into one history log, send it over as unreliable at a fixed rate,
up to the last verified position the other end ACK'd.  So stuff just
keeps getting resent over and over as quickly as possible until server
says it got it.  This can have an advantage over using reliable data
since  there are no possible time-out stalls. Check the above link for
more details.

Lee"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20080605/f6d0d4a8/attachment.htm>