Contents:
This handout describes one of the two final project choices you have this term, Gizmoball. The other project is Antichess.
Your final project is to design, document, build, and test a program that plays Gizmoball. Gizmoball is a version of pinball, an arcade game in which the object is to keep a ball moving around in the game, without falling off the bottom of the playing area. The player controls a set of flippers that can bat at the ball as it falls.
The advantage of Gizmoball over a traditional pinball machine is that Gizmoball allows users to construct their own machine layout by placing gizmos (such as bumpers, flippers, and absorbers) on the playing field. These machine layouts may also form complicated "Rube Goldberg" contraptions that are intended to be watched rather than played. As an optional extension (after you have designed, documented, implemented, and tested all required functionality), you may create new varieties of gizmos that can be placed on a playing field.
Any team which meets all of the requirements for Gizmoball will be permitted to enter the design contest. The contest is optional, and will not affect your grade in any way. Nominal prizes will be given to the winners.
Because this project is in part a design exercise, the assignment specifies what the user should be able to do and leaves it up to you to figure out what modules and interfaces are appropriate. This section gives an overview of Gizmoball. A detailed specification will be handed out soon. To enable automated testing, your implementation must support a standard file format (details will be provided), in addition to the loosely-specified graphical user interface.
Gizmoball has a graphical user interface with two modes, building and running. In building mode, a user can:
In running mode, the user can play the game.
You will work in teams of three or four. All members of a team will receive the same grade, except in unusual circumstances. Each team member should be responsible for part of the work including documentation, design, coding and testing.
| Stage | Due date (subject to change) |
% of project grade | Graded on |
|---|---|---|---|
| Preliminary design | Wed. 4/19 | Have you identified the issues? | |
| Weekly meetings with TA | Mon. 4/10-Fri. 5/12 | Did all of the team members participate constructively? | |
| Preliminary Release | Tue. 5/2 | Is it a good design? Is the required functionality present? | |
| Design Critique | Mon. 5/15 | Are the tradeoffs & alternatives thoroughly analyzed? | |
| Implementation & test | Mon. 5/15 | Does it work? Have you demonstrated that it works? |
As you can see, 60% of your grade depends on design, which is a cricial apsect of any large software endeavor. A good, well documented design will make the rest of a group's work faster, easier and more enjoyable.