Best Design Award Entry

Team 03 (Team Voltron)

The strong design of our gizmoball entry is shown by the combination of two events
that are generally only possible to achieve simultaneously with a well designed 
system: our general system design changed very little over the course of the project's
development, yet we were able to easily and quickly create drasticly modified versions of
the game.

Our design is based loosely on the model-view-controller pattern: our game items (the
models) are implemented so that that can function entirely independently have the game
board (the view) and the controller logic.  While we did zealously refactor any redundant
data dependencies and repeated code, changing our design in many incremental ways, our
overall class model is still very similar to the first plans we made in week one.  We also
made sure to put simple wrappers around the many complicated Java API libraries we needed 
to use; for example, the XMLHelper class put a friendly face on the challenge of creating
well-formed XML with the Xerces library, and the Song class conveniently unified the
annoyingly inconsistent javax.sound.midi and javax.sound.sampled libraries.  Our detailed
dynamics library, written by the physics major on the team, works well enough for us
to show off a simulated pool table "break" as a demo.

This could be a sign of a poor and difficult to adapt design.  In fact, quite the contrary:
our design has enabled us to create many variants on the original theme with a minimum of pain.
For example, we created an ASCII art-based "text mode" for GizmoBall, which runs a level
in a Unix terminal window.  While this was mostly done as a joke, that fact that we were
able to go from concept to a completed execution in under an hour is a strong testament
to the modularity of our system.  Similarly, we were easily able to make "stress tests" that
simulate the entire physics model of our game on a test level for long periods of time
to make sure that "impossible conditions" never happen; a poor design would have made it
difficult to run such tests outside the confines of the Swing window.

Another example of our design's flexibility is the fact that we needed to make absolutely no
structural changes to it to adapt to the amendment.  We simply needed to add the Extender
gizmo and create the ghost ball option; in fact, we had already planned ahead and carefully
made sure to support multiple balls from day 1.

Another testament to the flexibility of our design is the variety of types of games we can
play with it.  For example, we created a board that simlulates
the "labyrinth" game, where you roll a marble around a wooden maze by tilting
it and try to avoid holes.  By creating a zero-gravity level with gravity waves
connected to keypresses to simulate tilts and absorbers to simulate holes, we
were able to create a fun and challenging version of labyrinth -- inside GizmoBall!
Only by our careful design, which made sure to never hard-code the gravity and
friction as a single constant, was a single team member able to create the entire shockwave
and environment modifier stack in just one night.

All in all, the diversity of uses to which our Gizmoball system can be put without feeling at all
forced shows that our project's design is quite solid.