cs3802 - Software Engineering
yIN-yANG-pINK-dANK - Homework 3 - 11/10/99

Joe Hughes
Shad Hashmi
Mike Nestrud
Nick Black
John Yeager



Project Overview:

Our Design project is for a game called "Math Invasion", which is an
educational game for kids ages 8 to 10. The theme of the game is that
aliens have invaded our planet, and are dropping bombs on a city. In
order to save the city, the player has to solve math equations, one per
bomb dropped, to make the bombs not hit the city. The game will get more
difficult as the player's score increases, and there will be provisions
for saving high scores at the end of game play. The game is designed to
help young children improve their basic math skills, and is intended to
include full multimedia capability, with sound and video.



Completed Design Decisions:

1. We decided to follow the Model-View-Controller paradigm for this project.
This allows for abstraction of the math problems and details of the game
away from the user's view of the game, which eases programming and increases
maintainability and reusability. This leaves our design language-independent,
which was a goal of our design.

2. We decided that all objects on the screen during game play will be stored
in a Linked List data structure by the Controller. We thought of using other
data structures, but a linked list seemed simplest to implement, and allows
the programmer sufficient flexibility should the application need more objects
in the main view at a later time.

3. We decided that all graphical objects will draw themselves, instead of 
having the View draw them each individually. We could have the View draw
the objects, but we decided this would not be as reusable as letting the
objects draw themselves. By letting the object draw themselves, the programmer
can change the way objects look on the screen without changing the View, which
leads to more reliable and robust code.



Pending Design Decisions:

1. We left open a decision between a static list of math equations for game
play, versus a randomly generated set of problems for the player. A randomized
list seems simple enough to program, but the design specification states that
fractions must be evenly divisible. This is simple to overcome, but the
advantages of the static list include the ability ro re-play a whole level and
get the same math problems again, which could be beneficial.

2. We left open a decision between event-driven game flow, versus a
structured or non-event-driven paradigm. We did not know whether the authors
of the specification intended to use a timer to drive events, or if they
wanted a static loop running the graphics updates. This seems like a small
decision, but it potentially affects the way the objects will need to interact.

3. We debated whether the game should create a linked list of equations before
each level starts, or whether we should have an object array for each level.
The object array would allow for a static number of bombs to drop for each
level, whereas a linked list could provide more flexibility for the different
levels. We need to talk with the authors of the specification to see what
they intended the game to do, as far as expandability as the levels get
more difficult.