hastearcade / snowglobe Goto Github PK

You use Mock, MockNetwork everywhere, in fact everywhere
I would like to ask you to write an example using Colyseus or Socket.io or Geckos.io, it will help a lot of people

Do some surface-level performance profiling to get a sense for how many concurrent clients snowglobe can support in a medium-sized simulation.

• Can we remove the concept of Cloneable all-together by enforcing snapshots and commands be JSON-serializable?
• Can we eliminate any existing clones to reduce memory usage/GC events.

Getting the ActiveClient instance from a client is a little hairy and error-prone. You have to do stuff like:

if (client.state() === StageState.Ready) {
  client.stage().ready!...
}

Where we have to manually assert the presence of the ready property. We could take advantage of a union type/type narrowing to make this more intuitive and "safer".

Furthermore, getting deeply nested properties off of ActiveClient and company can be really nasty, e.g.

mockClientServer.client1.stage().ready!.timekeepingSimulations.stepper
          .lastReceivedSnapshotTimestamp!

By the looks of it, we didn't port over a few methods that would make this a bit cleaner, like this one from ready.rs:

    pub fn last_received_snapshot_timestamp(&self) -> &Option<Timestamp> {
        &self
            .0
            .borrow()
            .timekeeping_simulations
            .last_received_snapshot_timestamp
    }

The equivalent in snowglobe would let us rewrite the above TypeScript snippet as:

mockClientServer.client1.stage().ready!.lastReceivedSnapshotTimestamp()

I made a impulse decision to make Timestamped entities not "wrapped" like in CrystalOrb. Instead, snowglobe mutates the original object by adding a property with a Symbol key ($timestamp`). At the time, this seemed like it'd be more memory-efficient but may not be ideal.

This function originally tanked performance when we were still using objects for timestamps. I think it's still pretty slow. We should take a look at how it's used to see if we can replace it with a simple comparison, or consider memoizing the result to prevent excess memory allocations and CPU usage.

Do a pass over our modules to ensure we're using access modifiers where necessary, using member initialization patterns consistently, naming variables consistently, etc.

CrystalOrb is able to generate unique type identifiers for network messages (clock-sync events, snapshots, commands) using some kind of reflection/metaprogramming feature that we don't have in TypeScript. I quickly decided to categorize message types using integer ids using a function called makeTypeId.

• We should make sure this is the right way to go about categorizing message, and if so
• We should expose these type ids to consumers, maybe as an enum.