\label{sec:ui-design}

The user interface for the \Gizmoball game is implemented in the
\texttt{gizmoball.ui} package. It is a generalized design that allows
for multiple renderers to draw the game board state, and uses a shared
interface framework with \emph{interaction modes} for the game player
and editor in order to achieve code reuse.

The root of the interface is the \texttt{gizmoball.ui.GizmoBallFrame}
class. This class handles the initial bootstrapping of the system, and
displays the main window. It contains two rows of option buttons: a
universal set that handles system-level functions such as loading, 
saving, and switching between editing and playing modes; and a 
mode-specific set with controls that are only relevant to one mode or
the other (e.g. for playing mode, a start/pause button; for editing
mode, connection display options). It also contains a 
\texttt{GameBoardComponent} that draws a gameboard on the screen. 
It also contains a \texttt{PropertyTable} that displays information 
about the selected gizmo, and an editor toolbar that selects gizmos 
to be placed.

The actual drawing of the gameboard is performed by a
\emph{renderer}. We separate the renderer from the UI package in order
to make the design more general; by abstracting away the renderer, we
can drop in a new renderer that provides different
features. Initially, we intend to implement the $\R^2$ renderer
(described in detail in Section~\ref{sec:r2-renderer}), which
draws a two-dimensional representation of the game board using
the Swing API. If time permits, we may implement an $\R^3$ renderer
using the Java3D APIs.

Each renderer has a \texttt{GameBoardComponent} class (e.g.
\texttt{R2GameBoardComponent}) that extends the
\texttt{gizmoball.ui.AbstractGameBoardComponent} abstract base class.
This class handles all things related to the gameboard and its display
on the screen. It contains the \texttt{GameBoard} object that
represents the game board (see
Section~\ref{sec:game-system-architecture}). It accesses the game
board's state, and displays it in a renderer-specific manner.

Key presses and mouse clicks on the game board are also handled by the
\texttt{GameBoardComponent}. However, we maintain only a single
\texttt{GameBoardComponent}, regardless of whether the game is in the
editor or player mode. This decision eliminates the need to
simultaneously maintain or update state in two different game boards,
and facilitates code reuse. Since \Gizmoball obviously behaves very
differently depending on whether the user is currently editing or
playing, we use \emph{interaction modes}, which derive from
\texttt{gizmoball.ui.AbstractInteractionMode} and encapsulate how the
game reacts to user input (see Section~\ref{sec:ui-design-interaction}). 
The \texttt{GameBoardComponent} selects either the playing or editing 
interaction mode (for the $\R^2$ renderer, 
\texttt{R2PlayingInteractionMode} and \texttt{R2EditingInteractionMode}). 
The \texttt{GameBoardComponent} harnesses the power of dynamic 
polymorphism by passing click and keypress events to the interaction 
mode object, which chooses the correct action for that mode and invokes 
the appropriate method of the \texttt{GameBoardComponent}.

\subsubsection{Interaction Modes}
\label{sec:ui-design-interaction}

Interaction modes provide a pluggable system of user control handlers
that interface between events in the user interface and input domain
and the internal game systems.  The decision to adopt such a system
stems from a need for different strategies of handling user 
interactions depending on both the current mode (playing or editing)
and the current renderer ($\R^2$ or others).  One can easily see how 
editing would require different functionality than playing: keypresses
may be shortcuts rather than key triggers, and the gameboard component
would need to handle mouse events to deal with gizmo placement and
selection.  Similarly, a 2d renderer would not require camera angle
user controls that users of a 3d renderer would appreciate.  The
choice of an interaction mode system is also consistent with the
overall emphasis on designing a system that is as general and 
expandable as possible.

Implementations of interaction modes act as the keyboard and mouse
event listeners for the \texttt{GameBoardComponent}.  As such, the
interaction modes can handle user interactions from these input
devices correctly.  In addition, implementations of interaction
modes have various methods that serve as relays from the GUI's
components to the representation systems for the gameboard and 
display.  This design allows the interface and the internal systems 
to be completely isolated; the interface and devices are unaware of
underlying systems it controls, and the internal systems are 
unaware of buttons and input devices (or even a user).