MMORPG - Server Architecture New Expectations for Indies

In the continued pursuit to find and implement resources for the every growing field of MMORPG designs, i've researched and planned out many variables, the most pronounced being server technology. This includes software combined with hardware resources that can offer the best bang for the buck. The most obvious choice for security and scalability i have found is most obviously the Linux platform. Here i want to address specifics about why Linux is not only the best choice for an indie, but is also the most cost affective solution as well.

Open-source...
Obviously open source provides for much cheaper systems from a software standpoint. That lower cost makes up for most indie developers lack of knowledge or even desire to work with Linux and it's less user friendly interface. Windows and to some extent Mac OSX domination of the market for client based systems is staggering, which offers the highest level of possible player bases. This however by no means limits your server choices. A Linux box can certainly service any platform available given the correct set-up. Open source products are available in abundance and it the slow migration to more open information shares is a practically vital resource for indies that wish to offer an MMO.

Options, options, options...
What i'm going to cover here is limited, but there are pratically hundreds of viable options that any MMO designer should look into with full force. These alternatives are usually modular in nature and have fairly high learning curves, yet many of them offer secure peer-peer/client-server hybrid technologies that can uber expand even the best hardware/software singleton or sharded systems.

Singelton verses Sharded
Singleton mechanics are like a world gone segmented but in a fluent single server feel. Sharded mechanics are multiple "sharded" servers running duplicated instances of the world. An example of sharded architectures is a game like World of Warcraft where the client logs in to one shard for every connection, typically these server shards handle around 3000 clients and those clients all share one instance of the world, closed off from other server shards. The Singleton mechanic offers a fluid persistent world where every feels as though they are on one shared world. Capable of switching between zones to meet fellow players games like Guild Wars and EVE are run in this manner. If this seems confusing to you, it's simply because the architecture isn't much different. Singleton splits the world up into zones, each area being capable of handling around 100 or so clients in a given range, but allowing those clients the freedom to transfer seamlessly from zone to zone. Sharded offers one persistent world, but limits the amount of clients that can create account on that shard. This doesn't allow as much freedom to simply zone to your buddy that resides on a separate server shard.

Both have there advantages and both can offer the alter mechanism through code changes and server designs. So in the beginning of designing your game, giving consideration to the outcome is pretty vital, but not earth shattering if you choose to go either route. There is however some *new* trends/techs we will most likely see in some of the newer releases of MMORPGs. One specifcally of interest to indies is a dynamic layered peer structure, the other and still a viable option for indies (except more costly in hardware capital) is a hybridSS.

Dynamic Layered Peer (DLP) and HybridSS
Although searching the web for either of these will yield less then stellar results, these architectures are however being considered as very viable solutions. The DLP system offers very small amount of upfront server setup. The front end is Almost entirely setup to handle largely populated areas, offer master database structure and offer randomly generated keys for hashing among peers. In this system the larger amount of processing overhead is handle at the client, relying only authoritative data to the master server nodes. Each peer can be setup to handle zones of there own location in game or handle random zone processing, it can also be setup to split up proccesses among multiple areas in game where whenever there are free processing ticks available among any client that data is shuffled then processed, this makes every client a server. This obviously bring to mind security issues, but since it's a joint layered load system, it makes it extremely difficult, if not utterly impossible with key encoding, for a client to access the process thread it's handling or even know who or what it might affect if they could find it. PArt of the reason we don't see this currently is it's complicated and a bit more difficult to manage.

The HybridSS offers the client zoning transparency with a "regional server" front end. This means at any given time you are on a region server, but can easily interact with other region servers dynamically. It's fairly simple to implement and given the popularity of the 2 structures but has the advantage of singleton worlds using definite sharded servers speaking to each other allowing players easy interaction, but also offering structure for competition on a regional level. An example of this sort of system would provide each player to link their account to a server in say the Utah region, giving GM's or OP's the ability to manage local resources and players the ability to form localized groups in their communities of player base. Guilds could however operate in the same manner as sington server systems, where any person from any region could join up with any other, but instead of clients being shuffled between server loads, each player is always regional. Much in the same sense that a server cluster runs now, processor load sharing/balancing can be performed across regional servers where localized machines can reach out for spare processor time on less heavy loaded region servers.

For Neophagia, I'm planning the HybridSS model. It gives players the most freedom, but in a more organized manner. It also allows the scalability options i think suite mmos the best, but I'm keeing an eye out on the DLP tech, since it could offer the best price performance of any mmo out there today. Now how to make it happen!

Two Powerfully Simple Solutions
For me and the research i've done thus far, there are really only 2 options. One is Python and the other (which is seriously leaning toward now is Erlang. Python is used in just about every mmokit out there right now. It's a powerful solution to server scripting technology, but unless you're interested in running all the modules using several different software solutions, erlang offers what i would say to be a more simplified full service solution, taken directly from the faq "Erlang is a general-purpose programming language and runtime environment. Erlang has built-in support for concurrency, distribution and fault tolerance." Basically, it's build from ground up to handle database, server loads, potability and fault tolerance all in one. Although there is far more documentation on how to work python into Torque, i feel ultimately Erlang is going to give the project the best possible handle on server load, redundancy, security and distribution. There are just too many tools built right in!