MUSHcode: OOP in Real Time

MUSHcode is the internal programming language of MUSHes, multi-user text environments that focus mostly on social interaction and player building and coding--essentially, text-based predecessors of Second Life and the like. MUSHcode has all the normal features of an object-oriented language, includimg object classes, inherited attributes, and so on, but with the addition of a few odd twists: everything (including the programmers) is arranged in a virtual grid, code is entirely contained within the attributes of objects, and everything is happening in real time.  Heavy use of special characters and lack of formatting also make MUSHcode notoriously hard to read, and it has on occasion (I'm not making this up) been mistaken for line noise (that is, the random characters that, in the days when dinosaurs roamed the internet, appeared in a text stream as a result of a bad modem connection, probably on the phone line between your computer and the UNIX server at whatever university you were attending at the time).

The purpose of MUSHcode is to allow administrators ("wizards") and players to build the structure that players experience, by creating a grid of "rooms" linked together by "exits", and filled with other objects, including the players' avatars. These grids tend to be 2D or 3D representations of realistic spaces, but there's no reason they have to be. They give MUSHcode the first of its peculair features: all of the objects have spatial relationships to one another, and any object interacts most easily with objects that are nearby (in the same room).

The second pecular feature of MUSHcode is that players write code, not by the traditional method of listing commands in a text file, but by creating attributes of the various objects in the shared environment, including the rooms, exits, and players. A program is run by triggering an attribute, and that attribute can then trigger other attributes on its own or other objects, or (by using function calls) read data or user-defined functions from other attributes. Objects and attributes created by different players can interact, though this involves setting permissions for who can use or look at what, a necessity that opens up an endlessly entertaining variety of security problems. MUSHcode "programs" are backed up or ported to other MUSHes by "decompiling" the objects in question--that is, creating a list of the commands necessry to reconstruct those objects (and yes, you can edit these scripts, much as you would a traditional program, but that's not the usual means of doing things, since editing and debugging require altering one attribute at a time, rather than recreating the entire object), though full reconstruction of virtual spaces will also require linking exits manually.

The final peculiar feature of MUSHcode--and to me, the most interesting, because it poses some of the same challenges as working with dynamic databases--is that everything goes on in real time, with objects' interacting with players and other players' objects. This creates some unique challenges: for example, if a MUSHcode program creates or modifies a variable (that is, an attribute that's being used as a variable), and then the same program needs to make use of that variable, the programmer actually needs to code in a delay (the exact length of which requires some guesswork, and trial and error, and depends on server load), or the command in question will execute before the MUSH database has been updated. This is, in fact, so annoying, that most MUSHcoders rely as much as possible on function calls, because they execute completely before the program moves on to the next function or command. Indeed, later versions of MUSHcode even include the SETQ() function, which returns no output at all, but instead sets a value in a temporary register, which can then be retrieved by another function--thus, all the action happens in memory, with register values never being permanently recorded in the database.