\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 a toolbar (implemented as a
\texttt{JToolbar}) that handles system-level functions such as
loading, saving, and switching between editing and playing modes. 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. 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}.