\subsection{Overview}

\subsubsection{Top-level design}

\begin{figure}[htbp]
  \centering
  \includegraphics[scale=0.75]{layers}
  \caption{Gizmoball layer model}
\end{figure}

The design of Gizmoball is organized into three layers:

\begin{description}
\item[Utility libraries] These libraries provide basic services to the
  Gizmoball game and interface.  Both the physics library and Swing
  are provided libraries.  Additionally, this includes the
  \texttt{gizmoball.xml} package, which encapsulates support for
  loading and saving Gizmoball board configurations in the standard
  XML format.
\item[Game systems] The game system consists of the
  \texttt{gizmoball.game} and \texttt{gizmoball.xml} packages.
  \texttt{gizmoball.game} lies at the core of Gizmoball and captures
  the game physics and the modeling of gizmos.  Note that this
  component of Gizmoball is entirely independent of the user
  interface.  Additionally, this is where the properties system is
  implemented, because it is closely coupled with the gizmos
  themselves.  The properties system captures the properties of gizmos
  in an easily accessible manner.  The \texttt{gizmoball.xml} package
  contains the game serializer, which is responsible for loading an
  saving game board states.
\item[Interface] The user interface is built on top of the game
  systems and the Swing library.  It is responsible for driving the
  game system and presenting it visually to the user.  The game system
  relies on the interface for timing the simulation and for
  information on interactions from the user (namely, key presses that
  result in triggers).  The \texttt{gizmoball.ui} package takes care
  of the overall interface, but abstracts out the mechanism for
  actually rendering the game board.  Initially, this renderer
  abstraction will be implemented by the $\mathbb{R}^2$ renderer in
  \texttt{gizmoball.ui.r2}, which will display a basic 2D game board.
\end{description}

% Open issues

\subsubsection{Possible changes and unresolved issues}

While some form of a gizmo property abstraction is necessary to make
the editor function correctly, as it currently stands, the gizmos are
an odd balance of a somewhat slow and tedious property table approach
and much faster direct access to properties that is necessary for an
efficient physics and display loop.  Also, we are considering
segregating the triggers from the properties, and abstracting the
properties system out further from the gizmos.  Thus, the properties
system may still undergo revision.

Also, we are still considering the precise mechanism to use for
collision management.  Conceptually, a collision occurs
\textit{between} two objects, instead of simply one object colliding
into another.  However, this is difficult to express in Java while
still maintaining proper modularity of collision management.  One
possible solution is to leverage dynamic polymorphism with a global
collision manager.  This adds overhead, but leverages table-driven
programming for maximum flexibility.  Another possibility is to simply
define an ordering of gizmo types.  For example, this might entail
that a ball collides with an absorber, instead of the other way
around, thus making only one of the two objects responsible for
resolving the collision (if the two objects are of the same type, then
it should not matter which one is told about the collision).  However,
this second approach could lead to inflexibility.