I wanted to shape and explain my idea a bit better so that I’m able to show more clearly how and why it can work. Just as an exercize.

Requirements: Obviously the idea is possible only if the programmers are able to implement it. From my point of view it’s nothing fancy but there are non-trivial parts. The biggest issue to solve is that the databases need to communicate between each other. Some of the data of a character will be moved (cut and paste, not simply copied) from a database to another and the problem is a possible data loss during the transition. Now I’m not a programmer but I imagine that it’s something solvable in a creative way, for example using a system similar to the journalized filesystems (ext3, XFS etc…). There shouldn’t be other problems since what I propose is simply based on the possibility of that operation/transition. So, once this problem is solved, the rest should work.

The goals: There are three different goals. The first is to regulate the load on each server/shard, so that the population is spread equally on the servers, avoiding overcrowded, crashing servers and totally empty servers. The second goal is to regulate the balance, so that the population is more even between the factions of a PvP environment. The third goal is to insert the previous two into an in-game mechanic/gameplay. So that this system is part of the frame of the game, within the frame of the roleplay and not just an Out Of Character mechanic based on the technical data coming from the math on the servers.

Beside these functional goals there are other three “design” goals:
– Create an united, global and massive environment that doesn’t artificially encapsulate the players inside air tight spaces.
– Allow the players to travel cross server, meet and play together with their friends and reorganize and build new guilds without the need to restart from zero or create alts specifically to overcome the limits in the current mmorpgs. The choice of a server won’t be “tragic” (as an unavoidable consequence that cannot be made up) as it is in other games.
– Break the overall community into smaller, manageable units-per-server through the shard system (too big communities are overwhelming and, paradoxically, make social ties nearly impossible).

“There were a lot less of us back then, so it was easier to get to know most of the folks around you. Since there were so few players reletive to current community sizes, you become friends of friends of folks and a lot sooner you really end up knowing virtually everyone whos playing, or at least are familiar with guilds.”

How it works: For this example I decided to simplify more and more my idea to show how it works in the core. All the rest are layers allowing a more precise control but the core is what it makes it a valid idea. For now I don’t need fancy data, what World of Warcraft shows in the server login screen is enough. It just tells the load of a server in three different states. Low, Medium, high. That’s all I need. At release it’s obvious that I cannot achieve the third goal I explained above (transforming the system into an in-game PvP action) so for the first month it will work in a “special” status.

The idea is that the world is still differentiated into cloned shards. Each shard has a perfect identical copy of the landmass of the game-world. On each shard you can find two types of portals. One to leave the shard you are in, like an exit, and one to arrive from an external shard. To understand better the server structure you need to look this diagram:

As you can see the shards aren’t directly connected between each other. The exit portal doesn’t bring directly a character to another shard, instead it brings it to a “limbo area” working like an “hub” (similar to Guild Wars or Tabula Rasa, but the hubs are unique and not instanced). So the transition is:

Shard(a) => Static Plane => Shard(a-z)
From a shard you can only exit to one of the planes/hubs, from a hub you can exit to every shard in the gamem (if the portal is open).

Now. As I said we know just the load of each of the shards in a three-way status. The portals simply work on the following way:

– If a server is flagged as “low” population, both “in” and “out” portals are open.
– If a server is flagged as “medium” population, same as the first case.
– If a server is flagged as “high” population, the “in” portal is closed, the “out” portal is open.

At release when you create a character you *cannot* choose a server. The game will randomly pick a “low” population server and send you there. Once you are in the game you can freely leave the shard and follow the portals rules as I explained them here. At any time players in a “high” population server can leave to migrate to a less stressed shard. Noone can get in that high populated zone till the population number will decrease under a set limit. This means that the server will never crash for server-load issues. Once a server is capped the players can leave, but not come in. The new characters instead will be sent to “low” population servers. This will help to have the players equally distributed.

—
This is how the idea works at its core. Then there are a lot of “complications”. The first complication is about the real math formulas used. We cannot simply calculate the load of a server in a precise moment. Instead we’ll have an algorithm that will keep track of:

– The load on a precise moment
– The average load in the last hour
– The average load in the last twelve hours
– The average load in the last day
– The average load in the last week

The server will then combine this data and decide (giving to each a percent of relevance) if a server has “high, medium or low” load. This means that you won’t see these three statuses change sharply as the players log in and out. Instead it will be a relaxed movement. The formula isn’t done, though. Because the server also needs to track the number of unique characters it holds. This because we cannot forbid a player who logged off on a shard to not log back in because the server is set as “high”. So another percent of relevance must be granted to the number of passive (not logged in) characters inside the server. And that value must be considered once again in the calculations to sort out the status.

At this point we have a strong system to enforce *always* a precise load on the servers. Avoiding overcrowding issues and obtaining an even load on each server. But this isn’t the end. The complete system that will trigger *after* the first month after release will have three progressive “checks”:

– The first check is the one I explained above, unchanged. Each server/shard calculates its load. If it’s “red” the “in”-portal is closed. The other two checks aren’t needed. The portal is marked “red” and cannot be unblocked in any way. The players can only move out. Instead if it’s “green” or “yellow” (the load isn’t heavy) we move to the second check. At this phase the portal is still marked “red” and blocked at the eyes of the players.

– The second check is about the PvP balance. The server/shard calculates the proportion of the various PvP factions of the game, following a similar algorithm used to calculate the server load. It’s at this point that the players could see the portal change its status. If the players belong to a prevalent faction the “in”-portals are blocked even if the server load is low. Instead if you are in a faction with lower numbers AND the server load isn’t high (previous check), you’ll see the portal marked as “yellow”. It still isn’t open and usable.

– The third check is more complex because it’s about the third goal I explained above. From the player perspective the first check is hidden, passed or not. Then we pass to the second if the first was passed. If the second check fails (still red due to PvP population unbalaces) the players still have the “in”-portal blocked and red. But if the second check goes ok, the portal changes its color and becomes yellow. Now the portal CAN be opened but still isn’t opened. And we are at this third check. In this phase the system becomes gameplay. The players need to organize and conquer (PvP) power nodes inside the shard where they play. When they own enough power nodes the portal finally becomes “green” and can be used.

This is how the system works in the long run. We achieve the first goal because the server load is always under control, we achieve the second goal because the PvP faction population is as equilibrate as possible (within a threshold), we achieve the third goal because the portals are an in-game mechanic requiring you to *play*. To go out, take part in the PvP, conquer the land and then be able to move to the limbo areas where there will be access to an instanced form of high level PvE (the “adventures” in the diagram I showed above).

Have fun ;p

P.S.
As I explained here the shards will be PvP zones where the RTS layer (and the economic system) of the game takes place. But in order to participate in the conquest system and build/own/maintain properties the players will have to be organized in guilds and alliances. A guild can only set one “home” shard and cannot conquer or own territory on multiple servers. A guild can still relocate its “home” but only after giving up all its current assets.

This means that the cross server travel is always a possibility but won’t be part of the daily use. The mechanics of the game, as explained, encourage the players to organize and settle down in the home shard they choose. It’s in their interest to maintain and consolidate their progress there and not take everything and move somewhere else without a major motivation.

What is retained can carried over in a server move is the character and its possessions, plus the guild identity (if the whole guild decides to move and select a new “home”). But not the guild progress and status in the former server.