% -*- TeX-master: "finaler.tex" -*-

\label{sec:overview}

\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.  The physics library, Swing, and XML
  DOM are provided libraries.  Additionally, this includes the
  \texttt{gizmoball.property} package (see
  Section~\ref{sec:properties}), which encapsulates generic support
  for object property access.  The property system is used throughout
  \Gizmoball, particularly by the game system.
\item[Game systems] The game system consists of the
  \texttt{gizmoball.game} and \texttt{gizmoball.xml} packages.
  \texttt{gizmoball.game} (see Section~\ref{sec:game-system}) lies at
  the core of \Gizmoball and captures the game physics.  Note that
  this component of \Gizmoball is entirely independent of the user
  interface.  Also, this only defines the abstract gizmo, which is
  itself quite general.  The \texttt{gizmoball.xml} (see
  Section~\ref{sec:serializer}) package also resides in the game
  systems, and encapsulated support for loading and saving \Gizmoball
  game board configurations in the standard XML format.  Furthermore,
  this includes the implementations of the standard gizmos, in the
  \texttt{gizmoball.gizmos.standard} package.
\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} (see
  Section~\ref{sec:ui-design}) package takes care of the overall
  interface, but abstracts out the mechanism for actually rendering
  the game board.  Currently, this renderer abstraction is implemented
  by the $\mathbb{R}^2$ renderer in \texttt{gizmoball.ui.r2} (see
  Section~\ref{sec:r2-renderer}), which displays a basic 2D game
  board.
\end{description}

\subsubsection{Design Philosophy}
\label{sec:design-philosophy}

Our guiding design principle was generality.\footnote{Our design was
  handed down to us, inscribed upon stone tablets by the gods of
  generality.}  Our lower layers make as few assumptions as possible
about the upper layers, providing generalized API's that the upper
layers can leverage to control and direct the functionality of the
lower layers.\footnote{Thus, we follow the ravioli model instead of
  the lasagna model, without reaching the extent of the risotto
  model.\cite{pasta-theory}} Due to our goal of generality, we have
code-named this project \Gizmoall.

Following generality, we designed for component simplicity.  The
overall system achieves complex behavior by combining many of these
simple components.  As such, the design of \Gizmoball is a tour de
force of abstraction.

We leveraged dynamic polymorphism whenever reasonable in order to
achieve drop-in replacability and to enforce our goals of generality.
\cite{dpif} Many components of the system resemble plug-in
architectures because anything presenting the appropriate simple
interface can be dropped in to change the behavior of various aspects
of \Gizmoball.

Finally, many of \Gizmoball's components are decoupled via run-time
discovery.  This goes hand-in-hand with our use of dynamic
polymorphism because it allows components to discover the capabilities
and structure of other components at run-time instead of relying on
static knowledge.