[MUD-Dev] [BUS] How to build an MMOG...
ceo
ceo at grexengine.com
Tue Jan 27 15:38:09 CET 2004
Stratics have just published a short article I wrote
(http://www.stratics.com/content/articles/mmoguide.php) about
building an MMOG. If you saw Gordon's "10 reasons not to do an
MMOG", it's in a slightly similar vein, and highlights a couple of
points made by people on MUD-Dev.
It was borne out of seeing the millionth forum posting starting "I'm
going to build a new MMOG for 1 million players where everything is
simulated at the molecular level by a super physics engine", and
wanting to suggest a slightly more sensible way for people to get
started with building online worlds...
There's nothing not said previously on MD, although it pulls several
things together at once, so I figured it might be of interest to
some.
Adam
------------[ How to Build an MMOG... ]------------
By Adam Martin
Introduction
So, you've got some unique ideas that'll work really well, you've
got the commitment and skill, and you want to build your own MMOG
...but you're not entirely sure where to go next? This isn't a
step-by-step guide to building an MMOG (do you have the next 6
months free?) but instead a mixture of specific advice, gotchas, and
general pointers that might help you.
I work for one of the MMOG technology companies - we build
development systems and server engines to drive MMOGs, and to speed
up development. We often get asked for advice on "where to start"
with building a new MMOG, and sadly there are precious few resources
we can refer people to. Certainly I've not yet found a good guide to
building MMOG's anywhere.
This article is split into three major sections, each aimed at a
particular type of reader. First of all, we have one for individuals
and enthusiasts. This is where most of us lie -- people who're hooked
on MMOG's in one form or another (either playing them or inventing
them) but who aren't employed by a commercial games studio to
actually produce the things.
The second section is aimed at small teams, usually a bunch of
friends who have been working in other industries (typically as
developers) for a decade or so and include a few highly skilled
programmers. It should be just as relevant for groups of recent
Computer Science graduates (or "soon-to-be" graduates) in a similar
position, of which there are quite a lot entering the games
industry.
Finally, there's a section devoted to producers at commercial games
studios, looking to make an upcoming title into an MMOG. I'm
including this to give everyone else a strong flavour of what it's
like to build an MMOG from that perspective (for instance, the
presence of large sums of money and skilled staff make a big
difference!).
Enthusiasts
The first thing I want to say is that I do know, personally,
individuals who have created whole new MMOG's from scratch -- almost
without anyone else -- and ended up with tens of thousands of
subscribers; it IS possible.
It's also about as wise as head-butting yourself into
unconsciousness, and more often than not will produce the kind of
game you'd expect from someone who liked to reshape their forehead
against a brick-wall. The main problem is that you're attempting to
build something akin to a 500 foot suspension bridge with no power
tools, no labour, just the output of your own little workshop (based
in your garage/spare bedroom). Usually the only way to stand a
snowball's chance in hell of releasing the game is to make it almost
entirely crap (...and this is what the successes I've known had to
do initially).
In practical terms, you may be the longest-serving player on every
one of the top ten MMOG's, but you have probably have no direct real
experience of building one, and "walking the walk" is a heck of a
lot harder than "talking the talk". There's lots of things you know,
but that doesn't mean you'll remember (or have the willpower) to
actually implement them all. There's also some really important
things you don't know -- like whether you have the strength of
willpower to develop an MMOG (which is about as exhausting and
painful as giving birth to centuplets (100 babies)...). IMHO, the
best way to find out is to do a MUD first. You can't just walk into
Ferrari and get a job as lead designer of their next major car -- you
have to work your way up first, building up experience on smaller
projects. Similarly, a MUD is much quicker, easier and cheaper to
build than an MMOG. Note that many many people who start MUD's find
they can't even get a MUD finished -- better to find this out before
you commit your life to an MMOG. You will also learn a heck of a lot
about managing people (players) which you've probably experienced a
lot of (and have good ideas about) but haven't yet had a chance to
try out.
Another place to start is on the WorldForge projects -- although you
should be aware that you won't get much (if any) practice with real
games there for some years to come; you can learn a lot about the
design, technologies, implementation, etc.
Small Teams
For small teams trying to get started in the mainstream games
industry -- either to produce a portfolio to get employed by a big
studio, or trying to make a living as an indie -- the advice is
nearly always the same: make an innovative but fairly simple game
that you can complete inside 3 months. Everything you do should be
judged by KISS (Keep It Simple, Stupid!), since so few games that
are started ever get finished, even by really good teams.
Most importantly of all, don't even dream of trying to out-do the
current games industry. If you dream of writing a new 3D engine that
makes Doom 3 look dull, wait until you're part of a team of 20 or
more full-time fully funded developers -- not when you're starting
from scratch.
The advice for making MMOG's is quite similar, with some interesting
differences that actually make an MMOG a much more attractive choice
for your first game. An MMOG is a service, not a product, which has
several immediate consequences: firstly, every player costs you
money (even if you don't provide ANY customer support; think
bandwidth, think BIG costs), which tends to focus the mind!
Secondly, people don't just play your game a few times then stop --
they potentially will play every day forever, with new experiences
each time; you can keep changing the game as much as you like whilst
people play it. Thirdly, a large number of players is a source of
income EVEN IF they have no money or would refuse to subscribe (and
if any of them do subscribe, you have a stable revenue stream -
retail games tend to make 90% of their sales in the first 3 months
after launch, and then almost nothing afterwards): e.g. (this
certainly isn't the only source of revenue) you can make enough
advertising revenue off the backs of 50k regular players to be very
rich indeed.
This gives you a unique opportunity: make your game and get a few
hundred (yes!) people playing it, don't aim for any more than that
(be realistic). Trust me, you'll be very very appreciative when the
server crashes, or the support requests come flooding in, that it's
"only" 500 people...Then, *once it's complete*, you can actually
continue to extend and improve the game, and attract more people. 12
months after your initial launch, you could easily have gone up to
5k players (nb: you want to keep the increase gradual; it should be
slow enough that by the time you need extra money to fund costs
(both your own living expenses and the bandwidth/hosting/support)
you have had time to get some revenue streams in place). Once you've
got your billing in place, you can accelerate, and the "simple first
MMOG" that you started for a few hundred players can -- in just a few
years -- miraculously morph into "the best MMOG in the world...ever"
that you dreamed of.
You'll be following in a great tradition:
"The game design was done for 300. Nine months or so before ship,
we got the order from on high to make more players fit into the
game" - Raph Koster; Ultima Online
"...the path that Mythic took to success -- launch small games with
lower margins until you have the technology to do something like
DAoC"
"Most of these guys [publishers of MMOG's] do not know how to
think small. TSO could have been done for much, much less, and if
so, would have been wildly successful." - Damion Schubert;
Meridian 59, Ultima Online, Shadowbane
However, there is also something else that it is essential for small
teams to bear in mind: no "small team" is ever going to be big
enough to write a real MMOG. Five-person teams regularly produce
very slick polished single-player (or small multiplayer) first-games
in 3-4 months; when you bear in mind that in an MMOG you have to do
all that work just for the client side, and then you've still got
ALL the server-side work to do, PLUS all the time it takes to
integrate the two (and don't be fooled into thinking that is
anything other than a very long job).
The secret is licensing; license everything you can get your hands
on that will reduce your development time and let you concentrate on
the bits you most need first-hand experience of. For starters, this
usually means avoiding writing ANY networking code (there are half a
dozen good network layers specifically designed for games
development; use them!). Equally you usually want to avoid the more
esoteric and specialized parts of server development (you're games
developers, right? Not DBA's, nor Distributed Systems engineers,
etc...). Of the handful of companies that license MMOG server
engines, several -- including the one I work for -- offer zero-cost
licenses for small teams / independent developers / academic
research. Use them! However, be very careful: the market for MMOG
servers is far from mature, and only about 25% of the licensable
MMOG server engines are worth using at all -- in the long run the
rest may cost you more time than they save. You need to do some
research (do these people seem to actually know what they're doing?)
before adopting someone else's technology.
Commercial Games Studios
Whilst the previous sections contain good advice that many
commercial studios would benefit from, it's a whole different ball
game. Commercial companies have something that other games
development groups don't: money. Generally lots of it, too.
Careful management and planning of an MMOG usually starts by looking
at five major aspects:
* Planning
* Design
* Development
* Customer Service
* Experience
At the planning stage, commercial studios need to produce a
watertight financial plan. This can be a horrific experience:
working with huge unknown and almost inestimable factors, you have
to calculate precise figures for everything, to within small
tolerances (overall approximately to the nearest 1%). If you stick a
finger in the air and just guess, you'll have a spurious financial
plan with no relation to reality. Then, halfway through, you (and
possibly your entire project) get fired (or cancelled) for not
meeting your original targets...
This is inevitable because of the way that funding works; funding in
the games industry is no different at all to funding in the wider
world, except that usually the investors specialise in games (much
as VC's often specialise in a particular industry, only more
so). Everything you've ever heard about the difficulty of getting
funding for a startup comes to bear at this point. Fundamentally,
financial plans have to be precise because you're asking someone
else to risk millions of dollars on a project they will probably
have nothing to do with -- so they need really accurate projections
from experts (you and your team) to be able to make up their
mind. Financial planning is hard; getting this part wrong leads to
many of the "bizarre" public decisions -- like cancelling a game
just before it's finished, even though it looked set to do really
well (there is often no spare money set aside beyond what was
originally planned for!).
Design is much closer to traditional games development. As most
serious MMOG players know, however, there are a great many special
considerations for gameplay in MMOG's -- griefing, attracting all of
Bartle's suits, destructive cheats, community formation, etc. It's
somewhat depressing that the earliest MMOG's (e.g. UO) were careful
to employ people with formidable relevant experience (e.g. the
recruitment of several LegendMUD people to Origin), and yet so many
modern MMOG's (any number greater than zero is large for this
particular brand of foolishness!) by commercial studios fall by the
wayside because of apparently elemental mistakes. Fortunately, we're
seeing the rise and rise of small specialist consultancies, mostly
formed of old-hands from the MUD and (less often) MMOG industries;
these can only flourish if games companies are being wise enough to
employ them for their expert knowledge, so the signs are good that
elementary design mistakes should mostly fade away in the coming
years.
Unfortunately, when it comes to Development, commercial studios have
so far been very reluctant to follow the advice given earlier to
small teams -- start small, grow big. The nearest we've really seen
is "start small with a big staff, grow nowhere". If your game is too
small but requires too large of a team to support, then you will
spend all of your money treading water - supporting the game without
improving it drastically or having the cash to really do a new
project. The good news is that you'll never die, the bad news is
that you never seem to grow.
Customer Service becomes a major issue when you expect from the
start to be charging money. It's an even bigger issue when the
number of customers you expect will require a huge team of full-time
CS reps (usually a large multiple of the total number of development
staff who wrote the game in the first place). I recommend Jessica
Mulligan's recent book - "Developing Online Games: An Insider's
Guide" (ISBN:1592730000) -- which goes into considerable detail on
the planning and execution of an MMOG, particularly of Customer
Service. In the words of Gordon Walton (The Sims Online), "If you
master this one element, you would have a competitive advantage over
all online games today...no current offering is the benchmark".
Given that there are 3500 new games developed each year, of which
perhaps 10 are MMOG's, it's rather difficult to find experienced
personnel/staff within the market. The main options are to borrow
expertise by hiring consultancies or partnering with a more
knowledgeable company, or to look for "complementary" experience in
completely unrelated industries -- although this is often avoided
due to the problems (whether perceived or genuine) of integrating
"outsiders". Typically the biggest problem here is the mandatory
reduction in salary; although in some cases that can be offset by
royalties on the finished game, this doesn't seem to happen much for
MMOG's. The other approach, of course, is to find someone who has
the potential to become an expert, and train them up. Usually by
sacrificing your first game for their experience, and then firing
them so they can be snapped up by a competitor (at least, that's the
way that EA seems to do things...).
If you want to make a big splash, starting your game with tens of
thousands of customers, the most important thing is to have
incredibly good project management. A very smart move is to visit a
head-hunting agency and hire a top-notch "Programme Manager"
(preferably with experience on international corporate projects with
100-200 staff) and similarly hire an expert in Customer Service with
a background in luxury goods companies (NOT the games
industry). There are thousands of people in the world who know this
stuff *on this scale* better than anyone in your company. Making an
MMOG work as a project and as a service is orders of magnitude more
complex than producing a single-player game, and requires little in
the way of games-industry-specific knowledge.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list