[Design question]Value synchronization vs killing it with packets

[Zethariel]

Hello,

 

This is not strictly a technical question, so I hope it's okay.

 

Currently I have a magic system that supports toggled spells, eg. ones that periodically substract mana. The way it works now is that each second I send out a packet to every player with their current mana value (authoritative server). This means that if someone activates a spell right before this mana synch happens, they'll be taxed for it, which should occur only after a second of the spell being active. Ideally, I'd like to have each spell have it's own recurring task (the system for that is already implemented in my solution), so that the player's mana is being changed at the correct times - that would mean sending potentially a lot of packets with many spells activated at different times.

 

It may be just in my head, but it doesn't seem to scale well. Sending ~5 floats per second per player just looks like traffic waste. One idea I had was to simulate the mana drain on the client and only send synchronization packets on spell cast or every  second or so. I'm not hot on it because the clash of synch vs local player values would make the mana bar flicker a lot between values, depending on latency.

 

Has anyone done something similar in the past and could spare some advice?

 

Thanks!

Edited April 29, 2017 by Zethariel

[V0idWa1k3r]

Why are you sending 5 floats per packet each tick/second? Only send things that have changed and send them as a single packet. Implement the 'dirty' trackers for your floats (simple booleans will do) and set them to true everytime a value changes. Then in your tick/second function grab every field that has it's dirty tracker set to true and pack it into a single packet. That way you are only syncing what needs to be synced. You could append a byte before each value to mark it's "id" so when you read your packet you know which fields you are recieving.

Another solution is to render your mana bar by interpolating values (current vs prev. tick) using the partialTicks. Vanilla does it everywhere. Literally. It makes flickering almost impossible to notice as everything is smooth, including that flickering.

Also 5 floats is only 20 bytes. 20 bytes/packet/player is nothing

[Zethariel]

1 hour ago, V0idWa1k3r said:

Why are you sending 5 floats per packet each tick/second? Only send things that have changed and send them as a single packet. Implement the 'dirty' trackers for your floats (simple booleans will do) and set them to true everytime a value changes. Then in your tick/second function grab every field that has it's dirty tracker set to true and pack it into a single packet. That way you are only syncing what needs to be synced. You could append a byte before each value to mark it's "id" so when you read your packet you know which fields you are recieving.

Another solution is to render your mana bar by interpolating values (current vs prev. tick) using the partialTicks. Vanilla does it everywhere. Literally. It makes flickering almost impossible to notice as everything is smooth, including that flickering.

Also 5 floats is only 20 bytes. 20 bytes/packet/player is nothing

 

I don't think we understood each other. It's one float per packet, and there can be many per second, hence my estimate of 5 per player (5 active toggle effects).

This is a dedicated packet that does what you say - only sends the value when it changes. 

The partialticks render won't do anything against latency in packet arrival - when the client thinks it has 90 mana, the server might in fact have 89, and there will be a flicker back to the original value. That is what I meant - discrepancy between client and server values due to latency