CompSci 308 Spring 2024 |
Advanced Software Design and Implementation |
Below is a table of the project's expected functionality, following the format in the Functional Requirements Glossary (which describes the difference between Core, Variation, and Extension requirements). You are expected to implement all Core requirements, but only enough Variation and Extension requirements of your choice to validate you are making good choices to meet the Design Specifications.
ID | Name | Priority | Description |
---|---|---|---|
BREAK-01 |
Ball Movement | Core | When a player starts a level, the ball should be launched away from the paddle and continue moving in that direction until it comes into contact with a block, wall, or paddle. |
BREAK-02 |
Wall and Paddle Interaction | Core | When the ball comes into contact with a wall or the paddle, the ball should bounce off of the wall or paddle. |
BREAK-03 |
Basic Block | Core | When the ball comes into contact with a Basic Block, the ball should bounce off the block and the block should be destroyed. |
BREAK-04 |
Paddle Control | Core | When a player presses left and right arrow keys, the paddle should move so that the player can keep the ball from exiting the window. |
BREAK-05 |
Life Mechanics | Core | Designate one side of the window (usually the bottom) where the ball’s exit results in the player losing a life and the ball resetting. When the ball comes into contact with the designated side of the window, the player should lose a life and the ball reset to its initial position. |
BREAK-06 |
Level Progression | Core | When all blocks in a level have been cleared, the level has been completed. The game should load a new level with different block configurations and interactions. |
BREAK-07 |
Multiple Levels | Core | The game should include at least 3 levels, which should be distinct from one another in block configuration. The game should read the block configuration for each level from a data file. |
BREAK-08A |
End Condition: lose | Core | When a set number of lives have been lost (balls missed), the game should end. |
BREAK-08B |
End Condition: win | Core | When all levels have been completed, the game should end. |
BREAK-09 |
Game Status Display | Core | During game play, the game display should display the number of remaining lives and current level. |
BREAK-10 |
Splash Screen at Start | Core | When the game is first loaded, the game should display a splash screen detailing game rules. This screen should remain visible until the user clicks or presses a key to start the game. |
BREAK-11 |
Score keeping | Extension | The player should score points when events take place, for instance, destroying a block, receiving a power-up, and completing a level. The game display should display the current score. |
BREAK-12 |
Results Screen | Extension | When the user completes the final level, the game should display a results screen indicating whether the player won or lost and numbers of live remaining. The screen may include other relevant game information such as final score or power-ups used. |
BREAK-13 |
Splash Screen Between Levels | Extension | When a level is completed, the game should load a splash screen summarizing game state before loading the next level. This screen should remain visible until the user clicks or presses a key to advance to the next level. |
Choose at least two of the following:
BREAK-14A |
Paddle Behavior: Positional Bounces | Variation[2] | When the ball bounces off the paddle, the direction it bounces is determined by where on the paddle the contact was made (i.e., the middle third cause the ball to bounce normally, the left and right thirds cause the ball to bounce back in the direction it came). |
BREAK-14B |
Paddle Behavior: Catch | Variation[2] | When the ball comes into contact with the paddle, it pauses on the paddle. When the user presses a key, the ball is released. |
BREAK-14X |
Paddle Behavior: Custom | Variation[2] | Define a custom Paddle Behavior different from the other Paddle Behaviors. |
Choose at least three of the following, at least one being non-custom:
BREAK-15A |
Block Type: Power-Up | Variation[3] | When a power-up block is destroyed, the player receives a power-up. The power-up can be predetermined or randomly selected. |
BREAK-15B |
Block Type: Multi-Hit | Variation[3] | When the ball comes into contact with a multi-hit block, the block’s health is decremented. If the health reaches zero, the block is destroyed. For instance, if the block has 3 health, after it is hit three times, it is destroyed. |
BREAK-15C |
Block Type: Exploding | Variation[3] | When an exploding block is destroyed, it also destroys (or damages, in the case of Multi-Hit Blocks) neighboring blocks. |
BREAK-15X |
Block Type: Custom | Variation[3] | Design and implement a Block Type with a custom behavior different from the other Block Types. |
Choose at least three of the following (see more power up ideas):
BREAK-16A |
Power Ups: Paddle Extension | Variation[3] | When the player gets a Paddle Extension power-up, the width of the paddle is expanded to make it easier to block the ball. |
BREAK-16B |
Power Up: Extra Balls | Variation[3] | When the player gets an Extra Ball power-up, a new ball is added to the level. The old ball is not affected. While there is at least two balls on the screen and a ball contacts the edge of the window, the ball disappears but the player does not lose a life. |
BREAK-16C |
Power Up: Lasers | Variation[3] | After the player gets a Lasers power-up, when the player presses the space bar, a laser fires from the paddle. When the laser contacts a block, it damages/destroys the block. |
BREAK-16D |
Power Up: Speed Up | Variation[3] | When the player gets a Speed Up power-up, the speed of all balls increases. This makes the game progress faster but is more difficult. |
BREAK-16X |
Power Up: Custom | Variation[3] | Design and implement a Power Up with a custom behavior different from the other Power Ups. |
Choose at least six of the following, at least three being non-custom (see more cheat key ideas):
BREAK-17A |
Cheat Key: L | Variation[6] | When the player presses the L key, their current life total should be incremented by 1. |
BREAK-17B |
Cheat Key: R | Variation[6] | When the player presses the R key, the ball and paddle should be reset to their starting positions. |
BREAK-17C |
Cheat Key: 1-9 | Variation[6] | When the player presses any key 1-9, the current level should be cleared and the game should load the level corresponding to that key (or the highest one that exists). |
BREAK-17D |
Cheat Key: S | Variation[6] | When the player presses the S key, the level should be cleared and the starting splash screen loaded as if the game had just started. |
BREAK-17X |
Cheat Key: Custom | Variation[6] | Design and implement a cheat key with a custom behavior you define. |
This is your opportunity (perhaps for the first time) to think beyond the functionality — about how you want to organize a program and how to make your code readable. Throughout the semester you will be given a Design Specification, and you will be accountable for ensuring that your code's design meets the specification just like you are responsible for ensuring your code's functionality meets the Functional Specification. Keep in mind that design is more important than functionality for your final grade.
For this project, you can significantly improve the simplicity and readability of your code by refactoring it at least twice after you have gotten each level “working” (i.e., making multiple drafts to make sure you understand how every line works together and to get past the ugliness left over from all the things you tried just to “make it work”). Keep in mind, you should not expect to meet all the design requirements by simply getting it “working” right before the deadline.
Below is a table of the project's expected design goals, following the format in the Design Requirements Glossary. Future projects will include these specifications and add new goals.
ID | Name | Adherence | Description |
---|---|---|---|
DESIGN-01 |
Multiple Classes | Consistent | Divided code into several classes that each have a useful purpose (i.e., beyond just get/set methods). Avoid these code smells: large class and data clumps. |
DESIGN-02 |
Meaningful Names | Consistent | Give variables, methods, classes, and packages non-abbreviated, intention-revealing names to support Clean Code and reduce the need for comments. |
DESIGN-03 |
Named Constants | Consistent | Name constant values, including numbers and strings, used multiple times or in program logic. This includes being declared as final variables with an intention revealing name. |
DESIGN-04 |
Don’t Repeat Yourself (DRY) | Consistent | The same lines of code should not appear in multiple different places in the same project (i.e., they should not be duplicated). Instead, the code should be refactored so that the duplicated logic is written only once and called from many places. |
DESIGN-05 |
Interact Through Methods | Consistent | Classes should avoid inappropriate
intimacy by collaborating via method calls. A class should not
directly access the instance variables of another class. Do not use
public instance variables or global variables. |
DESIGN-06 |
Code Formatting | Forthcoming | Code should follow course formatting conventions, including things that cannot be automatically checked, especially the Java naming conventions. |
DESIGN-07 |
Tightly Scoped Methods | Forthcoming | Each method should be small with a single-purpose. Long methods should be decomposed into smaller pieces of functionality. Long methods are a code smell. |
DESIGN-08 |
Comments | Forthcoming | Follow Javadoc conventions for commenting on public classes, interfaces, methods, and packages. In-line comments should be used judiciously; self-explanatory code is preferred. See Internal Documentation. |