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

[Martin Sherburn]

Lee,

Thanks for your explanations, I read your original "long-winded post" 
when you first posted it. I only just got round to implementing your 
"Co-simulation" idea very recently. And so far it works a treat. I just 
have one more aspect I'm not quite sure how to handle very well which I 
don't think you explained:

The server buffers the client's inputs so that when some packets get 
lost or take a little longer to arrive the server doesn't run out of 
input and doesn't have to assign a credit to the player which would lead 
to jerky looking movement. But buffering too much introduces artificial 
lag. So the question is, how much should be buffered? I'm thinking about 
50ms sounds like a good value. But more importantly, how to ensure that 
on average the buffer stores 50ms worth of input? I can imagine that if 
two computers have slightly differing clock speeds things would get 
messed up over long periods of time. Is it not necessary at some point 
to trim the buffer length or extend the buffer a little to ensure the 
desired average buffer length is kept (especially at the start when the 
player entity is actually created)?

I remember Half-Life was vulnerable to speed hacks. Somebody had written 
a program to modify the clock speed on the client computer and this 
would actually allow the player to run at extremely fast speeds, or run 
in slow motion (but this wasn't much use for the cheaters :)). Since the 
netcode in HL seems quite similar to what you described, it seems they 
just process all the client input as it comes with some kind of 
smoothing I guess. Any thoughts on this?

Martin.

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