Open-world, non-MMO server architecture

I have a near-infinite game world that I am looking to add multiplayer to and would love some input on the best way to go about it.

The problem as I see it is the need for server authority over physics checks such as fireball and arrow hits and dealing with floating precision errors. Nothing super sensitive or complicated, it's a fantasy RPG, not a fast-paced FPS. In single-player the game deals with this by shifting the world back to 0,0 in 8192m increments so the player is never calculating numbers greater than that. Some players however have reached 10,000+ kilometers in the gameworld; I'm not clear on the best way to handle this server-side.

Now I'm not looking to add support for 100s of players or an MMO type server farm, for now 2-4 players is plenty. But, again, this is openworld, not "area" or "room" based, players are free to go in any direction.

Solution 1:
I'm imagining a master server setup where the game data/inventory/crafting is stored and handled on the master server and sub-servers are generated as needed to handle local physics and AI. If both players are within 8192m (simplified) of each other one server is enough. If player 2 gets far enough away a second server starts up and when it's ready it takes control of player 2s local physics, keeping the world near his/her local 0,0. When player 2 again crosses the threshold for "rejoining" player 1, both physics checks go back to player 1s server, server #2 goes to sleep waiting for someone to wander out again.

Solution 2:
Since we are only running logic on the server, local areas could be defined in world space on a single server offset enough to prevent interaction with one another. In single-player AI more than 200m (guess) is disabled. With a known offset of say y-1000 for player 2 (when he/she gets too far from player1), we could handle player 2's physics checks at varying locations. This is basically the same idea as solution 1, just handled different.

Again, nothing horribly difficult, enemy navmesh checks, a few projectiles tops, and player movement against world colliders.

Thank you for any input.

Comments

  • hi, @kylepostlewait

    If one server may handle the entire location, then I would split between the servers on CCU basis. In case 1 you will need to do this anyway. Also, solution 1 complicates servers management and increases costs of the game

    best,
    ilya
  • Though both sound like daunting tasks, case 1 is not doubt far beyond case 2. I'm working towards trying it out in it's simplest form for now. If I limit players to 4km^2 chunks and connect as needed only when the same terrains are going to be used by one or more players I should still be able to fit 16 players in a +/- 8,000m environment and avoid floating point precision errors.

    I only need monster AI really, so it might not be as difficult as I'm thinking. I'll still dream of more players on a single server, but there's plenty of things to do more important than that =]

    I got the basic system working today, just have to work on my understanding of what really draws the line as server authorative and then how I can go about manage my player "zones" to allow long distance travel. I'll lock every body into the first 16km^2 for initial trials.

    I also sent an e-mail, but I might as well ask here as well. For the server pricing plans, the ~$90 plan for 500 CCU is for users passing through the name server correct? Players can host rooms all the want so long as the global number of users doesn't exceed 500? The "per app / server" wording had me a bit confused.
  • you will get an answer in reply to your e-mail

    best,
    ilya
  • E-mail actually didn't answer the question XD
    But I think I've answered it myself through my experience working with the load balancer demo today. Basically only 1 name server can operate per license. But the number of connected clients hosting rooms is only limited by the CCU limit, not the server limit.