$24
Synopsis
Implement a "breakout" game in Java.
Breakout is a simple 2D video game, originally published by Atari in 1976. "In the game, a layer of bricks lines the top third of the screen. A ball travels across the screen, bouncing off the top and side walls of the screen. When a brick is hit, the ball bounces away and the brick is destroyed. The player loses a turn when the ball touches the bottom of the screen. To prevent this from happening, the player has a movable paddle to bounce the ball upward, keeping it in play." (see Wikipedia.)
Breakout
Learning Goals
Learn how to build an interactive application using Java 8 and Swing.
Learn how to handle real-time drawing and animation of simple graphics.
Utilize model-view-controller to structure your application.
Breakout Description
There are many versions of Breakout playable on the web (here or here). You need to implement a simple version that includes the following features:
Your game should have at least 5 rows of colored blocks along the top of the screen, and a single paddle along the bottom. The player can move the paddle left and right across the screen.
When the game starts, a ball moves across the screen, bouncing off the side and top walls in a realistic fashion.
If the ball hits a block, the block disappears. If the ball strikes the paddle, it bounces. If the ball touches the bottom of the screen, the game ends.
You should keep track of the players score, awarding points for every bounce of the ball. Display the current score on-screen during the game.
Your game should play smoothly, and animate/repaint in a way that supports smooth animation (e.g. 24 FPS or higher by default, see below).
You also need to add one additional feature of your choice. For full marks, this feature should be a significant enhancement to gameplay. Changing colors/fonts, or making other superficial additions is not a sufficient addition, and will only result in part marks for this section (see below for examples).
Requirements
Implement a breakout game of your own design in Java 8, running on a desktop OS (Windows, OS X, or Linux). You are allowed to the Java 8 Platform libraries, but you are restricted to AWT and Swing for UI toolkits (i.e. no Java FX or SWF), and you are not allowed to use any other third-party libraries.
Your game should run in a window on the desktop. It should open with a splash screen that includes your name, userid, and a description of how to play the game (including a description of which keys to use).
Your assignment must meet the game description requirements listed above. As mentioned, you need to implement one additional feature of your choice.
You're encouraged to be creative in this assignment! Some portion of your grade is based on building an enjoyable and exciting game.
Your game must accept two command-line parameters: (1) "frame-rate", measured in frames per second, and (2) the "speed" of the ball in-game.
The frame-rate (FPS) will be used by your application to determine how frequently to redraw the screen. The ball may or may not move every frame, depending on the ball speed, but your application should always paint based on the frame-rate parameter. We'll test values from 25-50, and it playback should be smooth in this range. You can decide what values are valid for your game, and should reject values from outside this range. Changing the frame-rate should NOT change the speed of the ball.
The speed of the ball is some measure of the velocity of the ball. You should have at least three values, but you can determine how they are applied in-game. Please document in your README which values to use, and their meaning (e.g. 1=slow, 2=med, 3=high). The ball speed should be independent of the frame-rate.
Your game must use both the mouse and keyboard effectively. In-game actions should include the ability to move the paddle left and right, and quit the game. You are free to use any combination of key and mouse input that makes sense for your game.
Your game must respond to window resize events. The simplest (and perfectly adequate) strategy is to scale the drawings to fit the window size. You may limit the size of the window so long as the minimum size and maximum size are substantially different.
Assume that the TA marking your game is a terrible gamer. You'll want to tune the game so that it provides an enjoyable experience for novice gamers. If your game includes levels or features that are not apparent from the beginning of the game, you should include some sort of cheat function to allow the TA to quickly access that feature.
Include a gradle build file. `gradle build' should compile your program, and `gradle run' should execute it.
Your should use model-view-controller to structure your application. Although this application probably doesn't require multiple views, you should have separate model and view classes.
Finally, you should implement one additional game feature of your choice. This should be a meaningful feature that contributes to gameplay. Examples include:
Adding extra levels that appear when the current level is cleared.
Randomly selecting one of many levels, each with a different configuration, when the game is launched.
Adding power-ups that can be earned (e.g. special block that makes the paddle wider for a short period of time).
Submission
Check in to your personal Git repository, under the assignments/a2 folder:
All files required to compile and run your program (you don't need to submit .class file, since we'll build your app).
A readme.txt file with any instructions to the grader. We cannot grade something if we don't know about it! Make sure to include anything we need to know about your game and the features that you implemented.
Assessment
30%
Technical requirements met, including command-line parameters, and proper handling of mouse and keyboard events. There is no lag, and the screen resizes and repaints properly when provided a reasonable framerate (25-40 FPS).
40%
Working game that meets the basic gameplay requirements described above.
10%
Additional feature of your choice, properly implemented!
10%
Screen design, aesthetics, enjoyable gameplay.
10%
Model-view-controller implemented.
Versions
1.0. May 7. Initial release.
1.1. June 15. Added MVC.
1.2. June 18. Expanded the description of the command-line parameters. Added examples of gameplay features that could be chosen.