Metaplace! That's what!

Build a virtual apartment and put it on your website. Work with friends to make a huge MMORPG. Share your puzzle game with friends. We have a vision: to let you build anything, and play everything, from anywhere. Eventually, anyway. We have to finish first.

Latest Forum Posts

Diehvel on Alpha Closed?

July 24th, 2008 at 8:54 AM PDT
3 Replies, 29 Views

DarknessFalls on Alpha Closed?

July 24th, 2008 at 8:49 AM PDT
3 Replies, 29 Views

Diehvel on HELLO RED NAMES

July 24th, 2008 at 8:42 AM PDT
12 Replies, 127 Views
MetaForums
Media Info

Feel like writing about Metaplace.com on your own site? Maybe you're a journalist? Here you'll find all sorts of materials that might make that easier: fact sheets, screenshots, logos and other artwork, and all the other handy stuff that goes in a Media Kit. Go nuts -- you've got blanket permission to use any of this stuff!

Contact Info
Areae, Inc.
11770 Bernardo Plaza Court
Suite 101
San Diego, CA 92128
USA
Phone: 858-451-2700 Fax: 858-451-2722
For press enquiries, please email:
FAQ

Our motto is: build anything, play everything, from anywhere. Until now, virtual worlds have all worked like the closed online services from before the internet took off. They had custom clients talking to custom servers, and users couldn't do much of anything to change their experience. We're out to change all of that.

Metaplace is a next-generation virtual worlds platform designed to work the way the Web does. Instead of giant custom clients and huge downloads, Metaplace lets you play the same game on any platform that reads our open client standard. We supply a suite of tools so you can make worlds, and we host servers for you so that anyone can connect and play. And the client could be anywhere on the Web.

We hope there will be millions of worlds made with Metaplace. It could get hard to find stuff if we're right, so the portal lets you easily search, rate, review, and tag worlds and games of all sorts. You also get a user profile so you can find each other.

That's sort of the whole point. You should be able to stage up a massively multiplayer world with basic chat and a map you can build on in less than five minutes. It's that easy. Inherit a stylesheet -- puzzle game, or shooter, or chat world -- and off you go! Building maps and places is as easy as pasting in links from the Web, and dragging and dropping the pictures into your world.

What's more, you can link your world to someone else's world. Put a doorway in your virtual apartment that leads to Pirate Vs Ninja-land! Stick your world in a widget on your Facebook or MySpace profile. Mail it to a friend and they can log in with one click.

You can make pretty much any sort of game or world you want. You can decide whether it's massively multiplayer or not (it's MMO out of the box, but you can set it to a lower size if you want). You can decide whether to have physics or not, you can change the keymappings and the interface, the sort of stuff there is in the world, the maps... basically, it's all up to you. Game logic is written in MetaScript, which is based on Lua. So it's easy to make whatever kind of game or world that you want.

Metaplace will support everything from 2d overhead grids through first-person 3d. However, right now we only have clients that do 2d of various sorts, including grid view, 2d isometric, 2.5d heightfields, and so on. We expect to keep working on the 3d client support.

We speak Web fluently. Every world is a web server, and every object has a URL. You can script an object so that it feeds RSS, XML, or HTML to a browser. This lets you do things like high score tables, objects that email you, player profile pages right on the player -- whatever you want. Every object can also browse the Web: a chat bot can chatter headlines from an RSS feed, a newspaper with real headlines can sit on your virtual desk, game data could come from real world data... you get the idea. No more walled garden.

Metaplace is made by Areae, Inc. We're a team of veterans of the game and Web industries who thought that the current way of doing things was kinda slow and didn't give users like you enough control. Check out the company website to learn more about us!

Developer Blog

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:
Aha, more info. Thanks Raph - that certainly adds some clarity.
on Friday, October 5th, 2007 at 9:03 AM PDT:
Andrew M. Kasper said:
Great post: how exciting!

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:
both. xml is too file-size-weighty and it's too much overhead to parse. metamarkup is "split on line breaks. split on pipes. done." and it's about 1/4 the file size of xml.

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:
Can you share some of the ideas you and/or others have already come up for Metaplace usage?

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:
lots of crazy ideas and stuff in the forums here: http://metaplace.info/

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:
A bit more on XML vs MetaMarkup. Network protocols for games and other low-level binary protocols are essentially application specific compression schemes. All of the type and layout data for the packet stream lives in the definition of the protocol and is "well known" by both the client and the server. This allows them to communicate very efficiently, but not not very flexibly or robustly. XML based protocols like SOAP and XMLRPC are the opposite end of the spectrum of network protocols - all of the type and layout data is embedded in every message. This makes them very inefficient, but very flexible and robust. MetaMarkup is literally what the name says - it is a meta-protocol. The builtin types and layout of MetaMarkup behave like a game protocol - although text based, then once the stylesheet has been setup using this efficient baseline, application/game specific communication occurs between the client and server who now have a shared "well known" format for the game they are participating in.
on Friday, October 5th, 2007 at 11:02 AM PDT:
18Rabbit said:
Is Areae creating their own in house tools for editing MetaScript/MetaMarkup or are you planning on making plug-ins for other editors like Eclipse?
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:
That was great I have been waiting for something like that and I can see why XML might be a bit much for a client.

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:
I added an entry to www.metadeveloper.net with some guesses of my own as to what each of the parameters mean and a big fat disclaimer that I am guessing.
on Friday, October 5th, 2007 at 1:56 PM PDT:
DamianoV said:
It will be interesting to see the list of different messages/tags provided. Even more interesting will be the MetaScript examples...
on Friday, October 5th, 2007 at 2:11 PM PDT:
Dorian said:
Because Metaplace works like the web does, any assets that are downloaded dynamically can be cached for quick/pre-loading next time, similar to how asset caching on web pages works already.
on Friday, October 5th, 2007 at 2:19 PM PDT:
Over00 said:
Well, just out of curiosity. Any out of the box parsers for MetaMarkup or it's up to us to build them? Parsers for .NET, javascript, anything else?
on Friday, October 5th, 2007 at 3:36 PM PDT:
Scott - Pair O' Dice Games said:
I like the thought of running in a JavaScript client, or even a Flash client in-browser, attracting players without requiring them to install a stand-alone client.

Seems that, by the description above, a JavaScript client wouldn't be out of the question would it?
on Wednesday, October 10th, 2007 at 10:05 PM PDT:
nectarine said:
Even if a JavaScript client isn't possible, a browser embedded Java client most definitely would be possible. And from the sounds of it, it could be very light weight too. Woo!
on Friday, October 19th, 2007 at 9:55 PM PDT:
jessy said:
just curious if you could give a sense of why you didnt use an existing open XML standard like X3D? which is also mostly used as a file format/encoding. thanks! look forward to seeing the beta...
on Saturday, October 20th, 2007 at 1:11 PM PDT: