Categories
games design massively multiplayer networking programming

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

I reserve the right to come back and edit this to make it ten once I’ve had more sleep and can remember two more :)…

Categories
amusing computer games conferences photos web 2.0

Sulka gets Angry…

Sulka Haro’s keynote at AGDC07. What happens when a Lead Designer gets heckled, and things turn nasty…

Categories
facebook web 2.0

Internet as Platform – Marc Andreessen is wrong?

“Often wrong, never in doubt” is the tagline on Marc Andreessen’s blog. With a recent post of his, on the “three kinds of platforms you meet on the internet”, I think the first part of that tagline is ringing true :P – Marc is talking nonsense with his claims that “[a Level 3 platform is] much better for the developer [than a Level 2 one]”

It’s great that he’s trying to “disentangle and examine the topic of Internet Platform”, but … seriously, there are good analyses and bad analyses, and this one rings jarringly false to me.

To save you reading the whole thing initially, here’s Andrew Chen’s summary:

The fastest summary:

* A Level 1 platform’s apps run elsewhere, and call into the platform via a web services API to draw on data and services — this is how Flickr does it.

* A Level 2 platform’s apps run elsewhere, but inject functionality into the platform via a plug-in API — this is how Facebook does it. Most likely, a Level 2 platform’s apps also call into the platform via a web services API to draw on data and services.

* A Level 3 platform’s apps run inside the platform itself — the platform provides the “runtime environment” within which the app’s code runs.

And which companies are working on Level 3 platforms, other than Marc’s Ning?

* Salesforce.com

* SecondLife

* Amazon (through AWS)

* Akamai

Which is fine, but I need to add Marc’s statement that

I call these Internet platform models “levels”, because as you go from Level 1 to Level 2 to Level 3, as I will explain, each kind of platform is harder to build, but much better for the developer. Further, as I will also explain, each level typically supersets the levels below.

  1. Are they monotonically harder to build?
    • Yes
  2. Do they typically superset the levels below?
    • Yes
  3. Are they “much better for the developer”?
    • Hell no

Marc has written a very programmer-centric post here. He’s identified that, technically speaking, the different classes of platform are “bigger” than each other and obey a transitive, non-commutative, superset relationship. Natural consequences of that are the first two items I hilight in his claims above.

But he’s then made the mistake of conflating this with *entirely unsubstantiated* business concepts of “better”. As the developer of one of these “level 3” platforms he contends are “best”, it’s no wonder that he wants to believe that it is a *logical* conclusion that the business advantage comes forth just as the technical conclusions are logically sound. But wanting to believing a thing doesn’t make it true. And whilst I genuinely believe he could have provided a decent argument that makes it true *for his business*, I think it’s not only an illogical claim, but actually false, in the general case.

Specifically, I would like to know how a level 3 is “better for the developer” than a level 2?

And I’m sorry, but I’m going to stop calling them “levels”; they are only levels in a programming sense, not in a business sense, and to name them that way implies something is globally true that only applies to one aspect of them.

Going from class 2 to class 3, you:

  1. have to do more work
  2. pay more in ongoing costs
  3. provide no appreciable benefit to any user who is also a competent developer

To give an example of a valid way of making the “3 beats 2” argument work is that you could argue that if your target-market is people who can’t write code at all then the third point above is irrelevant, and that actually you ARE adding value.

But for all the other users – and, let’s be fair here, Marc chooses *Facebook* as one of his examples of class TWO, not three; Facebook, where pretty much any idiot can (and does) write a facebook app within a matter of days or hours – point three above means you aren’t adding any value at all by moving to class 3.

Hosting is incredibly cheap these days, and developing basic functionality is incredibly easy – as mentioned, look at the proliferation of non-programmers and what they’ve done on FB. Reducing the dev cost and hosting cost over and above a level 2 platform seems to have very little actual point to it.

And, worst of all, with a level 3 platform, you make it into an “all-or-nothing” proposal, completely about-face from what has driven the proliferation of Web 2.0. You create a walled-garden of proprietaryness, where every user is dependent upon your ongoing existence. Facebook expressly does not do this.

Even when people use your service because they have no choice but to limit themselves to your walled-garden, you will scare away vast swathes of the best users because they will be rightly suspicious that yours is a proprietary platform that they cannot exist without.

I would rather contend that class 2 apps are the best of all. Why? Because:

If I develop an FB app, and FB disappears tomorrow, I can still run my app all over the web with almost literally no changes to code.

On the other hand (and I know many examples of where this has prevented people from using SL, even though LL have taken many steps to blur this and insulate people from the problem, including open-sourcing pretty much everything)

If I develop something in SL, and Linden implodes tomorrow … I lose my entire ability to conduct business.

I think it’s telling that even in Marc’s post it’s clear he was struggling to find examples of class 3 platforms. I think it’s disingenuous to even put SL in that category, since it is (as noted) moving so strongly and rapidly towards being something different – they’re even talking about allowing anyone to run the servers themselves. If they’re a poster-child for level 3 being “much better for the developer”, then why are they running full-tilt for becoming something that would only fit in his level 2?