How Metaplace Works
Back when we launched the original Areae website, we said that we wanted to make virtual worlds work the way the Web does. Looking back, I think a lot of people assumed we meant that sort of metaphorically. But in fact, we meant it very literally.
The core of Metaplace is something we call MetaMarkup. It’s a markup language designed to serve as a game equivalent to HTML. We use this as the network protocol for servers talking to clients. It looks like this:
[UI_IMAGE]|0|-1|my picture|0|0|100|100|0
As you can see, this isn’t XML or other markup standards; that’s just because XML was too big, and other standards weren’t really suited to what we were trying to accomplish. MetaMarkup is designed to work in real-time, so it’s meant for very fast parsing. Because of this, every tag is rigidly formatted. You can write MetaMarkup by hand, if you want, but usually, you can just let tools generate it. It can also be translated back and forth to XML quite easily.
The example I gave puts a picture on the UI, at the upper left corner. If your client can handle pictures, that is. You see, MetaMarkup is an open standard. Anyone can write a client for it. We figure, the more clients the merrier.
A game writer can’t assume that every platform out there will render every possible bit of MetaMarkup. Say you write a text-only client (something perfectly possible). That [UI_IMAGE] tag would get ignored. Or maybe the client would say “I drew ‘my picture’” just like a text web browser draws the ‘alt’ text for an image on the web.
This is why our clients are so small – every asset is fetched via the web, and clients consist mostly of a renderer, a tag parser, a simple HTTP browser, and the network connection. There aren’t very many assumptions in a client.
The server is also pretty assumption-free. There’s a lot of stuff that we know people will need to build worlds of various sorts. A 3d space, pathfinding, terrain, collision, physics, web services – we call all those things “platform services.” A server consists of these things, and little else – and if you aren’t using them, they aren’t taking up any cycles. So you can have a barebones world for something like a puzzle game without using much more than the basic terrain grid.
This means the server has no game logic in it at all. You write all that stuff in MetaScript, which is a sandboxed, event-driven version of Lua. This allows two worlds to have radically different sorts of rules to them.
Since rules can be hard to write, we offer the ability to create stylesheets and modules; these are basically collections of art, scripts, and other data, that you can easily import into a world, or use as a starting point. This is how the “Create World Wizard” works -- you may have seen in some of the press coverage. It lets you start from a stylesheet that happens to be a fully functional world.
So – does it work like the Web? Well, look at it this way: MetaMarkup is HTML. Clients are like browsers. The server is like Apache. The scripting is like CGI. The modules and stylesheets are like CSS and stylesheets. And Metaplace.com is like the Google/Yahoo/YouTube that sits on top of it all.
Over the next few months, we plan to dive into somewhat more depths on each of these pieces, giving those of you not yet in the closed testing the chance to learn more about the platform. In the meantime – we love seeing the discussions on the various sites out there. You’re already blowing our mind with the ideas you’re coming up with. We can’t wait to let you loose on the tools.
Raph Koster
Founder
Previous Post | 15 Comments | Next Post
Posted on Friday, October 5th, 2007 at 8:46 AM PDT
Reader Comments
Gary Crook said:
on Friday, October 5th, 2007 at 9:03 AM PDT:
Andrew M. Kasper said:
When you say that "XML was too big," did you mean that it was too unweildly for a beginner to use? Or is that assertion related to your later comment that MetaMarkup is designed for fast parsing?
on Friday, October 5th, 2007 at 9:40 AM PDT:
m3mnoch said:
also, the rate at which the client gets tags? wow. remember we're talking about the network traffic for an mmo here. it needs to be fast to parse and tight to deliver.
trust me. since i'm a huge fan of xml, when we were evaluating our options, i was pushing big-time on the standards-based document format. i quickly changed my mind in the brutal face of practicality, tho.
that being said, however, the web api is all about xml....
m3mnoch.
on Friday, October 5th, 2007 at 9:53 AM PDT:
Naereus said:
Also, does the quote below mean that you have already let in the initial group(s) of applicants?
..."giving those of you not yet in the closed testing the chance to learn more about the platform"...
on Friday, October 5th, 2007 at 9:56 AM PDT:
m3mnoch said:
and more over here:
http://www.rlmmo.com/viewforum.php?f=20
m3mnoch.
on Friday, October 5th, 2007 at 10:49 AM PDT:
NinjaInhibitor said:
on Friday, October 5th, 2007 at 11:02 AM PDT:
18Rabbit said:
Even with a condensed format it sounds like the amount of network traffic you will have with a large game will be pretty high since every object is a URL look up. I think moving away from XML for communication is a good choice. Are you able to store the same metadata in the condensed format or just a subset of standard XML attributes?
on Friday, October 5th, 2007 at 11:17 AM PDT:
chooseareality said:
Looking at that one line I am guessing that it will be possible to preload graphics and other resources so the game won't hesitate while downloading?
on Friday, October 5th, 2007 at 12:29 PM PDT:
chooseareality said:
on Friday, October 5th, 2007 at 1:56 PM PDT:
DamianoV said:
on Friday, October 5th, 2007 at 2:11 PM PDT:
Dorian said:
on Friday, October 5th, 2007 at 2:19 PM PDT:
Over00 said:
on Friday, October 5th, 2007 at 3:36 PM PDT:
Scott - Pair O' Dice Games said:
Seems that, by the description above, a JavaScript client wouldn't be out of the question would it?


