% -*- TeX-master: "fdd.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 and the modeling
  of gizmos.  Note that this component of Gizmoball is entirely
  independent of the user interface.  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.
\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{Possible Changes}

The editor is not yet implemented, nor is the mysterious amendment,
therefore these could still affect the design of \Gizmoball, however,
we are confident that only minor changes will be necessary due to the
generality and flexibility of our design.

We are considering revising the timing mechanism to adapt to the
maximum update rate possible on a user's system by consuming idle CPU
time\footnote{While Machiavellian, this is standard practice for
  games}, instead of the current fixed rate timer.  This would only
change the user interface because the game system is interval
agnostic.  Furthermore, not only would this let it provide smoother
animation on faster computers, but it could smoothly adapt to slower
computers without causing responsiveness problems.