Sending packets regularly

[imadnsn]

There are a few properties I wanted to synchronize between my server and client by sending packets from server whenever the properties change. The issue was that those properties changed every tick, so I made them change only twice a second which is the best pace I found for what I'm doing.

 

My question is, what is the rate of sending packets per seconds generally that should worry me when implemented? Taking in account for other packets being sent by the mod or other mods regularly.

[larsgerrits]

Maybe you could make it when the client needs the propertie, the server sends a packet to the client with that propertie, instead of synchronizing the all the time.

[imadnsn]

That would be worse, because then I'd send two packets every few ticks when rendering Gui.

Also keeping it server-sided is better because I can use the data on different things update the data regularly instead of every time something needs it.

 

But that's not my problem anyway, all I want to know is how and when packet sending might make the game a bit laggy especially on multiplayer, so I can avoid overusing it whenever I can.

[TheGreyGhost]

Hi

 

It depends a lot on how big the packets are.  To give you some context, Vanilla queues up Chunk updates (which are quite large, up to 10k depending on compression) to send at no more than 5 per tick.

Over a LAN, you can easily send several MB per second with almost no delay and the system can easily keep up with it.  Over the internet it is much much slower, as little as 10k per second or less, and with variable arrival times of the packets by up to hundreds of milliseconds or more.

 

A much better solution is to code the client and server to run independently as much as possible.  The client predicts what is happening on the server and just adjusts it every now and again based on a synchronisation packet.  This works very well for moving objects, for example.  Depending on what your properties are, the client might be able to predict the updates very easily.

 

Another important thing to think about is whether you can tweak the game mechanics to make the rapid updates unnecessary.  Is the player really able to follow 20 property changes per second?  Could you add a delay or smoothing to the property change and make it a feature of your gameplay rather than a limitation?

 

-TGG

 

[imadnsn]

Thanks for your post, well you've got what I was thinking.

I actually deliberately didn't send all the info I will need on the same packet, only the ones that change regularly, I'm planning to make different packets that send whenever values change.

 

A player level won't change every 10 ticks, and it wouldn't make sense to send them with the health or hunger, for instance.