A key element of the GAMES idea is the notion of a spatially oriented synthetic environment where learners explore and discover. The Spatial Metaphor maps a domain (and, consequently, its interface) onto the basic spatial elements of a MUD. GameCore accomplishes this using the MOOPort, a visual item in every GAMES Project game that is a viewport into the MOO running the game server. In it, objects are represented by MOOLogos. These logos can be manipulated in a way that makes sense to the domain. For example, in a simulated store, merchandise and store employee are MOOLogos. MOOExits are special MOOLogos for moving from one room to the other by double-clicking on them. For more information, read the MOOPort Implementation Spec, below.
Don Bora and Cliff Chaput
This paper specifies the implementation of the MOOPort. The MOOPort is a window to the MOO game server. It is an accurate and consistant representation of the data on the game server. Changes in the server are reflected in the MOOPort, and manipulations of the MOOPort change the state of the server. The MOOPort on the Mac and Windows will be a view in a window which displays pictures that represent MOO objects such as exits, objects, and other players. The MOOPort is part of GameCore, and therefore available to all game developers.
The MOOPort will be a view that gets attached to a window. The MOOPort will be responsible for:
The MOOPort is used mostly for protocol between the server and the objects in the room, and also between the objects and the platform's user interface routines.
Objects in the room will be stored in the MOOPort as MOOLogos. MOOLogo serves as a superclass to all the different objects in a room that are represented in the MOOPort. MOOLogos will be implemented as sprites (N.B. when sprites later turned out to be too resource bound, another scheme was developed). Both Windows and Mac have sprite packages. MOOLogos are responsible for:
There will be different subclasses of MOOLogo for different classes of objects in the MOO. The three main subclasses will be Object, Exit, and Player. See the SELL Game Mooport for a concrete example.
Only Objects can be dragged. When a player clicks and holds on an object, the client will assume that the player wants to drag that object. The client will notify the server that the player has picked up the object ("get object"). If the "get object" fails, the dragging action is aborted. Otherwise, when the client receives confirmation that the player now has the object, the MOOPort will notify the parent window that the user is dragging an object. The window will then track the mouse and tell the object to draw itself at appropriate locations. Whenever the pointer (holding the object) passes over another object in the MOOPort, the window will query that object to see if it will accept a drop. If the result is TRUE, the receiving object will highlight. If the player releases the mouse button, that object will then be notified that it has accepted a drop of another object, and will do the right thing (which will involve some notification of the server). Otherwise, if the user moves the mouse off of the object, it will simply unhighlight.
All actions that can occur in the MOO must have a unique and meaningful visual representation of that action. For example, when a player leaves the room through an exit, the watching player should see that player's MOOLogo move to the exit and disappear from the room. The same is true of picking up and dropping objects, opening and closing containers, speaking to other players, etc.
The following is a list of tasks for completing MOOPort: