<div>I certainly want the fancy approach!</div>
<div> </div>
<div>I'm halfway there, now. Well.. halfway getting the user inputs onto the server.</div>
<div>Getting the gamestate back to the clients can wait.</div>
<div> </div>
<div>I read your link above, and I'm going with the final option.</div>
<div>There are just a few things I'm not sure about. Possible optimisations, etc.</div>
<div> </div>
<div>How exactly does the delta compression work? Because at the moment my </div>
<div>average message is 5/6bytes - not a few bits. I'm just sending 1 bit for each </div>
<div>boolean value (~12), 24 bits for the mouse position (12 for x, 12 for y), and very rarely</div>
<div>I'll add on an additional 8bits to show what weapon was selected, etc..</div>
<div>If you're sending a change, then don't you have to allocate space to say what changed?</div>
<div>As opposed to just sending the state of each bool, where you can predetermine what bit</div>
<div>corresponds to what boolean value.</div>
<div> </div>
<div>Also, how many bits do you allocate to the packetID counter? Surely just the value of the</div>
<div>counter alone is going to be a lot. You'd want to make it big, wouldn't you? So you could leave</div>
<div>the game running all night without it going weird. Unless there's some way to loop it back to 0 safely.</div>
<div> </div>
<div>I was wondering if I even needed to include my own counter.. Afterall, Enet </div>
<div>uses counters to sequence packets anyway, doesn't it? Would it be possible to just use</div>
<div>them instead? Saving a bit of bandwidth. If so, how would I access it?</div>
<div> </div>
<div>Good article though. Very helpful :)</div>
<div> </div>
<div>Ben</div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div>"For things like reloading, shooting, etc. the dead simplest thing to do<br>is just send them reliably on a second stream, keep movement and such on<br>an unreliable stream just sending over positions. Reliable stuff needs<br>
to be tagged with its own positions where necessary, since it is not<br>synchronized with the movement.</div>
<p>But if you want a fancier approach that is less prone to cheating, you<br>need to keep an event history that synchronizes all movement, shooting,<br>etc. into one history log, send it over as unreliable at a fixed rate,<br>
up to the last verified position the other end ACK'd. So stuff just<br>keeps getting resent over and over as quickly as possible until server<br>says it got it. This can have an advantage over using reliable data<br>
since there are no possible time-out stalls. Check the above link for<br>more details.</p>
<p>Lee"</p>