Originally posted by tangerine
But won\'t this stall the whole movement in case of packet loss until this is detected and the packet resent ? Why resend when following more up-to-date update will come faster and obsoletes the lost one ?
Hmmm, well, it\'s a bit misleading what I said. In my game, there are movement packets and there are movement packets
The type of movement packets that are reliable and ordered don\'t stall movement, and in fact it is possible to get them out of order, they are just reordered by the client as they get there (by server timestamp value as well as a incremental key value).
The reason they are reliably sent is that I don\'t send actual positions (well, actually I do, but only once they are *known* positions by the server at some given time, so they are always out of date, but that\'s getting more complex than needed for this discussion
). I\'ve found sending absolute positions every x ms to be a less than satisfactory method (perhaps you guys found a way to do this, but I couldn\'t make it work with any decent results, heh). I instead send velocities and facings. Thus, every single velocity change *has* to get to the client, there is no superceding one data packet with another, as each builds on the previous. If one gets lost and data comes out of order, the clients use interpolation to \"guess\" on where the player is based on the data they do have until the actual missing packet(s) gets there.
I\'ve found this works really well. There is still a good deal of \"popping\" in my game for 3rd party avatars, but that\'s for an entirely different reason (which will be fixed in A6
).
Originally posted by Vengeance
That said, it is funny how your priorities are the opposite of ours. :-)
Hehe, yeah. It\'s odd how any given game\'s authors independently come up with many of the same solutions to some problems, yet entirely different solutions in other things.
The reason for this is that usually within a few msec the movement packet is obsolete and superceded by a new one.
Yeah, I\'d do it the same way if I was sending absolute positions every certain amount of time.
- ACKs are sent to keep the source computer from resending guaranteed packets. Non-guaranteed packets are not ACKed and never resent.
Ditto.
- All messages can be merged and sent as one packet.
I don\'t do this. I send each packet as a separate entity, even the really small ones. Yeah, I know there is some overhead with packet sending, but I found in my game the time spent trying to pull apart messages into individual packets just wasn\'t worth the effort
I was spending more time checking packet lengths and pulling out the individual packets than I was saving by sending them together. By sending them as individual messages, I can just read the first bytes to see what kind of packet was received, then rip the individual data members for that kind of packet and I can move immediately into processing.
That\'s just what I found though, YMMV.
