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

[Lee Salzman]

Check this long-winded, rambling post I made about FPS movement here: 
http://lists.cubik.org/pipermail/enet-discuss/2008-March/000820.html

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

Ben Johnson wrote:
>
> 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 mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>