Analytical Perspectives in Game Design
Chain of command
[ Home ] [ Up ] [ Chain of command ] [ Construct scenario ] [ Displaying a game to join ] [ Instantiating new parts of the game ] [ loading a game ] [ Selection dialog scenario ] [ Starting a game ]

 

The chain of command is combination of 2 patterns, the chain of responsibility and the command. It allows the applet to send of a command it does not understand to the game thing specified. If the game thing cannot handle the request it passes it up or down the chain to be handled.

Consider the following scenarios...

The player pushed on a batten in a door. The door opens. (UP)

The player tries to push open a door, but the door cannot open because it is locked by a component lock (DOWN).

The chain of command only passes the command up the hierarchy. To get the behaviour described by the lock a decorator is used.This has the advantage of allowing locks on that may only be decorative and allowing multiple locks buried deep down in the hierarchy.

main scenario

There is an assumption here that the viewer is building a view and needs the commands pertinent to a particular view. In game terms I am assuming that the commands are passed back as an tree for use in a tree or menu control.

Command needs to do things with threads and players on other computers to resolve multi-thread contentions when commands simultaneously interact.

  1. the viewer requests a new set of commands from the Game Thing.
  2. the Game Thing invokes a command generator.
  3. the Command Generator creates the actual commands as command sets.
  4. the command Generator passes the command set back to the game thing.
  5. the game thing passes the command set back to the viewer.
  6. Some time later the user uses the viewer to select a command.
  7. the command checks that the object has not been locked by another user
  8. the command broadcasts its intention to execute the command to all other clients and sets up a guard timer
  9. The command calls the appropriate class with the selected arguments.
  10. the command waits for the guard timer to complete
  11. if no lock responses have been received, the command proceeds
  12. the command is transmitted to all other clients
  13. the command is processed locally
  14. the viewer is notified that the action is complete.
 

21/11/99

 

See also: [Role Playing Games] [Game Engine]
© 1998, 1999 Brian Yap. These pages are available under the GNU licence.