[ENet-discuss] Running, Jumping, Shooting, Reloading.. reliable or not?

[Ben Johnson]

Hi all,

I've gotten the hang of Enet now, and for the first time I got it running on
two different computers. It was very exciting to see my guy move around from
one computer to the other. Although at the moment it's very basic movement.
I've also written up a nice Networker class which will compress stuff into a
bit-stream, and send it off.

Thus, bools only take up 1 bit, ints take anywhere from 2 bits to 32 bits,
depending on the allocated range, and I can send over strings as well.

Anyway, I'm deciding now what model I should use. My game is definately fast
paced. It's top down 2D like GTA2, and people run around with guns and
stuff. They can also select missions, buy weapons, use skills, etc. Btw, I'd
like this game to be able to support a lot of players.

I've heard of all sorts of techniques, delta compression, interpolation,
dead reckoning, etc.. and I'm not sure what type I want to use. I guess
there's a lot to figure out, but for now my question is regarding reliable
vs non-reliable packets.

I'm wondering what data values should be sent reliably, and which ones
unreliably. I'm particularly interested in sending user inputs. For example,
it makes sense to me that since the player will often be holding down the
WASD keys, they should be sent unreliably. Afterall, if a packet gets lost,
a new packet will come in 50ms later and set the movingUp value to true.

But what about reloading? When a player reloades, they just tap the 'r' key,
and that's it. If THAT packet gets lost.. then their player on the server
won't have reloaded. And because I'm going to want my game to feel
responsive, the client will see their gun start reloading, even though it's
actually not.

Also, how about firing the gun? You might hold down the mouse button with a
machine gun, but you'll be tapping it when sniping, etc. I read that unreal
article from the FAQ, and it was very informative. But I noticed that it
only sends off data at the end of each tick. Won't this create a lagged
effect? Should I perhaps send off user inputs as soon as they're changed..
and only use a tick system when sending back the game state?

Finally, Enet has channels, which operate independantly of eachother. My
understanding is that all packets sent within the same channel are
sequenced, meaning reliable packets wait till they've all arrived and are in
order, and unreliable packets will automatically be dropped if a later
packet has already arrived. Due to this waiting around for reliable packets,
would it be a good idea to send all my unreliable data through one channel,
and send all the reliable data through the other one? So the unreliable data
isn't held back by the reliable data?

Just a few things I'm not too sure about.

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