8Dromeda Blog

[All Posts] [<< >>] [2013-08-09]

Scaling: The MMO Kind Of

I promised to continue on working on the gamey parts, but... then I was asked: how I am planning to overcome all the typical issues MMOs face?

There are many things that I could try to prepare for, but which won't really break the game, like players abusing the chat or unfairly destroying other's in-game stuff. I have decided to not care about most of that until there is a larger playerbase where countermeasures may actually be useful and can be tested.

However, I see two things that will matter. The first thing is cheating. Soilnar is designed from ground up to be completely server-authoritative, thus cheating is implicitly taken care of as far as possible. The game suffers for other parts a bit from that - but in the long term it's for the better. A community-driven MMO is all about the long-term.

The second thing is scalability. The thing is, if you make a single-player game, no matter how many people download it, each of them is going to have their own computer running it, which means the amount of players playing the game does not affect the game's performance at all.

If you make a game where players run their own multiplayer servers, you only need some kind of a central server to allow players to connect to each other more easily.

But I make a game where the main game logic is largely run on a central server. This means that if it has any kind of player limit and the game starts gaining any popularity, only a fraction of the playerbase can play the game, and I am in trouble. The Single Soilnar server can only handle something like 50 players (conservative estimate) on common hardware - somewhat a misprediction from my part, as I tried to design it to handle 1000 - but even a hard limit of 1000 wouldn't really be enough. I needed to make it so that the scaling of Soilnar would be solely dependent on the amount of server computers one could gather to run it on, and that should be extendable dynamically at runtime.

Here's what I wanted:

1. Launch a server
2. Notice that server gets full
3. Launch another server
4. New players get allocated on new server, and the whole game world is accessible to all players
5. If that gets full, launch a yet another one, and so on

MMOs usually scale in two ways: they run 1) separate areas on separate servers, and 2) the same area on multiple servers. (2) is very important on traditional MMOs because it allows heavy reusage of content made by the game's developers. (1) is used for transitional areas between key locations and stuff like that.

Then there's stuff like EVE Online which is so extreme it's probably not really applicable to anything.

But Soilnar is more comparable to EVE than to something else, which means I'm kind of on my own here.

What I Did

There were two alternatives: Either split the world on an entity-component structural level, or split the world on a physical area level. Now, the framework isn't really designed to be split and the systems have much interaction between each other, which forced me to use the second way, splitting the world into physical areas. However, I would have probably used the second way in any case, as it is way more simple and effective.

I ended up with two types of servers:

• Control Server: The Control Server manages all the Regions, keeps track of which region each player is on, allocates areas, world seeds and entity id ranges to regions. Only a single instance is used. Players connect to it at first, log in to it, and it redirects the player to the appropriate Region Server.
• Region Server: The Region server is largely identical to the previous single server implementation, modified to interoperate with the control server. It is completely self-contained to the extent that players can continue to play on it even if the control server is temporarily lost, as long as they don't need to move or otherwise interact between regions.

The Control Server maintains it's own entity ID range and a stub game world where it stores the overworld map, player accounts and stuff like that. This stuff is broadcast to the region servers, freeing the control server of transferring it to players itself.

Some funky tricks were required for doing stuff like allowing efficiently splitting the entity ID range to a chunk per each region (indexing certain stuff in Soilnar is based on linear redirection arrays in order to get reasonable performance), but ended up being relatively straightforward. All the tricks, control-region communication and actions did require a week of intense-ish coding though.

Programming Overhead

How much overhead does this cause to actual game programming? There are things that I haven't yet made that do require special attention now. These include corporations (global entities, managed by the control server) and money transfer between players (routed from region to another by the control server).

But overally, not that much. Most interactions are not possible between regions to begin with, so those aren't affected at all. I expect quite easy sailing from now on.

Oh by the way: In Soilnar, you are able to carry your friends as cargo in your ship. Guess what? You can carry them over region boundaries too! I wouldn't have settled with less. 8)

- A of 8Dromeda

Scaling: The MMO Kind Of: http://t.co/apTRQtBEbM

— 8Dromeda Games (@8dromeda) August 9, 2013