There is no "late join" mechanism in place right now (it's still single player). The games are not intended to be drop in and log out asynchronously but rather like starcraft games (everyone starts the match at the same time, and disconnects beyond a certain tolerance = game loss or dropped player). Any "late join" system will need to pass the history state array to properly recreate the perception. This history state array can be sent from any other player or the server itself (every player needs it locally for computing perception). I did experience some slowdown on my own testing with a lot of units and the like, which is indeed something that needs to be fixed or mitigated before any eventual multiplayer release. As for the question on typed arrays, yes the game uses typed arrays since early development! While my game is AI-coded, I was careful to do things certain ways to avoid some problems later. That doesn't meant there's no room to improve though! Here is a more in-depth explanation (provided by my AI):
The ring is struct-of-arrays: one preallocated typed array per channel, indexed [slot * entityCapacity + id], where slot = tick mod capacity. Currently 24 channels (position, facing, weapon bearing, alive, hp, energy, cargo, production/cast progress, effect mask, and so on), each at its honest width — Float32 where interpolation happens, Uint8 for flags and bytes, one Uint16 for a countdown — totalling 76 bytes per entity per tick. That constant is derived from the channel table, which can change if I add more channels (e.g. new ability flags or dynamic values).
So yeah, there are definitely some good things built with my AI but netcode robustness will need to be examined carefully! For now though, I'm looking for feedback on the gameplay and controls. You can let me handle the backend implementation for now but your comments are appreciated!