Distributed SE MMO architecture recommendation

Mark McCorkle shared this feedback 2 years ago
Submitted

There is this great sci-fi book titled "Snowcrash" where the VR MMO that many of the people inhabit is run in a way where the player's own hardware directly affected the "resolution" of their avatar and what systems they could run within the MMO.

Back when I read that, I imagined that each user of the MMO would 24/7 run a "system tray" process on their PC which functioned as their "run things that belong to me" process -- eating up their own local PC's resources to render things like their home, vehicles, and whatever other programs that user needed to complete the functionality of their 'grids'.

Fast forward nearly 10 years and I believe that for SE to reach the mmo level of scale cost effectively, this type of architecture could be applied. An architecture where individual players cannot affect the experience of others and thousands could be online simultaneously. An architecture which pushes the cost and burden considerations of a player's creations onto the creator of those things.


How it would work:

The player's PC would run a persistent service where all the player's production, moving grids, PBs, physics, etc would continue to run even when the player isn't in the game. The "pcu limits" would be enforced by the player themselves based on how much of their PC's resources they were willing to give up for the game to keep their grids alive while they were offline. Any player without the bandwidth or computer resources who still wished to have their grids running at full capacity could pay a small monthly fee to Keen or a hosting provider to run the service for them.

The user's system service would operate in a pub/sub model, where each player's system service is the publisher, and a central (Keen run) "area of interest" server would mark any players that are within the AoE of this player's grids as "subscribers" so that when this player's PC would publish an update, any subscribers would get direct publishing from the owner of those grids.

This shifts the burden of processing all of a player's grids to the player.

This architecture is based on my own designs plus research into modern mmo architectures and a firm understanding into distributed hosting computing.

Attached is a diagram that explains the primary player data flow and calls out the important details of how this architecture could work. I'm happy to flesh out any use cases that you believe this architecture wouldn't support.