system: decouple level from client, introduce instance, level syncing

[f8122dac91]

To tackle #6 and eventually #14, we need to come up with a level syncing mechanism.

For now we can just use godot's native resource format (.tres for text .res for binary) as a testbed.

---

This issue should implement:

• [x] RequestLevel (client -> server) and LevelData (server -> client) message in protocol
• [x] PlayerInstance (client -> server) and PlayerInstanceAcknowledge (server -> client) message in protocol
• [x] each instances to sync individually
• [x] server to serve binary serialized level data: LevelService to serve levels
• [x] client to deserialize retrieved level data into PackedScene
• [x] client to load and instantiate level in LevelDataManager singleton
• client to represent the state of being uninitialized (no level, no player), level loaded (level, no player), and initialized (level, player)
  • [x] for now we can just have a simple loader scene that delays the instantiation of the main scene to prevent erroneous states of the singleton objects (which get things stuck in _ready())

[f8122dac91]

Had to work around the lack of serialization/deserialization mechanism for PackedScene by using PackedScene._bundled: Dictionary.

Serialization: use var_to_bytes_with_objects() with PackedScene._bundled dictionary

Deserialization: initialize an empty PackedScene instance and assign the result of bytes_to_var_with_objects() to its _bundled property.

[f8122dac91]

https://github.com/igneous-labs/telegram-space/pull/22#issuecomment-1422349273

details for the implementation

[f8122dac91]

Realized that world has to have the concept of (world) instance in order for multiple levels to exists. Currently, neither player state nor world state have any information about which level a player is in.

We can introduce Instance that identifies an instance of world and has associated level (identified by level_id) and add instance_id to player state data.

Conceptually, Instance is just a shallow association from a group of players to a level, and with this we can logically separate level (data, i.e. blueprint of world) and world (an instance).

[f8122dac91]

We can introduce Instance that identifies an instance of world and has associated level (identified by level_id) and add instance_id to player state data.

Ended up implementing it with a different approach (in 2fdcb747ba815e940812f53ec686734408f7a80c):

• each instance state is essentially just a HashMap<ClientId, PlayerStateData>
• on top of that, each Instance keeps some metadata (last_updated_at and last_synced_at) to facilitate syncing behavior
• WorldState is the collection of all Instances
• WorldState has client_instance: HashMap<ClientId, InstanceId> used to resolve a given client_id to current instance_id
• PlayerStateData is left alone and does not contain information about instance

The reasoning behind the implementation is that partitioning the whole world_state into each instance has to be performed every single time the server needs to sync instances, and this is way too expensive to perform at sync time which is close to the frame rate.