Turing Machine: 10 MMOGs you shouldn't make
10 MMOGs You Don't Want to Make
(originally published in Develop magazine at the 2005 GDC)
The buzz about massively multiplayer gaming oscillates like a broken TV set. Last year all we heard about were MMOGs being abandoned, even in development; this year has begun with World of Warcraft proving "too" successful for its servers to cope.
The MMOG genre does have some peculiar qualities, which suggest it really could cause a sea-change in the business models of developers. One of the most alluring promises is that studios can create an ongoing revenue stream that requires no marketing(everything's viral), no distribution (everything's downloaded) and where revenues are predictable (a fat cheque being deposited in the studio's bank account each month, without fail).
Who could fail to be excited by that? Better yet, MMOG game design was originally thought to be simple RPG fare (familiar to developers from past projects), allied with the implementation of simple FPS-style 3D engines with humanoid characters running about a pretty LOD-managed landscape. Easy! Except ... it's turned out to be much more complex than that, not least because of several cunningly disguised pit-traps that studios keep falling into (some even jumping down the same trap, several times in a row). Here's a guide to what NOT to make:
1 The MMOG which is also an Engine
The Idea
Make a game and some MMOG middleware at the same time. If one is a commercial disaster, the other will make up for it.
Why it seemed a good idea at the time
Making a successful game is very risky, and making a new genre of game which requires lots of tenhology you have no experience with is even riskier. But selling middleware to other people is, surely, risk free. So balance the risky development wit hthe risk-free one. If the middleware is any good, it can be licensed for millions of dollars a time, just like id Software did with its Quake engines.
But you didn't realise...
The main reason that here's not much good MMOG middleware around is that it's very hard to make. Most middleware sales will probably fall through, yet they are costly even to attempt, making it a high-risk business. Hardly any less so than selling the game.
So what actually happens is...
You thought you'd be working on a game and getting a 'free' middleware product at the same time for almost no extra development cost. In fact, you find you're trying to do two development projects on a budget intended just to cover one of them. Worse, the middleware ususally costs much more to develop than the game, so you've only got the budget to fund the lesser of the two projects. And selling middleware is far from risk-free. It may take six months of hard negotiation to sell just one licence. Anyway, most people won't even buy your middleware because your rushed game "sucked". So you'll need to develop a second, better, game to convince anyone to buy your engine - or else write off a huge waste of money.
2 The Server-less MMOG
The Idea
Networking is fairly simple. We'll get on with the client, and hire someone towards the end of the project to do all that networking stuff.
Why it seemed a good idea at the time
With experience in writing multiplayer games (eight-player RTS's and 16-player- FPS's) you might think networking is simple, so long as you know the pitfalls, how to minimise latency, and so on. The techniques are easy to re-use and almost universally applicable. Also, when it comes to publisher milestones or gaining funding, it's not an invisible server that convinces, it's a flashy graphical demo. It's not worth spending on something you don't need (yet).
But you didn't realise...
There really aren't many people who can write you an MMOG back-end from scratch, even in a couple of years. There are very, very few teams who'd have a chance of coding a simple basic working system in under six months - even without most of the features.
So what actually happens is...
You discover late in the project that your dev servers are utterly useless under real-world loads, and that no-one knows how to make a better one. You hire someone who works in distributed systems to make the server, and they can't believe you need as much done as you tell them you do, so they assume you don't really mean it. When six months later you ask them for the working system, they laugh. Then, slowly, the realisation sinks in and you stare at each other, realising you've either got to ask for another 12 months dev time, or cancel the project (and the client dev was going so well!)
Alternatively, you outsource the server development early, and when they go bankrupt (or just decide they cannot feasibly complete your game-server and choose to bow out), you find yourself with a beautiful tech demo that has no logic (no server system), just a few months before launch. Again, beautiful client, no server - and no-one can possibly get you out of your hole.
3 The MMOG in a Single-Player Retail Box
The Idea
Aim to make most of the sales in the first three weeks, at retail, just like you would with a normal game. All the marketing is arranged for the big, spectacular, launch.
Why it seemed a good idea at the time
You can have your cake and eat it: the multi-million income from the firs few months will pay off most of the development costs, maybe even providing profit - but then youu'll get masses of profit over the coming months from the subsrvier income. Server-hosting costs and support costs (customer support, administration, in-game management) are terriffyingly large, but big launch sales will pay for this. Anyway it's even easier to patch an MMOG post-release than it is to patch CD-only single-player games; as all the players have to be online with decent connections just to play, force-streaming updates will be easy.
But you didn't realise...
The last two MMOGs to launch before yours gained twice as many players in the first few weeks as you'd stress-tested for; there's no way your servers are going to cope. When a server overlaods, but he time it's rebooted, a backlog has built up. One server crash soon brings down all the others, as the backlogs get passed on from server to server.
So what actually happens is...
You only tested your systems for "average" load. On the first day of release, with 30,000 players waiting to log in at once, the 24-hour average may be within what you expected - only they are all going to arrive in the first hour, giving you a peak 20 times what you expected. You spend the rest of eternity fire-fighting, spending all your mopney on trying to fix bugs, with non spare to increase your staff. As a result everyone is always overworked and you never make any progress.
4 An MMOG that wants to be a Single-Player Game
The Idea
Develop an MMOG as if it were a single-player retail title. Most of the efoort will go into the client-side engine, the game design and the client-side testing.
Why it seemed a good idea at the time
You had no idea what you were doing.
But you didn't realise...
You therefore had no idea what stress-testing was. You had no idea why developers complain about "general non-determinism" and "non-deterministic failure modes". You thought that MMOGs could *and should) be written single-threaded, running on a custom soft Real Time scheduler, like most computer games.
So what actually happens is...
Sooner or later, the soft brown sticky stuff hits the rotating cooling-device, and the result is not pretty. The next 12 months will be a nightmare if the project isn't cancelled immediately.
5 The Silent MMOG
The Idea
Community management is hard (and what the hell does it mean, anyway?) and all the players are evangelists. Policing communities is near-impossible, and they'll all chear and use AIM/email/teamspeak. So you let them organise themselves.
Why it seemed a good idea at the time
Analysing MMOGs and trying to be cunning to avoid the hard problems through better design reveals that most of the headaches seem to be about resolving "griefers". Most conclude that static balancing a game with thousands of humans and cheaters is almost impossible.
It's also often noted that players are the best testers. They will work out every aspect of your game: every algorithm, every secret and every loophole. So why not use this as a force for good? Pit players against each other. Those who would normally try to understand and break the system can do so, and be given the power to fix it. A self-organized game-community (a "game without rules, save those you make yourself") sounds like a great USP.
But you didn't realise...
The volume, skill and dedication of people who want to "make the (game) world a better place" are all vastly outweighed by the volume, skill and dedication of those who want to spread chaos. Spreading chaos is just so much more fun, it seems - especially if getting caught depends upon nothing but your own skill.
So what actually happens is...
Local governments come down on you for failing to police laws on hate-speech, rape fantasies and so on. The game-world becomes a wasteland because the player-run society is fundamentally unstable, and the players soon break it beyond all hope of salvation. Customer support and refund costs go through the roof; class-action lawsuits appear on the horizon.
6 Massively-Multiplayer-Simulation
The Idea
Instead of faking and shortcutting, just simulate everything.
Why it seemed a good idea at the time
Even with 60 game-designers producing new content as fast as your 500,000 players can play through it, it's going to be very expensive, if not impossible, to keep the players occupied. Also, the developers are always blamed for all unpopular gameplay decisions and any random events that are "unfair", because the players "know" it has all been pre-ordained.
Instead, by using mathematical models and letting emergent behaviours take over, you will provide a never-ending, always-changing game at little or not cost - and changing yourself from the players' enemy into their ally.
But you didn't realise...
While players love to play with your simulation, by "play" I mean "see how many ways they can break it". Imagine a four year-old left alone with a hand-built model of the Cutty Sark for half an hour, wondering how it's put together.
Simulations never work in the long-run. No-one has yet produced a true, non-trivial simulation that the players can't quickly wreck.
So what actually happens is...
The players collude and destroy your simulation. Just like the Millennium footbridge in London, where every single pedestrian subconsciously started walking in time until huge vibrations built up, your players will all do at once whaever one thing is the most damaging thing to do to your system. It's like everyone on a ship running over to one side to look at the dolphins, and so causing it to capsize. Except that most of your players probably did it deliberately.
7 The Object-Oriented MMOG / DOA MMOG
The Idea
Using the design rules and 20-plus years of OOP design and development experience, you will make a clean, three-tier architecture - all nice and neatly encapsulated, and so easy to manage and maintain.
Why it seemed a good idea at the time
OOP is good, OOP reduces maintenance costs and makes design simpler. An OOP-esque server is very easy for humans to reason about.
But you didn't realise...
A server architecture that is easy for humans to reason about is almost impossible for a cluster of machines to execute efficiently. Fundamentally, the system that is most natural for humans to invent is one with huge amounts of abstraction, which means high-latency.
So what actually happens is...
Even on your local LAN, the latency to get the server to do simple calculations is being coutned in the tens or hundreds of milliseconds. This is before you add-on the 50-250 ms roundtrip-latency imposed by general internet connectivity.
Everyone wanders off, bored.
8 Everquest Evolved: The Best Bits
The Idea
Take Everqyest, copy it and fix the ten most "obvious" mistakes they made in the design.
Why it seemed a good idea at the time
Everquest (EQ) was the benchmark by which all other MMOG successes were measured, and it continues to be spectacularly popular and commercially profitable, despite its age and simplicity. But it had lots of small problems that turned out to have a huge negative impact on players. With the benefit of hindsight, these can ALL be fixed without too much effort.
But you didn't realise...
In the main, the hundreds of thousands of people who continue to subscribe to Everquest are not doing so because they like the game, but because they are already there. They have invested thousands of hours of play in building up their characters, and have large social networks that exist mostly in that game.
So what actually happens is...
Your game takes many months to develop, and by the time it finally comes to market, it's panned by critics for being ugly, simplistic and utterly indistinguishable from the rest of the crowd, not to mention EQ. Your game makes few sales; and the EQ players carry on playing EQ and bitching louder than ever. This despite the fact that your game fixes ALL the problems they are bitching about.
9 The Players MMOG
The Idea
Make the perfect MMOG, determining throught lots of player interviews and from discussion boards what players actually want.
Why it seemed a good idea at the time
Everyone is trying to make a mass-market MMOG. Sony pinned its hopes on the huge appeal of the Start Wars licence, and it failed. What's the secret? Well, every game has thousands of fans bitching constantly on the boards, in public view, often with very similar complaints - and for every one who complains, there are probably 100 more who don't bother. You plan to listen to them.
But you didn't realise...
As Richard Bartle has recently pointed out, the things players complain about bear little actual relationship to the things that need to be fixed to make the game better.
Moaning doesn't qualify players as game-designers. Why is it that after years of confidently telling players that their "brilliant" new game ideas have already been thought of hundreds of times by professional developers, we suddenly cave in and act as though vociferous jobless students who spend all their life playing one single online game are somehow automatically better at seeing what makes a good game?
Besides, the best community-building force is shared suffering. Without suffering, it's harder to rouse people's emotions and harder to get a real community going.
So what actually happens is...
Your game gets a lukewarm reception on launch and none of the viral marketing gets you many players. Your die-hard supporters are few indeed, and most people condemn you with faint praise: they simply never got hooked.
10 The Outsourced MMOG
The Idea
Outsource all the stuff that is unique to MMOGs: clustered servers, in-game custoemr support, monthly billing, even network layers. Concentrate on the stuff you know best: gameplay and making fast, beautiful, clients.
Why it seemed a good idea at the time
Analysis of previous MMOG failures shows up some common patterns. The most common is that while the 3D graphical client is perfect and the game greate, the non-traditional stuff (launch, customer support, patching, server management, bandwidth provisioning, and so on) fails for simpel reasons.
MMOG's don't fail because of incompetence by the developers, but rather ignorance in certain areas. So you will avoid those areas entirely.
But you didn't realise...
It's out of the frying pan and into the fire: you're turning your studio into an outsourced programming contractor. You might (finally) have escaped the strictures of being beholden to a publisher, only to put your masterpiece into the hands of a third party just as soon as initial development is complete.
And once they've got you by the short and curlies, they ain't gonna let go.
So what actually happens is...
The middleware providers suddenly get very unhelpful and start blocking each and every request for improvements to the system, because if they do nothing they make lots of money with little expenditure - and so it's just not worth the hasssle to them to change things. You lose creative control over your game: someone else is doing the in-game administration, and all the promotion and customer-support that seemed so much hassle suddenly - very obviously - becomes the major thing shaping how the game can develop.
Worst of all, you've got no contact with your customers; someone else is billing them. It's their logo on the monthly statement, their contact numbers, their branding on your success. They have an exclusive, free, audience of paying customers (of hundreds of thousands) to whom they can pump large amounts of advertising and cross-selling.
Weep as you watch them displace you entirely in the money-making side of the game.
