Server architecture
The typical approach in a centralized single-world MMO, like EVE Online or Elite Dangerous, is to assign users to servers based on their location in in-world space.
This has several problems, some of which are specific to a decentralized game:
Handover of players between servers in a continuous space is extraordinarily tricky. Elite is glitchy to this day, and EVE works around this by having discrete solar systems players must jump between.
Resource shortages can still be caused by players crowding onto one server (e.g. Jita in EVE)
In a decentralized world, the "owner" of an area of space, who operates the infrastructure for it, has disproportionate power. This can be abused in ways that do not detectably break the rules of the game, and thus cannot be punished by any sort of governance mechanism. For example, the server can reveal the positions of players to their enemies, who can then track them down with a plausible cover story.
Instead, we use a org-based, non-local sharding system. Some key features:
Player orgs run servers for their own entities (players, assets, code, etc). The org server simulates game logic for all their players, as well as handling other intra-org logic such as communication, governance, software updates, etc.
Player-orgserver uses a server-authoritative client-server architecture, similar to Eve Online. A player cannot cheat without a complicit orgserver.
Orgservers connect to each other with a generally mutually-trusting peer-to-peer architecture, similar to traditional multiplayer games. Cheating is handled through governance and penalties against entire orgs.
Orgservers sync information pairwise tit-for-tat. For example, A might ask B to provide A with a list of all entities visible from coordinate (x, y, z), but in the same request A must provide what exact entity is observing the world from (x, y, z).
This ensures information symmetry between any two organizations. Entities that enter stealth (e.g. submarines, ships in warp) cannot observe anything except through data gathered by other in-org entities that are not in stealth. Non-stealth is two-way.
This meshes nicely with "there is no stealth in space"
"Stealth abuse" (entering stealth without a plausible in-game physical reason, using stealth to hide evidence of teleportation cheating) is punished using governance. Orgs that properly keep merkle logs should be able to exonerate themselves.
Efficient synchronization
Sending full entity lists to every orgserver does not scale.
Instead, orgservers A initially provides B with a small number of bounding boxes guaranteed to contain all their entities. Only if B is interested in data for a particular region does B then share exact coordinates of sensors in that region to obtain responses from A.
Last updated