Pointers for Multiplayer

Skelerealms is not designed for multiplayer. However, this does not mean it is not capable of such a feat.

I did not design it for multiplayer because, apart from knowing the basic theory and some noodling around in python when I was 14, I have never made a multiplayer game before. I did not believe I could provide a satisfactory multiplayer backend - especially due to how ad-hoc network code tends to be.

This does not mean I gave it no mind, however. Bethesda's Creation Engine (largely the model for Skelerealms), through decades of cruft, became so dependent on the player character existing that the player was nicknamed "Atlas" for how it held up the world. This was fine for the single-player RPGs Bethesda is known for, but became a nigh-insurmountable problem when they decided to make Fallout 76. The refactoring to allow for multiplayer was a miserable experience, and we all know how it turned out in the end. Skelerealms avoids this issue- indeed, the player does not even need to exist for the game to function- not that it would be much fun. As of writing this, none of the unit tests used to test the core game systems actually include a player character.

However, Skelerealms does take a few shortcuts within the code going off the assumption that there is only one player in the game. Off the top of my head, these are:

1. The logic to calculate how far away from the player is from a given entity, used for rendering and for determining simulation granularity, is based off of the main camera's position, assuming that the camera's position is the player's eyes; because of this, there must always be a Camera3D present in the scene tree. A more appropriate way to do this in a multiplayer setting is to instead do something like sim_distance = min(get_players_online.map(func(player:Entity): return position.distance_to(player.position))). This code can be found mostly in the Entity and NPCComponent class.
2. When checking if an entity is a player, much of the built-in code simply checks if the entity's RefID is "Player". A more proper approach would be to check if the entity has a PlayerComponent.
3. The in-scene calculation refers to GameInfo.world assuming that that world is the only one loaded. This would require some work to shift around. You may have to do in-scene calculations on the client-side to work with this, with the GameInfo.world referring to the client's world.

Despite my limited foresight, restructuring Skelerealms would undoubtedly be no easy feat. If you wish to go on this endeavor, I wish you the best of luck, as I will be of very little use to you.