Oni

After finishing the parser for Aki which is a LambdaMOO port in Go I started thinking (again). During development of Aki I always tried to put a lot of burden on Go itself by utilizing go-routines and channels for my fork and suspend needs and it worked great. Go is a great platform to port LambdaMOO but only if you indeed implement the LambdaMOO VM too (which involves quite a bit of infrastructure like tokenizer, parser, interpreter, VM and a whole lot of other stuff).

LambdaMOO

There are a few things to LambdaMOO that make it special. First, it’s object oriented and very much like Smalltalk that you have an image (the database) and the runtime (the VM or moo executable). Apart from that, it also has sort of native support for task based execution. You can fork tasks, suspend tasks and even find out what tasks are running and kill them remotely. On top of that, it has a whole authorization engine.

LambdaMOO has all these features to support a few important use-cases:

• The server must keep on running while game releated features are added
• There can be multiple people programming different or the same game objects
• Multiple users can be connected and using the server while it is being programmed
• When the server dies, the state will be restored on next reboot

I think LambdaMOO can even support suspending tasks in the middle of a reboot but I’m not sure about that and it’s not really something that is planned for Oni soon.

One of the best things of LambdaMOO is that you can program it while it’s flying. In that aspect, it feels very much like programming a Smalltalk environment but LambdaMOO is task based too. It has notions of suspend and fork. In Go, keeping it flying with all current tasks and such is only possible if you implement your custom VM on top of Go (or maybe you can get really intimate with the Go scheduler). And even though I had great fun implementing that LambdaMOO VM or parts of it on top of various languages and runtimes (Python, .NET (C#) and Go) there was always this thought that there might be an easier way.

Oni

Enter Erlang, which seems like it was made for building LambdaMOO servers. It supports our number one problem case: hotloading code out of the box (mostly thanks to its functional nature). Also it has the kind of task based scheduler we want built in to the language with a bunch of builtin functions to boot. It has awesome batteries like ETS and Mnesia and of course the OTP framework to build on.

Although Oni is still lacking in a lot of ways it has one thing that LambdaMOO doesn’t have: a builtin action queue (aq). The aq is a concept from HellMOO where you have actions that span time. If you try to execute another action while you are already doing something it will be queued and executed when you finish what you are doing. This is a great concept because it allows for a lot of detail while programming the game verbs.

So instead of someone being in a particular room or not, you can have someone that starts to exit the room. He or she has to open a door for this so it may take 2 or 3 seconds. While this is going on another player might walk into the room. In a lot of games you either see someone in the room or you don’t. But in HellMOO it might like somewhat like this (the other player is Mistress):

> west
You wade east through the swamp.

[In the Muck] 10:34pm
You in the middle of a yucky swamp.
Mistress is here, wading to the west.

So you can actually see the other player moving to the other room. This works with taking stuff, crafting, interacting with players and NPC’s and basically everything you can dream of that takes some time. The amount of detail this allows is what sets HellMOO (and other games built on HellCore like Wayfar) apart from the other MUDs and MOOs. In HellMOO this is built on top of the LambdaMOO VM (with a few tweaks) but Oni has this concept natively.

If you want to find out current progress, check the Oni source.

On Smalltalk

I deliberately linked to Pharo and not smalltalk.org because frankly, that is not a really fun place although it has some nice information now and then. Squeak is decent too. To be honest, I haven’t dabbled in Smalltalk for a long time. It’s a great environment and a great philosophy but I feel the whole community as a whole has become an island. Anyway, if you haven’t tried out Smalltalk, give it a go. It’s pretty awesome and has a lot of great ideas. Also, be sure to look into the implementation too.

Even if you don’t intend to use Smalltalk itself. The Blue Book will definately make you a better programmer if you haven’t read it already.