Delete post [Edited by - Vanquish on September 14, 2007 7:39:27 PM]

The figures in the above are similar to the costings I came up with. This may well be a wakeup call to those who've not done their homework.

In other words they're valid. That said, I have seen cheaper colo bandwidth, but can't comment on the reliability of service. Guess you have to suck it and see.

I am SO glad I have budget put aside for hosting. Although not on that scale - I'm aiming for around 2000 concurrent at launch for my project, with very rapid ramp up once the subscriptions roll in.

Very nice post.

That's total bullshit.
While I have no doubt that so many servers with a LOT of bandwidth would cost you that much, a good MMORPG can host maybe 5K players on a machine (in 5 virtual servers).

We have a 2CPU P3 1.1 ghz machine and with over 500 players online it takes only about 15-20% of the CPU. And our server uses only one CPU.
And why in the name of god would you need a dedicated database server with 4GB RAM and stuff? Just use some P3 withy 512 RAM and you are fine, unless your design is inneficient.

The figures above are also similar to the ones that buried Warhammer Online - game support costs in addition to this were horrendous.

For my own project, I do a lot of math on the server end for event culling and some simple 3d physics. I'm aiming for a fairly hefty PC in other words. Also I keep a lot of assets in the DB, rather than file, since I have a live-update system in place. The dedicated DB makes sense for me in a cluster larger than 1 or 2 machines. Raduprv is right in that the CPU doesn't need to be great for it - but I disagree about the RAM, in the case that assets are stored in the DB (or a very large player base).

If you use the DB only to load and save player data, you will be OK.
If you save the whole world, it's a different thing.

I think the data the OP has is a bit overexaggarated. If you're going to start out with an MMO, all you need is 1 gameserver and 1 DB server, and perhaps even stick with the DB server on the gameserver.

Sure, if you serve a playerbase of which 10K of players is online at anytime, you need 2 to 3 gameservers and a seperate database server. But if you're start your own MMO, it's not like 10K of players will be online from the first day on.

First of all, if you're going to launch your own MMO, you'll run it from home to start with. Why? You most likely have a PC to spare to run the server on, it's cheaper as the internet connection is already there, and all you have to account for is the additional cost in electricity.

Toolmaker

And please, don't use a relational database as your game DB. Check out what the guys in the financial industry do.

I do use the DB to store the entire game world and the assets that comprise it (server side assets like collision meshes and some live-tweakable client side assets). Also stored on the DB are current asset tree hashes, which can trigger downloads from an external patch server.
Local cached versions of these assets relevant to the machine's domain(s) are kept on each machine in the cluster, but the DB is the master copy.

What exactly is the advantage in storing everything in a DB? I can understand storing the playernames and items and stuff there, but the colision detection??

My intention with this design is to allow live editting or rapid-prototyping, without taking the cluster offline, and to allow switching of what areas are included in what server domain, even to the point of allowing discontinuous domains.

Asset reuse is also heavily implemented - the precise same terrain information may be used in several physical areas - the database simply acts as a repository of this data, in addition to logging what data forms part of what physical area. Primarily hashes are used to check asset validity - assets are then copied from the DB to the server's local cache.