T=Machine » 8 things to avoid when building an MMOG server
A few years ago, I wrote an article for Develop magazine - “10 MMOs you don’t want to do”.
Here’s 8 things you really shouldn’t do but that might seem like a good idea if you’ve never made an MMOG before.
All these are examples of things that have been done on real MMO projects, usually MMORPGs.
1. use off-the-shelf middleware from the enterprise industry. It’s designed for completely different usage-patterns and cannot cope with MMO style usage. Equally, initially distrust anything from traditional Big Iron companies.
2. think that Grid Computing will somehow magically solve the problems. It won’t (c.f. previous point).
3. aim to code the server in a scripting language. You *can* run some scripts embedded in the server, but not the server itself - but even that can screw you when you’re trying to run thousands of scripts at once
4. assume that front-end load-balancing will solve any problems. It won’t, all it does is increase the efficiency of your cluster by a small amount. And it usually won’t provide you with failover, because most game designs will end up kicking you from your server if it dies, so the failover never gets used at that level.
5. ignore performance testing until mid-way through the project. If performance tests at 10% of the way through production say it’s slow, that means you’re in deep trouble - it does NOT mean that “we’ll come back and optimize it later”. Optimizing netcode and server code is NOT like traditional single-threaded local-only optimization: many of the things you’re dealing with (like LANs, and TCP/IP stacks) run orders of magnitude too slowly, so your optimization comes from imaginative system-architecture, not from optimizing small chunks of code at a time.
6. ignore billing concerns in your core game design. Non-free MMOG’s are entirely about billing, which means that you have to design it in, and build it in to the tech design from an early stage. Retrospectively adding billing hooks and billing information to existing server codebases is often about as easy and effective as retrospectively making your code secure. Just don’t go there.
7. hire an academic who specializes in networking, especially a PhD student (this gets done quite often). All this means is that they’ve obsessed with a very narrow slice of the many many problems, and generally they won’t know WTF to do about the rest of the problems. That’s no better than just promoting a general programmer to become “the new Server specialist”
8. innovate on both technology AND game design at the same time. Either do a traditional MMO so you can re-use all the existing common wisdom for design, and get to market (or at least a stable GDD) fast, and use the slack that buys you to focus on better tech, or use the most boring tech you can think of (instance lots; do lowest-hanging-fruit in your tech design) and innovate on the gameplay
9.
