MOOs (Multi-user Object-Oriented environments) are object-oriented
environments where multiple users synchronously and asynchronously
interact in the context of virtual worlds. MOO applications are a
particular case of concurrent and distributed programs where each user
realizes that other users may be in a remote site and that information
identifies the building blocks of text-based virtual environments:
Besides these functional building blocks Evans also identifies
non-functional building blocks of text-based virtual environments:
- Locations with defined scopes: ``A user can sense events and
objects within this scope, such as seeing and using objects within
the room or hearing a conversation''.
- Persistent objects: Players holding objects will still
hold them when they return after having exit the environment.
Moreover, the environment itself is persistent, it should survive
- Transportation and Navigation: Constructs should be
provided to allow users move between scopes. These constructs
should allow to move through exits between rooms, or allow
teleporting directly to another room, or joining someone in a room.
- Communication: Users should be able to communicate.
Communication can be synchronous or asynchronous. Synchronous
communication can use scopes. For instance, talk to all the players
that are in a room. New scopes can also be defined to allow
communication. For instance, a radio with different frequencies.
Asynchronous communication can use electronic mail or newsgroups.
- Properties of objects: To be interesting objects may have
properties, as its description, weight and so on. Should be no
restriction on the kind of properties a may object possess.
- Ownership and levels of control: Users can own objects and
they can also pick them and move them between rooms. These features
require the definition of levels of control. For instance, an
object's owner can pick it and move it but other users only can read
- Flexibility: The environment should provide online
creation of objects and online definition of their behavior. The
definition of new objects should not require restarting the server.
Behavior is defined in terms of verbs. Besides its properties, an
object possess a set of verbs. Verbs code is written in the MOO
programming language and it is executed using a set of built-in
When applying separation of concerns to MOOs we identify three aspects
of the problem:
- Server Requirements: Object verbs execute in a server.
This server should have database support, persistency, and
robustness. These features are provided by low-level building blocks
in the server.
- Virtual machine: The online MOO programming language is
interpreted and executes in a virtual machine defined in the server.
Built-in functions are hard-coded in the virtual machine.
- Efficiency: The MOO designer needs to decide whether
functionality should be hard-coded into built-in functions for
efficiency, or it should be written in the online programming
language for flexibility.
- MOO domain abstractions: Concepts as scope, object,
user, transportation and navigation are examples of MOO-specific
abstractions. These abstractions have a set of properties that are
perceived by MOO-users. For instance, users perceive objects as
persistent since they still there when users return to the MOO.
Object ownership is also perceived by MOO-users since since he get
some of his operations rejected when accessing another user object.
- MOO flexibility: Flexibility is a key functionality of
MOOs. Flexibility allows online object definition and creation.
Online actions is supported by a virtual machine that execute a set of
built-in functions. Moreover, flexibility allows the dynamic change of
- MOO distributed architecture: MOO are concurrent and
distributed applications. Most of current MOO distributed
architectures are based on a centralized server with several remote
clients that are connected using a protocol as telnet or http.
Separation of concerns techniques can be applied to each one of
mentioned aspects. Each MOO domain abstraction can be represented as a
design pattern and provided as a reusable design artifact integrated
in an object-oriented framework. In order to support flexibility, the
design patterns described in the GoF book may be
useful since they describe object-oriented techniques. Note that these
patterns are MOO-independent and their intent is to provide a flexible
class structure. For instance, the Chain of Responsibility
design pattern can be applied to decide which verb executes in
consequence of a request and, a player can enrich the set of his
features in run-time by applying the Decorator design
pattern. MOO distributed architecture benefits from separation of
concerns if distribution can be introduced incrementally and according
to the number and location of users. For instance, if a virtual class
is going to occur and most of the participants are located in the same
place, performance would be improved if the class room is located in a
In the MOOSCo project we envision applying separation of
concerns approach to MOO domain abstractions and MOO distributed
Antonio Rito Silva
Last modified: Thu Jul 27 17:05:28 GMT Daylight Time 2000