31–40 of 76 posts
Once you start caring about the performance the second thing you do is stick a cache layer of one sort or another in front of the database; the first thing should be making sure you have the correct indexes.
In any case, it sounds like a distributed cache problem. I wonder if you could just abuse redis for your game backend?
In most data architectures the DB is only the backing store, because no matter how fast your database is it's going to be slower than RAM. Once you start caring about the performance the second thing you do is stick a cache layer of one sort or another in front of the database; the first thing should be making sure you have the correct indexes. In any case, it sounds like a distributed cache problem. I wonder if you…
There's so many of them. I have to assume they're spatially limited. You enter a zone, or an area, and the system loads up all of the quests located in that space, then it runs through to determine whether you qualify for them.
As for quests that you're on, that's a bit more straightforward, since you're so limited to how many you can carry around with you at any one time. Then, every event can practically just be brute forced across your pending quests to see which ones get progressed, etc.
But it was always a curiosity to me considering the magnitude of the quests available how most anything can trigger quest progress.
There's also the whole achievement system, which perhaps is similar in design.
Early MMOs (WoW, Asheron's Call, Everquest, Daoc) were very impressive in terms of distributed computing.
WoW is a 2nd or if you count Meridian 59 as gen1, 3rd generation MMORPG.
It was not the 1st that had seemless maps, but IMHO it did that best. EQ2, while not having seamless maps, would be in the same league as WoW.
In most data architectures the DB is only the backing store, because no matter how fast your database is it's going to be slower than RAM. Once you start caring about the performance the second thing you do is stick a cache layer of one sort or another in front of the database; the first thing should be making sure you have the correct indexes. In any case, it sounds like a distributed cache problem. I wonder if you…
Earlier quoted context omitted.
They were not really distributed though, I think one of the first that really started was Guild Wars 2. 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-...
Would this count? https://www.gamedeveloper.com/design/classic-postmortem-i-as... > 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…
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.
Does anyone know any more good resources for designing an MMO architecture? Would love to do a MMO as a side project but a bit daunted by the unknown of architecture development.
Also important for most online games: any core gameplay relevant actions need to be server authenticated - usually you do RPCs from client to server, resolve the result, then broadcast it to the relevant clients.
The "cache, lots of cache" statement is the most true of any MMO architecture we can build. I did some optimization work earlier this year on a project where the single back-end server is now handling 2 billion requests per minute and had around 3TB of RAM for cache (I think the final production system was aiming for 12TB of RAM). There's concerns around race conditions as you pointed out, message passing from client…
Early MMOs (WoW, Asheron's Call, Everquest, Daoc) were very impressive in terms of distributed computing.
They were not really distributed though, I think one of the first that really started was Guild Wars 2. 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-...