> One the most impressive features of the Turbine engine is the continuous outdoor environment. This is made possible thanks to dynamic load balancing, which is a scalable serverside architecture. The easiest way to appreciate the need for dynamic load balancing is to consider the following scenario.
> Dynamic load balancing solves this overloaded server problem. Instead of assigning a static geographic area to each server, the individual servers can divide up the game world based on the relative processor load of each server. In the previous example, instead of remaining idle, all four servers would divide the load equally among themselves, ensuring the most efficient use of the hardware’s processing capacity.
That's a useful technology. Second Life / Open Simulator do not have that, and need it. It's good to hear about a success with that approach.
Improbable tried that, dividing the world into regions but moving the region boundaries around based on player density. This worked, but apparently required huge amounts of inter-server traffic. The system was too expensive to operate. (Running it on Google Cloud with metering for every client/server transaction didn't help.) Five indy free to play games, some of them good (look up Worlds Adrift), went bust because of server cost.
Improbable then pivoted to simulators for the UK military, a much less cost-sensitive market. That worked, but they had way too much company and funding for that niche. Then they tried to pivot to crypto metaverses, two years too late, and hooked up with the Yuga Labs (Bored Ape, Otherside) crowd. Lately, they're trying to do something with US Major League Baseball. Their solution to the cost problem is to only run special events that last a few hours, for which they can short term rent some huge number of servers from AWS or somebody.
There's still no good off the shelf solution for this kind of scaling, with big worlds and big moving crowds. Epic and Roblox were making noises about working on this problem a year ago, but not much has been heard recently. Now both are in money-losing and layoff mode.
To be fair, GW2 was able to do that by instancing the world per zone, with loading screens to switch server connections, rather than having a seamless open world.
And the techniques in the article are basically how we did it. (I say “we” but I’m just a system administrator who got to work with some cool people at Turbine.)
As Eumenes notes, the Asheron’s Call engine was significantly ahead of its time with the seamless zoning. The cost was high, though — we needed quite a few servers to run a world, I think many more than our competitors. There are business reasons why we weren’t quite as cost-conscious as we perhaps should have been.
The other factor involved in determining how often you persist is item duplication. If it’s possible to transfer an item between players without persisting state, and if there are known exploits that crash servers (not world, but individual servers), you wind up with an exploit that can duplicate items. But I’m sure that’s just hypothetical.
Its a book https://whenitsready.com/wowdiary/ originally sold as a kickstarter by one of the original Blizzard mappers made from notes they wrote while working on original wow. They did some AMAs[1][2] with other wow developers that sort of touch on some of the topics discussed here.
https://ubm-twvideo01.s3.amazonaws.com/o1/vault/gdc2017/Pres...
DAoC was basically a Linux box with a bunch of processes connected to MySQL.
https://www.gamedeveloper.com/disciplines/postmortem-mythic-...