Hi, I'm currently working on a mmo game (mmorpg to be precise). For the server part, I can see 3 solutions, but without knowing the one is the best/easier. a/ 1 server, 1 world This is the simplest solution at the beginning. Do a simple server, and when it's full, buy a new one. You'll then have 2 worlds. They're full ? Buy a third one, and so one. Pros: - easy to develop - easy to grow Cons: - multiplication of game communities - adding functionnalities (then ressources need) to a server means lowering maximum players count. b/ 1 world, n specialized servers Here, we split the server logic in different servers. Once for the connection, another one for IA, the third for fights, one for chat, ... All of these servers need to be connected one with the other. Pros : - architecture 'easy' to understand - everyone on the same world, without bigger servers - code well partitionned. each server has his own utility, and don't need to konw how his friend works. - good for team work. A server for everyone, everyone a server :p Cons : - not very scalable : what happens if the chat server is not used, but if the fight one is full ? - probably needs a lot of communication between servers, for data (characters states, ...) exchange - synchronisation problems ? c/ 1 world, n parallel servers In this solution, instead of specializing each server, we just do copies of the same. For example, we could imagine a simple server do all the work (fights, chat, ...) but only for a portion of the world. When a player cross an imaginary boundary, he just connects on another server, and that's all. Pros : - scalable. Just add a new server, assign some parts of the world to it, and the load will be balanced. Cons : - need to split the world in smaller entities - probably needs a lot of communication between servers, for data (characters states, ...) exchange - synchronisation problems ? Well, here I'm in my reflexions. At this time, the last solution is the one I prefer, but I would like some opinions. Is there some traps I didn't see ? Does another solution I didn't see exist (maybe a mix between b and c) ? Thanks in advance for your help, and sorry for my crap english, Camille

Out of all the MMOs I've played, they all seem to favor a 1:1 mapping of server-to-world. You may end up with multiple communities; but, that can add to the flavour of the game. You get some servers saying that they're better than others, and that could draw some people to those particular servers. One big question is though, would you allow each subscriber to create at least one character on each server, or would you limit them to one character per account?

It could also boil down to the workload your server needs to perform. If you don't have a player cap on a server, and everyone flocks to that one, you could experience severe lag, and possible server crashes. If you decide to stick to a single world, where every player plays on, then the parallel servers approach may be something to consider.

This also brings up the issue of costs for moderators/game masters. If you were to use the 1:1 mapping, then you would need to find GMs for each world.

As well, some players prefer to do nothing but PvP while playing an MMO. Others prefer PvE. So you should take that into account. If you decide on keeping with a single world, you could alienate one of those two groups if a balance isn't found. Personally, I'd prefer a dedicated PvP server, yet still have the option of becoming a PvP player on the regular servers. But, if I were to become a PvPer on a regular server, I don't think I should be allowed to liberally attack non-PvP players, unless they either consented to a sort of duel, or entered a PvP "arena".

Just some food for thought.

Hi there. It's nice to see another MMO project kicking off from someone who's actually considered the back end architecture. ++ for you.

For an indie with limited funds, I think option c is the closest to what should be done, but remember that a 'server' is not a machine- it's a process, which may be on a particular machine. If you keep the concept of process and machine separate in your mind your task becomes easier.

I've not heard of fights being handled on separate servers - 'heavy duty' AI tasks (A*) do tend to be farmed off to an AI process, but this relies on the AI process having the requisite resources loaded for all tasks.

Personally, the architecture I advocate is a microcluster consisting of a single master process, a login process, and a database process, not necessarily on the same machine. Optionally, slave processes can take over a portion of the game world, by registering with the master process. There's a fair few threads on this sort of thing in this board.

Thanks for your wuick answers.

Quote:

Original post by Dorvo It could also boil down to the workload your server needs to perform. If you don't have a player cap on a server, and everyone flocks to that one, you could experience severe lag, and possible server crashes.

