Bought TNet

[hippocoder]

Hiya,

I have bought TNet (email as my username) via paypal. I'd love it if I could get a small amount of support:

[Background Info]
Our test game has 8 players and currently TNet works like a charm except there's a problem with one of the clients. The client's netbook will often not send udp or tcp packets for up to a second due to it's power saving. So it will send regular packets for a while, then pause... then resume again.

This is something we can expect clients to do from time to time in worst cases. My game is an action oriented 2D game and for the most part it works perfectly with TNet.

The problem
The client is sending at a rate of 20 packets a second, and if there's a substantial delay between packet update time for position, the client appears to teleport quite some distance.

I already simulate all clients on all machines so if there's a lack of a packet it fills in the gaps nicely, and does not move through solid walls, however my problem is when the client does teleport to the clients proper location it looks terrible on the other machines.

How to solve this? I mean does the master client or host, have to send correctional packets back to the misbehaving client? To clarify this is not when packets are sent regularly, but when there's a long delay before the arrival of the next, which happens randomly.

The same client playing quake 3 doesn't appear to notice the server correcting him. I am looking for advice in this situation

[ArenMook]

I would teleport the player if he was too far, but I'd also probably disconnect him. It's a tricky question and highly depends on the game itself.

Btw, the client can "halt" packets for a while if you happen to flood the network card with various packets. Even 20 updates per second is too much. I recommend sending ~5 updates per second, and simply interpolating between them. I usually have the renderer smoothly follow after a collider. You can see this done in the examples that come with TNet as well.

[hippocoder]

Thank you for the advice. I had no idea 20 was too much because I read that quake 3 and counterstrike send 20 packets a second (or perhaps I'm just tired - it's possible). I tried 10 and it's the same issue. The issue seems disguised though.

If it's 5 times a second, will this still be enough for instance, the player jumps, or shoots? or should I just send a separate packet for "actions" such as jumping and shooting?

Thanks for advice. I think your framework is put together in a nice way. I enjoy using it. I think perhaps 20 times a second might be ok for those games which use some form of delta encoding with Huffman coding for compression. I guess these packets they send are considerably less congestive than mine.

[ArenMook]

Implementations offer brute-force the packets, sending them frequently as opposed to doing predictive interpolation. It's pretty much excuse for poor coding. I'd send things as infrequently as possible. Jump packet should be sent immediately though -- along with the updated position. Basically every time you perform an important position-related action, send the position as well. And possibly rotation. Aside from that, sync infrequently.

[hippocoder]

Thanks!

I'm thinking of this:

infrequent: position and velocity

instant: delta input (changes in input - which includes the jump button) - hows that sound? So player holding jump wouldn't send any packets but tapping jump would send a byte for the jump. Or holding left wouldn't send any packets but pressing right or not moving would send another.

[ArenMook]

It's often easier to send the effect of the user interaction. For example, pressing forward changes the vehicle's vertical axis. Sync this value while it's changing. Synchronizing delta can cause floating precision issues, and also is unlikely to save you much bandwidth.

In the multi-purpose game starter kit I sync the axes when they change, and I sync the position and rotation ~4 times per second -- but this can easily be dropped down to once per second.

I also sync the position and rotation when something major occurs -- such as a collision, or an explosion.