ItemsForRooms.html
02aug09 CmdrZin

Keying Items To Rooms in DarkMud

How do you require the player to have a certain item to be able to access a certain room?

This paper will look at the com.sun.sgs.darkmud.locked package. It supplies support for keys that can be used to unlock
or lock doors that are lockable. The following are classes that were added to support keys and lockable doors.
    ManagedObject, Serializable->MudObject->GettableObject->Key.java
    ManagedObject, Serializable->MudObject->Door->LockedDoor.java

As shown above and explained in Exercise 3 of the JavaOne 7400darkstar Lab, everything in the game is based on the MudObject class that implement the ManagedObject interface and is Serializable. This allows all game objects to be managed
by the PDS server database services to give the objects persistence.
NOTE: Game objects are passed around using their ManagedReference, not as ManagedObjects.

The MudObject class (1a) defines a minimal interface that allows all objects to have a description, maintain an inventory, support
aliases of its name, and parse command the look command. For items that the Player can pick up, put down, and carry around, the GettableObject class (1b) is provided.

The command parsing is where a lot of the game magic takes place and understanding it will be our holy grail.

Commands

As per the Exercise, commands are the primary means of interaction between objects. A key point is that the action an object
takes is based on how the object interprets a command, not by the command issuer doing something to it. So the target of the
command has to parse the command and respond to it.
Processing a command take two phases: Parse and Commit.

Parsing the Command

Text commands from the user are parsed to generate a command object. Each possible target (i.e. everthing in the room) is
given a change has to (2a) parse the command. If the target (2b) recognizes the command as one that it supports, then it (2c)
set the command's type. Once the command type is set, the rest of the objects do not have to parse the command for its type.
If an object (2d) recognizes that it is the target of the command, it (2e) sets itself to handle the command. If an object is not the
target, then it can still be involved by (2f) registering itself as being interested in the command.

Commiting the Command

This two phase process first allows any object that is registered to veto the command and second, if not vetoed, notifies all
interested objects that the command is being commited and the target executes the commnad.

Example: the Rope object
The Rope is going to be used to interact with a door. Since it has to exsit in the game, it must be (3a) a MudObject which
is a ManagedObject and is Serializable allowing the server to manage its existance. Also, since it is going to be used by the
Player, the Player has to be able to pick it up and add it to their inventory. Therefore, the Rope will be a GettableObject
which extends the MudObject class.

The MudObject provides the look command support. The GettableObject provide the additional take and drop command
support. Since the actions in the game are done by the target of a command. Rope action commands have to be supported
by objects that respond to the Rope. This will be the Trap Door that will be discussed later.