If I were to tell you that I was thinking of making an MMO with a database-centric design, using a DB to serialize entities from one sub-server to another, you would be in good company if you thought I was a dumbass.
Darrin West, the architect at Emergent Game Technologies, does not waver in his disdain:
There are hidden costs of a DB-centric approach for migration. … In my experience, DB throughput is the limiting factor in scaling a shard. Please, please, run screaming from DB-centric!
No? If that doesn’t convince you, how about Bryant Durrell, former Tech Ops director for Turbine? Let’s see what he thinks:
Relational databases: please no!
OK. It is completely obvious that any MMO is going to need a way to store data. I understand that the instinctive reaction is to use a relational database, because that’s what relational databases are for. However, I beg of you as the guy who needs to keep the things running fast and smooth, think twice.
However, Emergent’s MMO engine still isn’t ready for development, and Bryant doesn’t seem to have leaked Turbine’s server technology to the internet before he left. So I know there are better ways, and yet I can do nothing about that.
… Or Embrace Your Destiny!
Sandra and I, along with a few others, are plotting out what it would take to make an MMO on our own. And if I plug realistic timelines into a realistic engineering schedule, it appears that two or three engineers working half-time on an MMO will never ever finish it if they have to develop the server tech themselves (or the client tech, or the tools pipeline, but those are a different post). Every single hour that is not spent on gameplay reduces the chance the game will ever come to market. This is the bitter pill to swallow: the best practices of MMO server development simply aren’t available to tiny indie teams, no matter how experienced they are.
There are some really cool technologies that could help, like Terracotta. This sucker is just what we need! Wait, you say it would cost us how much?! Oh. I see… these solutions are designed for rich companies, not indie developers. Well, maybe we can use that for our second MMO.
SmartFoxServer: The Glorified, Extensible Chat Room
In the mean time, we can use SmartFoxServer to make a simple database-centric MMO. It’s got a decent track record: Habbo Hotel runs on it. SmartFoxServer (SFS) is really a simple piece of software: it’s a glorified chat room. This is, contrary to what you’d expect, its strength. See, it’s a really full-featured chat system. Authentication, multiple rooms, private messages, friends lists, ignore lists, bad-word filters, you name it. But that’s all it is. It doesn’t try to be a full MMO engine. And that means it’s relatively fast, elegant, and stable at what it does.
You plug extra modules into the back of your “rooms” to add extra functionality. You can implement entire MMOs as plug-in modules to SFS. And that is one road we’re considering.
If you’re thinking to yourself, “Chat?! Come on, I can write a full-featured super-powered chat service in a month!” then you aren’t getting the “tiny indie MMO team” part. But more importantly, you’re wrong.
There are a ton of details that getcha when you want to make a professional-quality MMO. SFS also provides logging, banning, moderation, customer support tools, and flood prevention. It’s all little detail stuff, none of it hard, but all of it time-consuming. You couldn’t actually code all the features of SmartFoxServer in a month.
SmartFoxServer Plus A Database Equals “MMO” (With Air Quotes)
Okay, so how does it work? Well, you use SmartFoxServer as your “front door”: it helps with authentication and, of course, chat. Then for the game logic, it calls your plug-in module, which in turn loads the player’s character from a central database. Each geographic section of your world is run in a separate SFS “zone”. Multiple zones may be on the same physical server computer, or they might not.
A client only talks to one “zone” at a time (well, maybe a couple at a time. But the point is, it doesn’t talk to all of them at once). When the player moves to a different area, the client literally connects to a different zone.
It’s really simple to code — that’s the whole point. In fact, if you’ve got a good handle on SQL, this is probably the simplest possible MMO server. When you’re a tiny indie company, simplicity is key. But there are down sides.
Embracing Your Destiny Sucks Sometimes
What are the down sides? Well, we’ve basically invented the server technology for EverQuest 1. But EQ1 wasn’t technologically advanced even when it launched, ten years ago. This is a poor man’s engine in every respect.
The biggest limitation is that your world will be segmented into very tightly-defined geographical areas. When the player goes from one geographic area to the next, they will have noticeable delays. This engine isn’t going to win any tech awards.
The physical size of each geographic area is unimportant to the server. Instead, the limiting factor will be the number of players that can be in a given area at once. The exact number of people allowed in one area will vary from game to game, but a good guess is about 50 players per area, max.
And lastly, you have a big bottleneck in your design: the database. It will be the limiter on how big each game shard can grow. And you will need shards: you won’t be able to have one world in which every player exists simultaneously.
The Poor Man’s MMO Is Good Enough
Gee, what if I have so many people playing my game that I can’t support them all without more hardware expenditures? Man, as a tiny indie, I’d love to have that problem. It means I have a hit on my hands, and in that case I will be able to find the financial support I need to get more hardware.
The flip side of the coin is more dangerous: “what if I spend months or years making cool server tech and then never make an MMO with it?” Wait… I already did that before. In fact it’s the easiest trap in the world for an engineer to fall into. But it will doom your project, indie or not.
As long as the game looks good and is fun, players aren’t gonna care that there are load times occasionally. Lots of games have geographic zones, actually. Don’t get hung up on it.
We haven’t settled on SmartFoxServer yet. There are several other simple server engines that we’re going to examine before making a decision. But none of them are going to be amazing MMO masterpieces.
There’s a simple indie mantra that I’ve been trying to take to heart: “design around the limitations.” Don’t try to remove the limitations: get creative and figure out ways to minimize their effect, instead.