Few questions around "massively" multiplayer

[adjourn]

Hi, very impressive crate, my hat off to the hero who laid the foundation and of course to all the contributors!

Working on a passion project, I'm a systems guy so it's all about the systems, clients see only 3D cubes 🙃
I hesitate to call it an MMO since it then gets compared to the ones that cost 50 or 100M to make..
But there is some features overlap, at least with the classical ones:

• Few thousand players in a shared world (i.e per server)
• At least 100 players can be in one area and see each other without major issues

I'm not seeking to simulate physics, etc on server which limits most modern MMOs to few hundred players per shared world.

So I'm wondering if lightyear allows to employ the strategies mentioned below to make it possible or has alternative features of its own to reach these goals. I have two and half questions..

---

Thousands of players per server

To enable this, client needs to receive spawn/update/despawn events only in near area, for example in the radius of 50 meters.

My first prototype was done with renet and bevy_spatial (before I discovered lightyear) and it worked wonderfully. Each server tick, for each player, query kd-tree for all (replicated) entities in 50 meter radius, fill the buffer(s) with relevant data and send to client.

Any pointers how to combine kd-tree approach with relevance manager? Or would it not work well with this approach at all?
Rooms give me static vibes, so I've already written those off in my head. I'd be gladly wrong.

100+ players in one area

100 players, 100 x 100 = 10,000 updates, granted every player moves every frame which is not likely but aiming for worst case.

My idea was to have a distance based replication (simulation still runs every tick). For example entities in the range of 0-20 meters get replicated every tick, 20-30 every 2 ticks, etc. Interpolation would smooth out all tick rates. I think it would come down to using kd-tree again to strategically query based on radius (frees us from having to calculate and store any extra state around distances), very basic example:

• tick 1: query radius 20 (all entities in 0-20 meter range)
• tick 2: query radius 30 (0-20 every tick, 20-30 every 2nd tick)
• tick 3: query radius 20
• tick 4: query radius 60 (0-20 every tick, 20-30 every second tick, 30-60 every fourth tick)
• start again from tick 1

I was first going to ask if something like this would be possible to implement with lightyear but as I realised while writing this, easiest way to implement it would be to reuse kd-tree, so it's again a question of can I use kd-tree without having to hack or maintain a fork.

Server meshing

Planning to experiment with this soon. There are very complex parts I do not even dare to think about yet like seeing entities across the server boundaries but the first issue I'm trying to tackle is that if player crosses the server boundary, entity will be serialized and moved to another server (without loading screen) which then becomes responsible for that entity simulation and state.

Is that kind of connection management possible with lightyear?
I.e you start off connected to server 1, if you approach/cross the boundary then you'd likely need to be connected to both server 1 and server 2 at the same time and finally drop connection to server 1. Rust static nature and how almost all networking libraries define their connection configs in main outside the game loop (examples) has made me question dynamic abilities.

---

I'm just a noobie who just started playing around with this crate, if these are solved problems and I'm just trying to fit in unnecessary features that were required elsewhere, please do let me know. Thank you very much!

[cBournhonesque]

Hi!

I think none of these problems are currently solved, but I would love to have a big projects with many concurrent players to test lightyear in heavy conditions.

FYI I don't think lightyear is especially well optimized, so I doubt it would handle that many concurrent players.
There's this project: https://github.com/hyperion-mc/hyperion which uses rust to serve 10K concurrent players, it might be interesting to look at.

As for your questions:

• maybe using the immediate-api for visibility might be useful? https://github.com/cBournhonesque/lightyear/blob/main/lightyear/src/server/relevance/immediate.rs#L101

You would use the kd-tree to query for any entities at a given radius around a player, and mark all of them as visible

• I've tried to add some bandwidth management system: https://cbournhonesque.github.io/lightyear/book/concepts/advanced_replication/bandwidth_management.html
  Basically you can set the max bandwidth per player; once that limit is reached the server will send replication updates in order of priority. The priority is set per ReplicationGroup (group of entities replicated together). So entities with priority 2 will get double the amount of replication updates than entities with priority 1. You can combine this with the distance to send fewer replication updates to entities that are farther away from an entity.
  You can check out this example to see how it works: https://github.com/cBournhonesque/lightyear/blob/main/examples/priority/README.md

• server meshing: this isn't really available, but there are some building blocks available.
  One of the building blocks is that in lightyear you can transfer the authority over an entity to a different peer.
  Currently the authority can be transferred between the server and a client; but I could imagine a world where you could have multiple servers, and the entity gets transferred from one server to the other.
  This is the example I have for authority: https://github.com/cBournhonesque/lightyear/tree/main/examples/distributed_authority

[adjourn]

Thank you, this helps a lot!

[caniko]

MMOs are very intriguing indeed!

Can lightyear ever be optimized to the level of a game-specific framework like hyperion?