The session was titled "postmortem" but, since it is impossible to postmortem a product that is still in alpha, Raph Koster retitled the session accordingly. The theme for GDC this year is democratization of user content, he said. That's why we're here even though we're done yet.

Why reinvent MMOs? They are just too hard to make now. Each is a custom-crafted moon-shoot. They are poorly integrated with the rest of the internet. They kind of work like Prodigy. We haven't had anything really different since 1978. We're making MUD 203 instead of MUD 2. The consequences: they are getting insanely expensive to build. You have to get it perfect at launch since it's so expensive. We keep reinventing the wheel and these lead to publisher pressure to "make it like WoW."

Today, MMOs are monolithic giant servers. All the services are contained within the server. They have complex server cluster architectures and a tight dependency between client and server. These architectures are really complicated, monolithic, and not very reusable. There are virtually no successful reuses of MMO servers. In the past, you had a client like, say telnet, and a server, which had, say, rooms. And today you have a multiplexing user server architecture to manage different world servers, with a runtime DB server, often a global chat server, and some kind of process manager to make sure they are all running, including web bridges, authorization systems, RMT, metadata, and so forth. Furthermore, you need all of it per shard.

The alternative is a system that is low cost to develop for, scalable, robust and future proof, modular, and reusable. One of these already exists. It's called the web. The web works today because it uses an open markup language (HTML), a reference browser (Mozilla), an assumption-free server (Apache, etc.), scripted behaviors (CGI), templated content (CSS), distributed, segmented routing (DNS), and rich in metadata (e.g. Google). The question is, if you were trying to make an MMO that got you these benefits, what would it look like. There is also a philosophical difference. This is not about Snow Crash. Snow Crash is a lie. We are putting virtual worlds on the web, not the web in a virtual world. We are leveraging technology from the game industry that the web doesn't know how to do. Virtual worlds are going to be first-class citizens on the web.

Now let's do a demo. If it blows up please forgive us. Here's a multiuser MMO in a webpage on flash. Everybody looks like one avatar because customization isn't done yet. The nice thing about running in a browser. Live demonstration of a translation via Babelfish. Scripting in Lua. Full, realtime web integration. Demonstration of youtube video in the client. A Metaplace server is a web server. Every object has a URL. You can browse to it outside the world, or interact with it inside the world. And any object in the world can interact with any object on the internet. A server can also be a client of another world.

Let's show something else. Here's a puzzle game, written in the same client, in a different kind of environment. The server makes no assumptions about what you are building. We're trying to be client-agnostic. It's based on markup language. The client architecture will be open standard and can be written in C++, Java, Lua, Javascript, BASIC on any platform. Here's a different world. Everything is fetched by HTTP and not streamed by some special format. Demo of a space shooter game. What we've shown you is all 2D, but it could scale down to text or up to 3D. It is representation agnostic. You could make a client that was feeding out just RSS, or maybe being an ad banner. Really whatever you want, sitting on a webpage anywhere. You could write on in OpenGL, and so on.

Demo of my meta. Every metaplace world exists in a network . You can walk from one to any other. You can get presence feeds from anyone online. You can teleport to that world wherever it happens to be running. All of these things are web services and anyone can plug into it in any way. Every world gets its own profile page. Ok, enough demo.

How metaplace was built. We started from crazy simple and did crazy loops over and over and over again. Web time is different from game time... the web people watch us and think we're going really slow, but the game people think we're going really quickly. By decoupling components, we can iterate on one and then swap it out. The bottom layer of metaplace is literally a markup language. We started working against a text mud server, hand writing the tags into a text file and then writing a client that would parse those tags. Then it evolved. Soon we move to multiple formats for tags: GML (game markup language).

Clients are hard to make today because we pack them with graphics and try to make them really smart. Our clients are stupid, you can write them on anything at all. A client just needs a few basic things. The stupid client lesson has been really powerful for us. So much of our work goes to representation these days. Having stupid clients means you can be agnostic to clients. You get a virtual world that's multiheaded: you can interact with it on any device at all. Developing clients in parallel was really good.

Comments (2) | Post a Comment