In our design, user interaction with a gizmoball level is based on the
model-view-controller design pattern and operates in two distinct modes:
edit mode and play mode.  The layout and properties of a level are
represented by the Level class.  The Level class is used in both edit
and play modes.  Gizmos are represented by subclasses of the Gizmo class,
and balls are represented by the Ball class.  A Level contains lists of
the Gizmos and Balls it contains.  The MVC design pattern was chosen to
allow for a single representation of a Level and its Gizmos while
still allowing the user to interact with it differently in edit and
play modes.

In edit mode, the initial state of the gizmos and balls in a level is
displayed by a LevelEditView, and the user may modify the level by
adding, removing, and modifying the initial properties of gizmos
and balls.  Although gizmos may contain internal state (eg the angle
of a flipper), such state is only relevant in play mode and the Level
class does not update the state of gizmos or balls.

In play mode, additional information must be kept about the state of the
game, such as the ball position and score.  The state of a gizmo is
maintained in the gizmo itself to allow the processes of updating and
drawing to be encapsulated in the gizmo's class.  Similarly, the state
of a ball is maintained within the Ball class.  An additional class,
GizmoGame contains the global state of a game as it is being played.
The global state includes the score and any special modes that are active
(such as multiball).  GizmoGame is also responsible for responding to
key presses and collisions as well as updating gizmos and balls.
To allow gizmos to have special effects on the game state, a GameEvent
class exists to contain pre-defined game events which a gizmo can trigger.

All collisions and game events are handled by GizmoGame as they occur.
We also considered adding events to a queue to be purged each time
GizmoGame updates, but decided against it to avoid creating an overly
complex class to handle different types of events (ball-gizmo, ball-ball,
game event, etc.) in general.  Collisions call an appropriate method in
the Ball class to update the position and velocity of the ball(s).
Collisions involving gizmos also call a trigger method on the gizmo.
Game events are handled in GizmoGame itself to allow them to have an
effect on the state of the entire game.

Milestones:
Ball, Gizmo, Level initial implementation: Monday 11/14
GizmoGame, GameEvent initial implementation: Friday 11/18
Ball, Gizmo, Level, GizmoGame, GameEvent revision: Friday 11/25

Fancy graphics: Friday 12/2