A MOO (MUD, object oriented[1]) is a text-based online virtual reality system to which multiple users (players) are connected at the same time.
The term MOO is used in two distinct, but related, senses. One is to refer to those programs descended from the original MOO server, and the other is to refer to any MUD that uses object oriented techniques to organize its database of objects, particularly if it does so in a similar fashion to the original MOO or its derivatives. Most of this article refers to the original MOO and its direct descendants, but see Non-Descendant MOOs for a list of MOO-like systems.
The original MOO server was authored by Stephen White, based on his experience from creating the programmable TinyMUCK system. There was additional later development and maintenance from LambdaMOO administrator, and former Xerox PARC employee, Pavel Curtis.
One of the most distinguishing features of a MOO is that its users can perform object oriented programming within the server, ultimately expanding and changing how the server behaves to everyone. Examples of such changes include authoring new rooms and objects, creating new generic objects for others to use, and changing the way the MOO interface operates. The programming language used for extension is the MOO programming language, and many MOOs feature convenient libraries of verbs that can be used by programmers in their coding known as Utilities. The MOO programming language is a domain-specific programming language.
Contents |
MOOs are network accessible, multi-user, programmable, interactive systems well-suited to the construction of text-based adventure games, conferencing systems, and other collaborative software. Their most common use, however, is as multi-participant, low-bandwidth virtual realities. They are often used in academic environments for distance education or collaboration such as Diversity University; but others are primarily social in nature, or used for role-playing games (RPGs), or simply to take advantage of the programming possibilities.
Most commonly, MOOs are connected to by users using a client which speaks the telnet protocol, which provides a stay-alive connection with the host, to relay output and send commands. Some however have developed web interfaces, or other such methods; however this commonly limits interaction that the user can have, usually to the point they have no interaction, but instead can browse objects and discover typical information. Developments in cross-MOO networking have also lead to the creation of SunNET, a hubless network allowing cross-MOO communication and add extra possibilities to cross-MOO development, including networked channels.
Every MOO stores the content and state of all its objects within a persistent object database, which keeps objects from being lost by a reset of the MOO server software or the computer hosting it.
New MOOs have to choose a starting database from which to set their MOO up, or they can use a very minimal one which contains only the necessary objects to start a MOO. There are a handful of such MOO "core" databases which serve as foundations of code and utilities from which to start your MOO, including LambdaCore (from LambdaMOO), MinimalDB (considered the minimum necessary code and utilities to work usefully in a MOO), JHCore (from Jay's House Moo), and enCore (from LinguaMOO).
Every object in the MOO is assigned a number, and may be referred to by this number, prefixed with a #, as well as its name when the user is in the object's presence. Administrators, also known as Wizards, who are able to manage the MOO, and assign certain global names to these objects, which are prefixed with $, a process known as corifying. They also feature parenting systems, and every object will have a parent, commonly eventually leading to Root Class, otherwise known as #1. #0 is also reserved as a special system object which is responsible for managing the list of global names, incoming network connections, and other information related to the operation of the system.
MOO, along with all of its nephews, started out with text based adventure games. With the advent of the internet, MUD was formed as a networked version of one of those games. Eventually it developed into a tree of different types of MUD, with MOO becoming one of them.
Stephen White (also known by the handles "Ghondahrl" and "ghond") wrote the first version of the MOO server, which was released on May 2, 1990, and used for the operation of a server called "AlphaMOO". Pavel Curtis, an employee of Xerox PARC and also known by his handles "Lambda", and "Haakon", took the basic design, language, and code, fixed bugs and added features to release the first version, called "LambdaMOO" on October 30th, 1990.
According to Jill Serpentelli in her paper Conversational Structure and Personality Correlates of Electronic Communication:
MOO was originally developed as a MUD server in the same general style (sharing much of the command syntax and community conventions) as TinyMUD.
There are currently two distributions of the MOO server code. The more popular of the two, the LambdaMOO server, is named such as indication of the close historical and continuing association of the MOO server code with the first public MOO, LambdaMOO, which is still popular today.
It is this LambdaMOO version of MOO that gained popularity in the early 90s, and it remains the most widely-used distribution of MOO. Pavel Curtis continued to maintain the server for several years. Other early contributors to the LambdaMOO server included users Tim Allen ("Gemba"), "Gary_Severn", Roger Crew ("Rog"), Judy Anderson ("yduJ"), and Eric Ostrom (known as "Joe Feedback"). Later, Eric Ostrom maintained the server, and the server is now maintained by Ben Jackson and Jay Carlson and has a LambdaMOO SourceForge.net project.
Some servers use "MOO" style object oriented characteristics without being descended from the original MOO server, in the sense that they use little or none of that server's source code and use internal languages that are more or less incompatible with the MOO programming language. None of them have attained the popularity of LambdaMOO or its relatives.
Stephen White went on to write a new and similar system called CoolMUD, although it never obtained the same wide userbase as MOO. Another, later, attempt at a programmable object-oriented MUD server was ColdMUD, written by Greg Hudson and later maintained by Brandon Gillespie under the name "Genesis".
One unusual MOO with no real relationship to the original MOO is called mooix. mooix is unique among MUDs in that it uses the underlying UNIX operating system to handle all of the multitasking and networking issues. Several unique side effects result from this, one of which is that the MOO can be programmed in any language. mooix was written after a failed attempt by Joey Hess to write a MOO entirely in Perl, called perlmoo.
There are a number of MOOs written in Python, including POO, MOOP and ErisMUD.
MOO is often used in programming games, such as PointSet.
Participants (usually referred to as users) connect to a MOO using telnet or some other, more specialized, client program. Upon connection, they are usually presented with a welcome message explaining how to either create a new character or connect to an existing one.
Having connected to a character, users then give one-line commands that are parsed and interpreted by the MOO as appropriate. Such commands may cause changes in the virtual reality, such as the location of a character, or may simply report on the current state of that reality, such as the appearance of some object.
The job of interpreting those commands is shared between the two major components in the MOO system: the server and the database. The server is a program, written in a standard programming language, that manages the network connections, maintains queues of commands and other tasks to be executed, controls all access to the database, and executes other programs written in the MOO programming language. The database contains representations of all the objects in the virtual reality, including the MOO programs that the server executes to give those objects their specific behaviours.
Almost every command is parsed by the server into a call on a MOO procedure, or verb, which actually does the work. Thus, programming in the MOO programming language is a central part of making non-trivial extensions to the database and hence the virtual reality.
All MOOs provide a flag called Wizard; when set on a player, the player gains the ability to view and modify nearly everything in the MOOs database. Such players are called Wizards, and usually form the basis for MOO administration. Designated owners of a MOO are sometimes referred to as Archwizards.
These wizards are able to restrict access to the MOO, as well as make news postings and monitor logs. Wizard permissions are needed for modification and even execution of verbs and properties for which the user does not own, or is not publicly readable/writable. All verbs and properties within objects have the appropriate flags, with the user can change to determine its current state. They are also able to assign global names to any object.
Builders are players who are given the limited ability to create objects and areas in a MOO, whereas programmers are also able to program on the MOO.
Welcome to the MOO (MUD object oriented) learning project. This project allows Wikiversity participants to learn about the text-based virtual reality environments known as MOOs.
Contents |
"MOO" means "MUD, Object Oriented".
MUD is an acronym for Multi-User Dungeon (or Domain), based on the Dungeon and Dragons board game. The board is a world divided into various sized rooms with interconnecting exits. The world is inhabitted by several monsters and contains many items like armour, weapons, potions, hearbs, scrolls, poisons, containers, and furniture. Each player creates their own character and tries to advance it as far as possible by moving around the world and 'interacting', usually by killing or getting killed by, monsters with the help of other characters.
Most MUDs use several point systems: Experience, Hit, Mana, Move, and Gold being the most common. Characters also have attributes, such as strength, intelligence, wisdom, dexterity, and constitution. These are defined by the character's race and modified by class. The class defines what skills and spells a character can learn, but race decides how well they can do them. In some MUDs, it is possible to multi-class and in others to remortalise.
The game is played over a network, using a telnet client to connect to the MUD server, and logging in as your character, typing commands, and reading the response. Each room has a name, description, and exit list. By carefully reading the description you can figure out where you are and what surprises the room contains. Other players, monsters, and items currently in the room are listed by name and title (or item description), and their current position (standing, resting, fighting, incapacitated, or corpse).
You can use several communication channels to talk, say, shout, yell, auction, and whisper to others. This variety enables players to remain in contact throughout the world. Players can turn off channels to avoid channel spam. Unlike direct channels, notice boards provide discussions, questions, bug-reports, and advice, regardless of whether players are logged in or not.
Because the MUD simulates a world and people have the choice to become someone else, MUD culture has undergone some academic scrutiny. Four player types have been identified:
These four types interact with each other as follows:
Successful MUDs have a mix of all four types, as each contributes to the mud culture. Setting up the world to provide interest for all types is more an art than science. Ensuring that killers don't drive out socialisers, achievers the killers, socialisers the explorers, or explorers the achievers, takes careful balancing between interest, difficulty, challenge, and oppotunity. A major factor is building unique, rather than using stock, areas. Builders are designated players who have to bring the world alive with interesting descriptions and colourful words. But more than that, the layout and quests must be well tested for difficulty and interest. Coders define the game play, the skills, races, classes, and available items. Angels are special players who spend their time helping others and mediating conflicts. Immortals run the MUD, make policy, are forbidden to play, and lurk in the background, just so you know they're watching.
A MOO is a MUD that makes use of an explicitly object-oriented programming language for constructing the MUD. See: MOO programming language.
Mooversity can help Wikiversity participants learn about object-oriented programming.
If you have participated in a MOO, please provide a description and a link.
MOO
|
|