\label{sec:game-system}

The game system module, implemented in the \texttt{gizmoball.game}
package, contains the classes necessary to represent a game state and
simulate it.

\subsubsection{Architecture}
\label{sec:game-system-architecture}

The principal interface to this module is through the
\texttt{GameBoard} class, which captures the state of a \Gizmoball
game board. An \texttt{GameBoard} can be constructed in an empty
state, or it can be generated by a factory function in
\texttt{gizmoball.xml.GizmoballReader} (Section~\ref{sec:serializer}).

Intuitively, a game board can be represented as a collection of
gizmos, in addition to a few additional pieces of state information
associated with the board itself. This is the representation used by
the \texttt{GameBoard} class, a composite object that contains gizmos.
We model the ball as a gizmo, so the ball does not need to be
considered separately. Each gizmo maintains its own state information,
including its position on the board, and the \texttt{GameBoard}
primarily passes messages on to the appropriate gizmos.

Each gizmo is represented by its own class which inherits from the
\texttt{AbstractGizmo} class. The \texttt{TranslatableGizmo} and
\texttt{FixedGizmo} abstract classes derive directly from
\texttt{AbstractGizmo} and express whether the gizmo can move about
the screen, or is fixed in place (this distinction becomes crucial in
collision handling, among other places). So, for example, we have a
\texttt{BallGizmo} that extends \texttt{TranslatableGizmo}, and a
\texttt{SquareBumperGizmo} that extends \texttt{FixedGizmo}.


\subsubsection{Property system}
\label{sec:property-system}

The property system is a generalized framework for storing information
about game entities. A property, represented by the
\texttt{gizmoball.property.Property} class, is simply a name-value
pair. The property can hold whatever type of value is appropriate for
the specific property, including a list.

Each gizmo contains a set of properties (the implementation is
contained within the \texttt{AbstractGizmo} class). Some examples of
data that are stored in a gizmo's properties list include:

\begin{itemize}
\item the gizmo's name (a string used by the editor to identify a
  specific gizmo to the user)
\item the gizmo's position and orientation on the board
\item the gizmo's color
\item for a \texttt{TranslatableGizmo}, its current velocity
\item a list of incoming and outgoing trigger connections
\end{itemize}

The property system also implements the Observer design pattern. Any
class implementing the \texttt{PropertyChangeObserver} interface can
register to be notified when a gizmo's properties change. This is
used, for example, by the editor user interface's property table in
order to update itself at the appropriate time.



\subsubsection{Game loop}
\label{sec:game-loop}

Game simulation is performed in discrete time, with a time quantum
known as a \emph{tick}. A timer in the UI's
\texttt{GameBoardComponent}, controlled by the
\texttt{PlayingInteractionMode}, triggers the \texttt{GameBoard}'s
\texttt{tick} method each quantum. This initiates the following
procedure:

\begin{enumerate}
\item The \texttt{GameBoard} checks for key presses passed to it by the
  \texttt{GameBoardComponent}, and maps them to keypress triggers, if
  applicable. If such a trigger exists, the object is notified that it
  has been triggered. However, the trigger does not actually take
  effect until later in the game loop.
\item Each gizmo's \texttt{tick} method is called. This simulates one
  quantum of motion, including friction and gravity. Each gizmo's
  motion is independent of the other gizmos on the board; we do not
  rely on information from other gizmos. Thus, the order in which the
  gizmos' \texttt{tick} methods are called should not matter. Each
  gizmo's previous position information is also retained; this will be
  used in collision resolution if necessary.
\item Collisions between two objects are detected. Since a collision
  is an event involving a \emph{pair} of objects rather than a single
  object, some arbitration is performed based on the types of the
  gizmos in order to determine which gizmo's \texttt{collide} method
  will be called.\footnote{This design has not yet been entirely
    finalized.} (For example, a collision between two translatable
  gizmos ought to be handled differently than a collision between a
  translatable gizmo and a fixed gizmo.) The physics package is used
  to resolve their collision and determine the new position and
  velocity of each object. Each object involved in a collision is
  notified that it has been triggered.
\item Triggers are processed. Every object that had been notified that
  it was triggered, either by a keypress or a collision, performs
  whatever action it performs in response to triggers.
\end{enumerate}

% Local Variables:
% TeX-master: "prelim.tex"
% End: