12jul09 CmdrZin

Keying Items To Doors Or Rooms in DarkMud

How do you require the player to have a certain key or item to open a certain door or access a certain room?

To start, per Exercise 3 of the JavaOne 7400darkstar Lab, everything in the game is based on the MudObject class and
therefore implement the ManagedObject interface and is Serializable. This causes all game objects to be managed
by the PDS server database services to give the objects persistence. 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 commands. For items that the Player can carry around and use, the GettableObject class (1b) provides the commands and methods to support that.
The command parsing is where a lot of the game magic takes place and understanding
it will be our holy grail.  


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.