My quest for MOO
If you know me well, you know that I love envisioning the perfect MOO. I have had many insane plans for MOO servers and cores; I keep trying to settle for LambdaMOO, but it just reeks of how old it is.
What is a MOO
At the heart of it, a MOO is a multi-user environment where the users have all constructed objects. These objects interact with eachother and players programatically. This allows players to be creative in a way other mediums can't allow: collaborative, interactive user experience.
Sure, the traditional game allows for interaction. Multi-player games allow for a collaborative experience. The difference is that a MOO is a sandbox where not only can anyone create an environment and props and actors to fill it, but the interactions (especially unexpected interactions) between their creations and other users and other users' creations is emergent. An emergent, collaborative, interactive environment. I can't really think of anything else I'd rather participate in.
Modern attempts at multi-user, collaborative environments (read: virtual worlds) have made what is, in my opinion, a grave error: displaying the game world visually in three dimensions. Of course, it has the great benefit of widening the user base, but at the cost of immersion. You might think I've got my head on backward: how can a visual, 3d experience be less immersive than text? Here is your answer: How detailed and complete of an experience can the average user author given a few hours of time in each environment? How long does it take to make even a rudimetary model of an object compared to describing it in sufficient textual detail? Far too long. The price of 3d is sparse, shallow environments. One could argue that the wider user base makes up for the decreased creative output of each individual member. To an extent, that is true. Second Life has a large and at times very rich environment, but limiting creation to the highly skilled few, and using the masses to fill the gap results in a very skewed, and in my opinion, inferior experience. For instance, the majority of content in these worlds is fashion items, a large portion of the remainder is sexual. If I want a "hand stiched, black canvas jacket with a red maple leaf logo embroidered on it" in a textual environment, even the most novice user can author one, in one of these virtual worlds it requires the skills of a modeler and a texture painter. Too much creative ability is wasted on creating even the most rudimentary of content, so (for the most part) richer content is never made. But that's enough ranting.
What's wrong with LambdaMOO?
LambdaMOO was excellent for its time, but its time has passed. Technologies have improved and there are new obstacles to face.
- LambdaMOO can't scale horizontally (across CPUs or across hosts). If I want to build a game world with thousands upon thousands of reproducing plants and animals, I need lots of resources. The modern computing era has plenty to offer, but to get to them requires distribution. Multi-core processors, inexpensive clusters of interconnected machines. Lambda can't take advantage of them.
- The Lambda MOO programming language was developed before the modern interpreted programming language, it just isn't as snappy or nice as, say Python or Ruby.
How not to fix it:
For a while I wanted to re-implement LambdaMOO on top of Python, some people have started and gotten quite far. I took their efforts a little farther, but got stuck at host-level distribution. You can re-write the server and link in any modern interpreted language, but you lock users into whatever language you've picked and (depending on chosen language, of course) you can only scale across CPUs, not across hosts.
My new plan:
If we are to distribute a MOO over a network, we can use a protocol that doesn't depend on language. The benefits of this are that objects could live on different servers and be written in different languages. Different implementations of the protocol can be created, those that perform better will enjoy wider use, it will be possible to write a server that is especially good at certain kinds of objects, etc. This introduces latency and overhead (looking at the objects in a room could become hundreds of network requests), but I think that with modern networks, latency is low enough for the sort of interaction that occurs in MOOs.
The only problem is agreeing upon a sufficiently advanced protocol, one that is easy to implement, reduces overhead, yet robust enough to allow for the emergence of unforseen kinds of content.
I believe that HTTP, not IP should be the basis of that protocol. Why HTTP? HTTP is almost the definition of robustness. You can GET or PUT data, you've got MIME for intelligently managing different kinds of information, metadata for caching, redirection, load balancing. You can do SSL, you've got built-in authentication methods, streaming media. It's great. Besides, you've got a bunch of military-grade, bullet-proof implementations on the shelf, ready to go.
The data format can be just about anything, but if we want it to be robust and fast, I think JSON is the way to go. A RESTful JSON MOO distributed over HTTP.
The new problem:
This, at first appears to leave too much up in the air, we have no defined standard for representing a room or an object or how to get two to interact. How can my object tell if it's stored in the room, how does the room know which objects are stored in it?
The answer is liberating: it doesn't really matter as long as it works. For one, even other coders can't see your internal implementation, just the external interface. It doesn't have to be that pretty. Secondly, the MOO environment will be tiny at first, the content will be sparse. This gives us loads of room on the performance and robustness fronts, we can come back to these problems later.
I'm going to start writing a MOO core using this philosophy, probably in Python possibly leveraging the power of Apache via mod_python. I'll focus on getting things to just work. There is plenty of room for more elegant solutions to form later.