Been tinkering with this for a while. Its an abstraction to have the main gameloop up and running on the client & server and basic entity synchronization between the two.
The important part here: The threejs scene runs on both the server (headless) and the client (with rendering of course). So the scene can be traversed / queried on the server too for hit detection or anything you need.
Interesting architecture. Running the same Three.js scene on both client and server is a strong approach for multiplayer because it keeps the world state deterministic and makes things like hit detection, spatial queries, and entity validation much easier on the server side.
Using a headless scene on the server also opens up possibilities for things like authoritative physics, AI simulation, or server side world logic while the client focuses purely on rendering and input.
The entity synchronization layer is probably the most important part in setups like this. If it’s structured well it can scale nicely for multiplayer interactions, prediction systems, and partial scene updates rather than syncing full objects.
I’ve been experimenting with similar browser based environments and world systems built on Three.js where large scenes, entities, and interactions are streamed dynamically.
Curious how you’re currently handling things like entity ownership, prediction, and reconciliation between client and server. That part usually becomes the interesting challenge once multiple players interact with the same scene.