It's what's happening with the last game I worked on. It's was a simple architecture, a mix of the a and the b solution (one server for conn, one for database, and the last one for... everything else). Connection server and database process are fine. But balancing game servers is a trap. At this time I've got the oldest game server holding about 4.000 simultaneous players when the 2 last ones take only 2.000 of them. Add to this GM problems, as you said, and you know why I'm trying to find a different way :p
But of course, you're right, the best solution is still to have several different worlds. At least to separate PvP, PvE and Roleplay.
i'm not against a "p worlds, n x p servers (or process)" solution :)

Let's continue with a new question :
What about servers emplacement ? (Ok, it's no more development here, and I would understand if someone complains about it)
For lag and performance, it's always better to have the server and the players as near as possible. That means you have to set up different servers, at least one per continent. So my question : do you think it's better to think about it as several different games, with no connections, or to think it as just some parallel worlds, linked not with a LAN but with a WAN ?

Ok, I stop my philosophical questions, now :p

Typically the login process is not time-critical and so can be centralised (physcially, and also tied in with your subscription management). Individual clusters (world instances) which an authenticated client can communicate with can then be localised (per continent or whatever). The player simply sees a single game, which they choose a shard of, and know that they can expect better performance in a local shard.

We do 1 world, N "interchangeable" server machines. This is great for a "virtual world" type environment. The fact that the servers are interchangeable (scale linearly) means that you get pretty easy redundancy/fail-over, too. We also do seamless hand-off between the servers, so you never see any zoning.

However, this took a while to get right. I would not recommend it for someone who's starting an indie project. Perhaps even more importantly, there are significant game design aspects that are hard about a single world, and hard about a non-zoned world.

Zones provide structure to a game world, and I've heard several game designers say that, after being zone-less, they'll go back to zones. Just like platformer games still have levels -- you need that structure.

Further, if you design a single world for 200 people online, what will you do when you have 1000 people? If you design it for 5000 people online, what will you do when you have 25000? Shards solve this (very hard) game design problem; they allow you to balance a single world to a specific population count, and then replicate it as necessary while maintaining balance.

If I were to build a MMO today, with a heavy RPG game-play element, I would go for a zoned world (one process per zone), and scale through sharding. It's absolutely simplest technically, and solves a number of game design problems.

Thank you for this concise and concrete answer !
It confirms my opinion to go with zoned servers and to add shards when required by the gameplay (size of the world too small).

Btw, I'm not alone on this project, and already built up a 15.000+ simultaneous players mmorpg. So the seamless zoning system seems to be an attracting challenge, now :p

Quote:

Keep in mind that there are times that your login server can be time-critical. The biggest is when the game crashes, and around 6:00 PST. You will get a flood of clients trying to log on.

Why? Your authentication ticket should still be valid; the client doesn't need to re-authenticate unless you're down for longer than your ticket expiry time. Or do you generate a new random server secret (and re-distribute it) each time (some part of) a server goes down?

Given a very large player base, I'd probably split the login processing across several login servers - say one per cluster. I'm assuming that 30k on a single cluster is unlikely (more like 5-6k concurrent) - and assuming that players can select which cluster they wish to play on before connecting. This allows us to distribute the load somewhat, with clients connecting to one of a range of login servers, rather than trying to get through one box.

Alternatively, if a single cluster architecture is used for the entire game (or a very large player base per cluster is intended), then a simiple solution to handling many concurrent login requests is to use mirrored login databases, with connections being made to the appropriate login process by crude load balancing (first server refuses connection, move to second and so on), before passing the authenticated connection to the cluster master process, which will assign it to the appropriate zone process.

In any case, processing time for login details is not as critical an issue as in-game response times.

Quote:

I keep my tickets valid only long enough to do the handoff to the player's communication server.

I would recommend, if you want to avoid having a login system slammed when lots of people come back, that you issue tickets that are valid for longer times (say, four hours at a time?) and re-issue them every two hours while the player is connected. That would let a player re-connect to any of your servers directly (without going through separate authentication) as long as they re-connect within two hours.

Btw: for other readers: by "ticket" I mean something that contains the player ID, ticket expiration time, other identifying data if needed, and a hash (Tiger, MD-5) of these items plus a cluster secret. This allows you to get the player ID out of the ticket and verify that it's valid without running anything more expensive than a hash, when the user connects.