Hello Unity Team,
The default serialization logic currently resend the entire buffer when the element count changes, as it’s challenging to determine precisely what has changed. However, in our scenario, we utilize a custom IElementDataHashMapBuffer where everything is stored as key-value pairs.
What are the available approaches for developing a customized serialization logic for our specific IElementDataBuffer?
Thanks !
Not many that are easy to do.
Buffer serialisation logic is largely opinionated at the moment, and somewhat all code-generated, and this is where we are actually encoding how the buffer need to be serialized/deserialized.
Because in general we couldn’t know the content of the buffer and if the size is changed, we don’t do any delta compression.
To change that logic it is required to make changes in the template and some places in the package too (ghost receive system in paricular).
While plenty doable, it is not definitively the easiest thing to change.
We are planning to add more options for that and to let specify that behaviour a little bit more (i.e: element are still delta compressed) but in order to customise many of the serialisation aspect we need to refactor the seriallzatoin support to let user customise the behaviour as they want.
I prefer to stick to no custom serialization until an official way to do this is released.
Thanks !
Hey @CMarastoni
Anything new about this ?
Still on our radar but we need more reasoning about what it is the part that need to be customized.
In that sense, @Opeth001, let supposing it is possible to customize the behaviour.
How do you would like to serialize the key-value pairs of the hashmap ?
Hey @CMarastoni
I would compare the old and current key-value pairs and send specific commands, such as removing key X or setting key Y to a new value. This approach ensures that the full buffer is never sent, even if the number of elements changes.
Ok. So zero assumptions on the element order? in your case kind make sense, with the only caveats that in the “general” sense, the comparison can become O(N^2) if the element in the buffer don’t maintain the same order.
But in general should be still O(N) by searching appropriately.
So, in your custom serialization you would like to delta compress by:
That would mean you would like to customize:
I’ve been meaning to look into this as I really need full buffer custom serialisation, not per element. I have some binary data in a buffer which i know how to compress to
50% of it original size.
Atm I have to create a second buffer, memcpy to it, and use that as the ghost component then reconstruct on client. I’d really like too avoid having to duplicate my buffers.
Yeah! Understood. I’m trying to understand the use cases to see what to expose and how to be customizeble.