Compress state before hydration

[littensy]

When a player joins, a brief but noticeable lag spike can be observed. This is likely caused by the hydration remote sending a lot of data at once, and all other remote calls are queued until this one finishes.

This can be optimized by sending data over a longer period of time, i.e. sending candy a second after sending the initial data.

The payload can benefit a lot from compression, too! The data is JSON-safe and has a lot of repeated strings that can do well with most compression modules.

[littensy]

Data, namely Vector2 values, will need to be serialized before encoding them to JSON for compression. To do this, we should save it as an array of the coordinates, and store the datatype in the key like so: Vector2_key: [x, y] @NeoInversion

This way, we can avoid malicious user input that affects the serialization process, while keeping the code simple.

[littensy]

The best module for this may be https://gist.github.com/metatablecat/92345df2fd6d450da288c28272555faf

[littensy]

The current compression options are too slow to be effective at solving the issue. As an alternative, we will manually compress and serialize candy and snake objects. Certain datatypes may also be passed through BitBuffer if something can be gained.

[littensy]

The focus of this issue will be shifted towards cleverly compressing candy and snake entities using BitBuffer. I expect it to save at least 100KB, considering that property names will no longer be needed. If the solution is inefficient, this will be marked as wontfix and closed for the time being.