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. TheGame
object
contains e.g. one GamesBoard
, which contains 100 CorridorBlock
objects.
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 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 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:
CorridorBlocks
(which consist of Walls
and a
Floor
) that represent the logical maze corridors the maze is made of
Players
that represent the players in the maze
Treasure3D
objects that represent the treasures in the maze
Arrow
objects that are used to position the seperate ('free')
maze corridors at each turn (see the rules of the game
for more information)
Teleport
objects that are used to indicate the position of
a 'staircase' to another level of the games' board
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.
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.
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.