Skip to content

Exchange protocol too verbose for real world use #10

Open
@jgamedev

Description

@jgamedev

For production deployment it's paramount that data exchange between the client and the server is kept to a minimum.
Currently there seems to be zero optimization on this area. For reference here's an example of an exchange payload with only 1 user inside the game room:

"onServerUpdate",{"serverTime":30.091000000001493,"ownPlayer":{"id":"a8061581-7929-4b37-9477-c472e8959634","name":"jay","lastInputSeq":"121","position":{"x":156.355,"y":119.995},"fireing":false,"reloading":false},"players":[],"events":[]}] as {"type":2,"nsp":"/","data":["onServerUpdate",{"serverTime":30.091000000001493,"ownPlayer":{"id":"a8061581-7929-4b37-9477-c472e8959634","name":"jay","lastInputSeq":"121","position":{"x":156.355,"y":119.995},"fireing":false,"reloading":false},"players":[],"events":[]}]}

Here's a few ways in which I believe this could be optimized:

  1. Rounding-off time to a meaningful precision: this is the most obvious one. For instance: ' ' 30.091000000001493 could be sent as 30.091 or (maybe 30.02?) and specially the rounding off of positions could be a benefit in a scenario where there are +20 players in the same room.

  2. Client UIDs should not be included on frequent exchanges: UIDs should be only be included in meaningful, one-time-off events such as joining rooms, etc. After that a much shorter id can be used that can be mapped to the actual client UID whenever that is needed

  3. Avoid sending 'state of the world' types of updates inside of frequent exchanges: instead only "diffs" should be send.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions