|6.170||Laboratory in Software Engineering
Final Project: Gizmoball
Due: See Schedule
Note: Some 6.170 students have acquired Repetitive Strain Injuries (RSI) over the course of the final project in the past. Don't let it happen to you. It hurts. Please read the MIT web site about RSI before embarking on the final project.
This handout describes one of the two final project choices you have this term, Gizmoball. For information on RSS Client, the other project, refer to handout devoted to it.
The goal of the 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. (If you don't know what a Rube Goldberg machine is, see http://www.anl.gov/Careers/Education/rube/ or http://www.rube-goldberg.com/). 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.
Gizmoball has a graphical user interface with two modes, building mode and running mode.
In building mode, a user can:
In running mode, the user can play the game.
The picture above illustrates the most important features of Gizmoball.
Each team may enter its Gizmoball implementation into a class contest for one or more of the following awards:
Whether your program implements only the basic required functionality orextra gizmos etc. will not be considered when making the design award. However extra functionality that improves game-play or "Rube Goldberg" artistry will be an asset in competing for the other two awards.
|Preliminary Design||Preliminary design document||Wed. Nov. 9|
|Preliminary Release||Source code, specifications, unit tests||Mon. Nov. 21|
|Final Release||Final design document, source code, specifications, unit tests, user manual, webstart packaging||Mon. Dec. 5|
Each team will receive a single grade for the final project, determined as follows:
|Category||Deliverable||Due date||% project grade||Graded on|
|Design||Preliminary design document||Wed. Nov. 9 at 12 noon||Are key issues identified?|
|Final design document||Mon. Dec. 5 at 12 noon||Is design clean, robust and flexible?|
|Team work||Weekly meetings||weekly||Did team work well together? Did all members participate constructively?|
|Packaging||User Manual||Mon. Dec. 5 at 12 noon||Is the tool easy to use? Is the user manual clear and helpful?|
|Webstart delivery of executable||Mon. Dec. 5 at 12 noon||Is the client packaged correctly?|
|Implementation||Specifications, preliminary||Mon. Nov. 21 at 12 noon||Are important interfaces identified and crucial parts well documented in Javadoc?|
|Specifications, final||Mon. Dec. 5 at 12 noon||Are important interfaces well documented in Javadoc?|
|Unit tests, preliminary||Mon. Nov. 21 at 12 noon||Are there good unit tests for non-trivial classes?|
|Unit tests, final||Mon. Dec. 5 at 12 noon||Are there good unit tests for non-trivial classes?|
|Source code, preliminary||Mon. Nov. 21 at 12 noon||Is the code clean and well structured? Basic functionality working?|
|Source code, final||Mon. Dec. 5 at 12 noon||Is the code clean, well-structured and low in defects?|
Here is what each of the deliverables should contain:
Some general points:
Each team will meet with its TA once a week for an hour. You should contack your TA to schedule these meetings. To receive full participation credit:
Although the progress document must be clear, it is short and informal. This document will form the basis of discussion during the meeting, and the TA will keep it on file as a record of progress made. The team should bring multiple copies to the meeting, one for each team member and one for the TA. This progress document should include the following information:
This section is full of information and links that will help you complete your final project.
javax.swingpackages to construct your graphical user interface (GUI). We have provided you with a demonstration program in Example.java that shows how to animate the movement of a ball bouncing around the window. It also demonstrates how to get your program to listen to user events, such as clicking on a toolbar button, pressing a key or dragging the mouse. All members of your group should be able to compile and execute this demo GUI.
We have also provided you with a library of physics routines (see Appendix 3) for calculating the dynamics of elastic collisions. You are welcome to use this code as is, or modify it in any way that you like.
A careful design will save you a lot of time in the long run. It's
well known that a small mistake made early in a project can become a
big problem if it's not caught until much later. The preliminary
design is a major part of the project (more so than its proportion of
the grade might indicate). Do it very carefully, trying to anticipate
problems that may arise. Then the rest of your project will be more
straightforward and more fun.
One of the largest challenges for this kind of design problem is
figuring out where the "gotchas" are. If you are having difficulty
imagining how to structure one part of the design it sometimes helps
to build a small prototype. Plan to throw away your prototypes. Once
you've figured out how to do design something correctly, it rarely
makes sense to try to retrofit a hacked up, broken version.
Validation shouldn't be an afterthought! You may choose a design
because its implementation will be easier to test. Make sure you
validate your code as you implement.
Incomplete documentation is better than no documentation at all. If
a potential problem or subtlety occurs to you, but you don't have time
(or are unable) to formulate it properly, then just add a few
sentences in your document describing the issue. Later, if you have
time, you can go back and fix it.
Don't include any redundant material. For example, there's no need
to explain the difference between black-box and glass-box
testing. Just indicate which of your test cases fall in each
category. Similarly, being rigorous is not the same as belaboring the
obvious. You can assume that your TA knows what a set or a stack
is. There's no need to explain something from scratch when you can use
standard terms and notions.
Enjoy being part of a team. Run new ideas past your partners, and
discuss problems with them. Read and discuss each others code. A good
way to find a bug is to ask someone else to look at your code. Start
Each meeting you hold with your team members (or your TA) should have
The roles should rotate among the group members; in 6.170, no one
individual should perform any of the roles disproportionately
We had fun putting together this project. Our goal was to provide
you with a project that is both very challenging and offers many
opportunities for you to be creative. We encourage you to
experiment. Make your implementation of Gizmoball as beautiful to
watch, and as fun to play as possible. That said, make sure you get
the basic functionality working before you add bells and
whistles. The best way to approach extensions to the project is to
make your initial design flexible and extensible.
You should acquire background knowledge about Swing before attempting to code your GUI. You can see Sun's Swing tutorial (particularly the quick tour).
Do not try to use the realtime clock in order to determine timing
information. Instead, arrange to receive a timer event every
1/framesPerSecond and proceed to do the simulation and screen updates
in response to this event. If you get behind and time slows down, so
be it. A simple way to set this up is do use the
class, as in the example GUI. Using
this approach will simplify the implementation of your code and will
also avoid the need to deal with synchronization issues in a
If you are using Swing and wish to paint your own component, as you
will need to do in order to actually draw the board, gizmos, and ball,
you should extend
and implement your own paint routines. In order to do this you will
need to override the
method of your
JComponent to paint the board. The
painting is done by calling methods on the supplied
object. Unless you explicitly turn it off, Swing components are
automatically double-buffered to reduce flicker. If you do not
understand this, do not worry about it. In addition to
Graphics Java has an alternative graphics context
which provides more sophisticated capabilities than the traditional
Graphics object. Note that the calls your components
paint(Graphics) will always have a
Graphics2D passed as the argument, so if you want to work
Graphics2D, you may simply cast the
Graphics object. You may implement Gizmoball using either
style of graphics, but here are some differences which you might want
Graphicsobject works in terms of integer values for pixels allowing you to more directly control which pixels are updated.
Graphics2D, on the other hand, accepts floating point values to define geometric shapes to be rendered and performs the rasterization itself. This is somewhat more automatic, but also makes it more difficult to directly set individual pixels.
Graphics2Dclass also allows
AffineTransforms to be applied to it. (An affine transform is a geometric transform that preserves parallel lines.)
In order to respond to mouse and keyboard actions from the user you
will want to create and install
all of which can be found in the
package. Information about Java keycodes can be found in the
The specifications for handling keyboard input in Gizmoball require that an object connected to a key is triggered when that key is pressed or released. This provides behavior similar to that of a real pinball game: hitting the button causes the flipper to swing upward and releasing the button causes the flipper to return to its rest position.
The Java specifications for
describe three types of key events,
documentation suggests that
KEY_PRESSED events occur when
a key is actually depressed by the user and
events occur when the key is released. It would therefore seem
reasonable to trigger when receiving a
KEY_RELEASED event for a given key bound to a gizmo.
Unfortunately, most Java runtime environments fire multiple
KEY_PRESSED and in some cases multiple
KEY_RELEASED events when the user has only pressed the
key once. Additionally, in some environments you may never receive the
KEY_RELEASED events for an upstroke. This is because the
system dependent. The behavior occurs through an interaction with the
operating system's handling of key repeats that occur when you hold
down a key for a period of time.
On Windows and MacOS, Java will produce multiple
events as the key is held down and only one
when the key is actually released. For example, holding down the 'A'
key will generate these events:
KEY_RELEASEDare received as the key is held down:
If you want to explore the behavior of your in your environment,
you can use the
class provided by the staff. The application will dump all keyboard
events to the console for inspection.
The source code is available at
You should feel free to handle this nuance of the Java API as you
see fit. One easy solution is to shut off the operating system's
key press repeat mechanism and thereby cause the
KEY_RELEASED events to more closely correspond to the
actual actions of the user.
xset -r" to shut off autorepeat. To re-enable autorepeat use "
Accessibility Optionsapplet. On the
Keyboardtab select the
Ignore quick keystrokes and slow down the repear rate. Select the
Settings...button next to that option. Make sure
No keyboard repeatis selected. Slide the
Short(0.00). Press OK twice. Check
Use FilterKeysand press OK. To enable and disable these changes, simply check or uncheck the
Keyboard and Mouse. Select
Keyboard. Drag the
Delay Until Repeatslider to the
An alternative solution
is to take advantage of a special key listener
decorator provided by the staff. The class is available in compiled
form in the
gizmo.jar file as
staffui.MagicKeyListener. Refer to the
MagicKeyListener or use the
code as your own starting point.
Your implementation must support two modes of execution: building and running. In building mode, the user can add gizmos to the playing area and can modify the existing ones. In running mode, a ball moves around the playing area and interacts with the gizmos.
To describe dimensions in the playing area, we define L be the basic distance unit, equal to the edge length of a square bumper. Corresponding to standard usage in the graphics community, the origin is in the UPPER left-hand corner with coordinates increasing to the right and DOWN.
The playing area must be at least 20 L wide by 20 L high. That is, 400 square bumpers could be placed on the playing area without overlapping. The upper left corner is (0,0) and the lower right corner is (20,20). When we say a gizmo is at a particular location, that means that the gizmo's origin is at that location. The origin of each of the standard gizmos is the upper left-hand corner of its bounding box, so the location furthest from the origin at which a gizmo may be placed is (19,19) on a 20L x 20L board. The origin of a ball is at its center.
During building mode, Gizmos should "snap" to a 1 L by 1 L grid. That is, a user may only place gizmos at locations (0,0), (0,1), (0,2), and so on.
During running mode the animation grid may be no coarser than 0.05 L by 0.05 L. Suppose that the ball is at (1,1) and is moving in the (1,0) direction -- that is, left to right -- at a rate of .05L per frame redraw. Then the ball should be displayed at least in positions (1,1), (1.05,1), (1.10,1), and can be displayed at more positions if you wish the animation to be smoother. Rotating flippers can be animated somewhat more coarsely; see the precise description of flippers below. If the ball is moving faster than the animation grid size per frame redraw, it need not be redrawn in each animation grid position.
In building mode the user can:
In running mode, the user can:
In running mode, Gizmoball should:
There are seven standard gizmos that must be supported: bumpers (square, circular, and triangular), flippers (left and right), absorbers, and outer walls.
A coefficient of reflection of 1.0 means that the energy of the ball leaving the bumper is equal to the energy with which it hit the bumper, but the ball is traveling in a different direction. As an extension, you may support bumpers with coefficients above or below 1.0 as well.
A square shape with edge length 1L
Trigger: generated whenever the ball hits it
Action: none required
Coefficient of reflection: 1.0
A circular shape with diameter 1L
Trigger: generated whenever the ball hits it
Action: none required
Coefficient of reflection: 1.0
A right-triangular shape with sides of length 1L and hypotenuse of
Trigger: generated whenever the ball hits it
Action: none required
Coefficient of reflection: 1.0
Flippers are required to come in two different varieties, left flippers and right flippers. A left flipper begins its rotation in a counter-clockwise and a right flipper begins its rotation in a clockwise direction.
During run mode, a flipper should never extend outside its bounding box. In edit mode the flipper should not be permitted to be placed in any way which would cause the flipper to extend outside of its bounding box during run mode, or would cause the flipper's bounding box to overlap with (the bounding box of) another gizmo.
The below pictures show flipper placements for various initial rotations. In run-mode, when a flipper is first triggered, it sweeps 90° in the direction indicated by the arrows. If triggered again, the flipper sweeps back 90° to the initial position.
In the pictures, the shape and design of the flippers are for illustrative purpose only -- your final design may differ.
Flipper initial placements and initial directions of rotation.
As with the three standard bumpers, a flipper generates a trigger whenever the ball hits it.
When a flipper's action is triggered, the flipper rotates at a constant angular velocity of 1080 degrees per second to a position 90 degrees away from its starting position. When its action is triggered a second time, the flipper rotates back to its original position at an angular velocity of 1080 degrees per second.
If its action is triggered while the flipper is rotating, the exact behavior is at your discretion. Here are some suggestions, but you are not limited to these options:
The standard coefficient of reflection for a flipper is 0.95. However, when computing the behavior of a ball bouncing off the flipper, you must account for the linear velocity of the part of the flipper that contacts the ball; therefore the ball may leave the flipper with a higher energy than it had when it reached it.
When a ball hits an absorber, the absorber stops the ball and holds it (unmoving) in the bottom right-hand corner of the absorber. The ball's center is .25L from the bottom of the absorber and .25L from the right side of the absorber.
If the absorber is holding a ball, then the action of an absorber, when it is triggered, is to shoot the ball straight upwards in the direction of the top of the playing area. By default, the initial velocity of the ball should be 50L/sec. (With the default gravity and the default values for friction, the value of 50L/sec gives the ball enough energy to lightly collide with the top wall, if the bottom of the absorber is at y=20L.) If the absorber is not holding the ball, or if the previously ejected ball has not yet left the absorber, then the absorber takes no action when it receives a trigger signal.
Absorbers cannot be rotated.
A Gizmoball game supports exactly one set of outer walls. The user cannot move, delete, or rotate the outer walls. The outer walls lie just outside the playing area:
It is not required that the user be able to use the GUI to connect the trigger produced by the outer walls with any of the other gizmos. However, the standard file format does support this kind of connection.
But before Xerces can create these Java objects, it makes sure that the file it is reading in validates against an XML Schema. An XML Schema is a file written in XML that defines the desired format for other XML files.
We provide you with an XML Schema gb_level.xsd that defines the text format for a level of gizmoball that your application must be able to load and save to. Any XML file that does not validate against the schema should be rejected by your application, and an appropriate error message should be displayed to the user.
If you are new to XML, then you may first want to read the w3schools tutorial on XML. The API for Xerces is located at http://xml.apache.org/xerces2-j/javadocs/api/index.html, but a good example of the parser in action is available here.
The following is an example of a very simple gizmoball level file:
<ball name="Ball" x="1.8" y="4.5" xVelocity="-3.4" yVelocity="-2.3" />
<squareBumper name="Square" x="0" y="2" />
<circleBumper name="Circle" x="4" y="3" />
<triangleBumper name="Tri" x="1" y="1" orientation="270" />
<leftFlipper name="FlipL" x="10" y="7" orientation="0" />
<rightFlipper name="FlipR" x="12" y="7" orientation="0" />
<absorber name="Abs" x="0" y="19" width="20" height="1" />
<connect sourceGizmo="Square" targetGizmo="FlipL" />
<keyConnect key="32" keyDirection="up" targetGizmo="Abs" />
The ball tag specifies the initial position and velocity of the ball. Because the ball can be at intermediate points within a particular square, the coordinates are specified as floating point numbers. For example:
<ball name="Ball" x="1.8" y="4.5" xVelocity="-3.4" yVelocity="-2.3" />places a ball with name Ball, center at (1.8,4.5), and an initial velocity of 3.4L per second to the left and 2.3L per second upward.
Each gizmo has a name and a location (x and y coordinates) where it will be placed. The triangleBumper and the flippers all require an orientation. This orientation can be "0", "90", "180", or "270" degrees, and refers to the clockwise rotation of the gizmo.
Triggers can be connected to actions with the connect tag. In the example above, FlipL's action will be triggered whenever the ball hits the bumper named Square.
The keyConnect tag specifies that the action of a gizmo is associated with a particular key being pressed or released. For example:
<keyConnect key="32" keyDirection="up" targetGizmo="Abs" />specifies that the gizmo named "Abs" should be activated whenever the space bar key is released ("32" is the decimal number that represents a space in ascii). Type man ascii and scroll down to the "Decimal" section to view all the mappings from decimal numbers to ascii characters).
Because you might also want to allow the outer walls to trigger various actions, the special identifier "OuterWalls" is reserved for it:
<connect sourceGizmo="OuterWalls" targetGizmo="GIZ" />This command would cause the ball hitting any of the outer walls trigger the action of the gizmo named by "GIZ".
The main board tag can optionally take arguments for gravity and friction. If the board was described with:
<board gravity="16.0" friction1="0.0" friction2="0.0">the gravity in the game would be reduced to only 16L/sec2 and all effects of friction would be removed.
Here are the contents of the gizmoball file for the example shown at the beginning of this document. It specifies a triangular bumper in the upper right-hand corner, a bunch of circular and square bumpers, and a few flippers. The actions of the upper flippers are triggered by the "space" (ascii 32) key, the actions of the lower flippers are triggered by the "q" (ascii 81) and "w" (ascii 87) keys, and also by hitting some of the circular bumpers. The action of the absorber is triggered both by the "delete" key (ascii 127) and also by the absorber itself! This allows the game to run continuously. Every time the ball hits the absorber, the absorber immediately shoots the ball back upwards again.
<ball name="Ball" x="1.0" y="11.0" xVelocity="0.0" yVelocity="0.0" />
<squareBumper name="S02" x="0" y="2" />
<squareBumper name="S12" x="1" y="2" />
<squareBumper name="S22" x="2" y="2" />
<squareBumper name="S32" x="3" y="2" />
<squareBumper name="S42" x="4" y="2" />
<squareBumper name="S52" x="5" y="2" />
<squareBumper name="S62" x="6" y="2" />
<squareBumper name="S72" x="7" y="2" />
<squareBumper name="S82" x="8" y="2" />
<squareBumper name="S132" x="13" y="2" />
<squareBumper name="S142" x="14" y="2" />
<squareBumper name="S152" x="15" y="2" />
<squareBumper name="S162" x="16" y="2" />
<squareBumper name="S172" x="17" y="2" />
<squareBumper name="S182" x="18" y="2" />
<circleBumper name="C43" x="4" y="3" />
<circleBumper name="C54" x="5" y="4" />
<circleBumper name="C65" x="6" y="5" />
<circleBumper name="C76" x="7" y="6" />
<circleBumper name="C99" x="9" y="9" />
<circleBumper name="C109" x="10" y="9" />
<circleBumper name="C1110" x="11" y="10" />
<circleBumper name="C129" x="12" y="9" />
<circleBumper name="C139" x="13" y="9" />
<circleBumper name="C156" x="15" y="6" />
<circleBumper name="C165" x="16" y="5" />
<circleBumper name="C174" x="17" y="4" />
<circleBumper name="C183" x="18" y="3" />
<triangleBumper name="T" x="19" y="0" orientation="90" />
<triangleBumper name="T2" x="1" y="1" orientation="0" />
<leftFlipper name="LF92" x="9" y="2" orientation="0" />
<rightFlipper name="RF112" x="11" y="2" orientation="0" />
<leftFlipper name="LF87" x="8" y="7" orientation="0" />
<rightFlipper name="RF137" x="13" y="7" orientation="0" />
<absorber name="A" x="0" y="19" width="20" height="1" />
<connect sourceGizmo="C43" targetGizmo="LF87" />
<connect sourceGizmo="C54" targetGizmo="LF87" />
<connect sourceGizmo="C65" targetGizmo="LF87" />
<connect sourceGizmo="C76" targetGizmo="LF87" />
<connect sourceGizmo="C109" targetGizmo="LF87" />
<connect sourceGizmo="C1110" targetGizmo="LF87" />
<connect sourceGizmo="C139" targetGizmo="LF87" />
<connect sourceGizmo="C99" targetGizmo="RF137" />
<connect sourceGizmo="C1110" targetGizmo="RF137" />
<connect sourceGizmo="C129" targetGizmo="RF137" />
<connect sourceGizmo="C156" targetGizmo="RF137" />
<connect sourceGizmo="C165" targetGizmo="RF137" />
<connect sourceGizmo="C174" targetGizmo="RF137" />
<connect sourceGizmo="C183" targetGizmo="RF137" />
<connect sourceGizmo="A" targetGizmo="A" />
<keyConnect key="32" keyDirection="down" targetGizmo="LF92" />
<keyConnect key="32" keyDirection="up" targetGizmo="LF92" />
<keyConnect key="32" keyDirection="down" targetGizmo="RF112" />
<keyConnect key="32" keyDirection="up" targetGizmo="RF112" />
<keyConnect key="87" keyDirection="down" targetGizmo="RF137" />
<keyConnect key="87" keyDirection="up" targetGizmo="RF137" />
<keyConnect key="127" keyDirection="down" targetGizmo="A" />
<keyConnect key="81" keyDirection="down" targetGizmo="LF87" />
<keyConnect key="81" keyDirection="up" targetGizmo="LF87" />
<board gravity="FLOAT" friction1="FLOAT" friction2="FLOAT">
<ball name="STRING" x="FLOAT" y="FLOAT" xVelocity="FLOAT" yVelocity="FLOAT" />
<squareBumper name="STRING" x="INTEGER" y="INTEGER" />
<circleBumper name="STRING" x="INTEGER" y="INTEGER" />
<triangleBumper name="STRING" x="INTEGER" y="INTEGER" orientation="0|90|180|270" />
<rightFlipper name="STRING" x="INTEGER" y="INTEGER" orientation="0|90|180|270" />
<leftFlipper name="STRING" x="INTEGER" y="INTEGER" orientation="0|90|180|270" />
<absorber name="STRING" x="INTEGER" y="INTEGER" width="INTEGER" height="INTEGER" />
<connect sourceGizmo="STRING" targetGizmo="STRING" />
<keyConnect key="INTEGER" keyDirection="down" targetGizmo="STRING" />
<keyConnect key="INTEGER" keyDirection="up" targetGizmo="STRING" />
The formal definition of the file format can be found in the schema gb_level.xsd. Basically, the schema defines which elements it expects to see in an XML file and notes where the format may be extended. (These extension points are denoted by either <xs:any> or <anyAttribute>.) You don't have to understand the schema unless you want to extend it to support any new Gizmoball features you've designed. If you want to extend the schema, the XML Schema Tutorial will be helpful.
The provided physics library consists of
immutable abstract data types such as
as well as a class
that contains static
methods to model the physics of elastic collisions between balls and
other circles and line segments. You are welcome to use or not use
this code as you please, and to modify it to meet your needs.
Documentation for the physics package can be found in here.
Source for the physics library can be found in here. The jar file of our code is available here. While this source is provided in the event that you wish to examine or modify it, we strongly discourage you from modifying it. In the past, students who have not used the physics library as-is have had poor results on their projects. Most groups will not need to copy the source code to their own directories, add it to their CVS repositories, or compile it, but will just use the gizmo.jar file and examine the specifications.
The amendment has not been posted yet.