Cliff Chaput and Brian Slator

Given a MOO as the foundation of the games developed for the Games project, there is a need for a generic interface to the information in the MOO server. Using a standard interface to the MOO augmented by a graphical representation of the MOO information (the MOOPort), we create a way of interacting with the MOO that is both powerful and flexible enough to meet a variety of game design needs.

The MOO is represented on the screen much as people use the MOO in MUD game play. That is, there are rooms, exits, actions, and objects. However, these are represented on the screen in a generic, flexible fashion that allows the game designer to customize the game to suit the particular needs of the situation. The following is a breakdown of the spatial metaphor and its corresponding user interface components:

The Room = Window = Context.

The room is the place where things are, and where things happen. The room is the context in which game activity takes place. As such, its visual representation should be nothing more that a visual cue to the user that certain activities can take place "here." The can be done simply by providing a background picture. Just as we can assume functionality when we walk into a bathroom, we should also be able to assume functionality if a picture of a bathroom pops up on the screen.

The Object = Icon = Object.

The object is the fundamental entity that can be acted upon. Objects represent things that you can view and manipulate. In the case of the Mac interface, objects can be manipulated by clicking, double-clicking, dragging, dropping, and selecting. Objects in a room will be represented by icons on a bitmap that can be acted upon. The valid actions, and their meanings, will have to be determined by the server. The server will accept commands like click and dragto x y. (More on this later.) Players are objects, too.

The Exit = Button = Context Change.

Exits are used to change rooms. If a room is a context, then an exit should be used to change context. So to follow this train of thought in the User Interface, pressing a button on the background should change the background. There are more uses for buttons than this. Hence:

The Action = Button = Action.

Some activities can be performed without requiring an object to be acted upon, yet still occur within a context (unlike "global actions" like QUIT and WHO). These actions can also be represented by buttons on the background. One way to approach the Exit/Action similarity is to make Exits a type of Action (in fact, some MUDs implement exits this way). Another approach is to keep them conceptually and visually distinct. Exits and actions should be pict-buttons or "hot regions" on the background bitmap.

#ROOM|id|pict

New room. All exits, objects and actions are now invalid. Prepare for a new list of them. Display "pict" bitmap.

#EXIT|id|pict|loc|act

A new exit is being displayed. This happens when (a) we enter a room, (b) a new exit gets created, or (c) an obscured exit becomes visible. Add this exit to the list of exits for this room. Show the picture "pict" at the location "loc." Make the picture region hot if "act" is true.

#OBJECT|id|pict|loc|act|mov|sel

A new object is being displayed for one of the same reasons as #EXIT. Add this object to the list of objects for this room. Show the "pict" at "loc." If "mov", then it is movable. If "sel" then it is selectable. "act" indicates activation.

#ACTION|id|pict|loc|act

A new action is available. See above for reasons. Add this action to the list of actions for this room. Show "pict" at "loc." Make the pict region hot if "act" is true.

#MOVE|id|loc

An object, exit, or action has moved. Move the pict associated with "id" to "loc."

#REMOVE|id

An object, exit, or action is no longer visible/available. Remove the object from the appropriate list. Remove its picture from the screen.

#ACTIVE|id|act

An object's activation has changed. Activate or deactivate the object "id" based on whether "act" is true or false.

#PICTURE|id|pict

The appearance of an object has changed. Change the picture of the object "id" to "pict."

In order to accept a standard set of user input, every object will have a set of verbs to respond to user input. For example, when a user clicks on an object, the client sends the following string to the MOO: @click object-id. The following verbs are minimally necessary:

The Next Level

An example of higher level messages concerns animation. It would be really wasteful to use #PICTURE to animate objects (thought it might be necessary). It would be nicer to send commands like #WALKTO|id|loc and #GET|player-id|object-id and #LEAVE|player-id|exit-id. These could be included in the base vocabulary.

Also, every game should have #SAY|player-id|speech, and other things like #SMILE|player-id and #HAND|from-player-id|object-id|to-player-id would be useful. These have not been implemented