Contains the graphical user interface of an Amazing Quest game.

Structure

Overview

The following picture shows the partial structure of objects that make up the interface of the game:

Only the containment of objects in other objects and some inheritance is drawn.

The default containment number is one. The Game object contains e.g. one GamesBoard, which contains 100 CorridorBlock objects.

Main control

The only public class in the package is the GameController. Constructing a game controller effectivily starts a new Amazing Quest game. The game controller talks to the outside world through an Uplink object. These two classes are the only coupling between the game and the rest of the program. The outside world only constructs a GameController, and the game itself talks to the outside world by sending game messages through the Uplink. The Settings object provides some global information that all classes in the package might use.

The 2D interface

The actual 2D interface is constructed in the Game object, which is build by the GameController when all the nessecary initialization information is received from the server. The interface itself consists of various custom components (PlayerList, MissionInfo, History, SpectatorList, StatusBar). The Game observes various parts of the 'logical' game and updates these components when nessecary.

The 3D interface

The 3D interface is also constructed by the Game object. The 3D scene itself is made of VisibleObjects. These are abstract objects that contain a 3D model (a subtree of the Java3D scenegraph that will make up the whole scene). The basic visible objects are:

Treasures and teleports are part of the 3D model of a corridor block. All the corridor blocks are contained in the GamesBoard object that represents the 3D maze. This also contains all the players (which are positioned independently from the maze corridors) and the arrows next to the maze. The 3D model of the games' board therefore contains all the 3D models of the other parts that make up the 3D interface.

To simplify the construction of the 3D models, object can use the ModelTool object to generate coordinates, normals etc. The NodeComponentFactory ensures that as much as possible Java3D node components are shared between various nodes, since this speeds up the rendering process.

3D interaction

Users can select some 3D object with their mouse (called 'picking'). Only subclasses of VisibleObject, namely PickableObjects can be selected this way. PickableQuestObjects specify the picking reponse even further, by changing the {@link quest.global.game.SelectionState} of the associated {@link quest.global.game.Selectable} object.

The actual picking is implemented by a custom Java3D behavior: PickBehavior. This behavior is added to the scene graph, and will perform a pick when the user clicks on the 3D canvas. If a PickableObject is picked, a PickEvent is generated and given to that object. Objects that are interested in certain pick events must implement the PickListener interface, and register themself as a listener at the PickableObject they're interested in. When a pick happens, the picked object will distribute the PickEvent to all the listeners. This behavior is similar to the other event handling schemes in Java, and is an example of the Observer design pattern.

Animation

All the basic visible objects represent a logical part of an Amazing Quest game. Each visible object observes the part it represents, and will update it's 3D model when the logical part is changed. The CorridorBlocks for example will update the position of their 3D model automatically when the MazePosition3D values change. These adapdations are often implemented as animations. This means the 3D models are self-supporting: each part updates itself.

Animations are implemented by constructing at runtime a Behavior that performs the animation. This behavior is added to the scenegraph that makes up the 3D model of the visible object. The Java3D renderer will then execute the animation and animate the 3D model of the visible object.