CompSci 308 : Spring 2026

Breakout: Detailed Specifications

Functional Specifications

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 2 levels, which must be distinct from one another in block configuration. The game should read the block configuration as a "picture" for each level from a data file so it is easy to compare the expected block pattern in both the text file and running program.
`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	Core	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	Core	When the game ends, a results screen should be displayed indicating whether the player won or lost and the final score. The screen may include other relevant game information such as lives remaining or power-ups used. This screen should remain visible until the user clicks or presses a key.
`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.
`BREAK-14`	Restart Game	Extension	When the game has ended, allow the user to start a new game.
`BREAK-15`	High Score	Extension	Display the highest score over multiple games played, either as part of the Game Status Display or the Results Screen (or both).

Choose at least two of the following (either provided via Power Ups or on different levels):

`BREAK-16A`	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-16B`	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-16X`	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-17A`	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-17B`	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-17C`	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-17X`	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-18A`	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-18B`	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-18C`	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-18D`	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-18X`	Power Up: Custom	Variation[3]	Design and implement a Power Up with a custom behavior different from the other Power Ups.

Choose at least five of the following, at least two being non-custom (see more cheat key ideas):

`BREAK-19A`	Cheat Key: L	Variation[6]	When the player presses the L key, their current life total should be incremented by 1.
`BREAK-19B`	Cheat Key: R	Variation[6]	When the player presses the R key, the ball and paddle should be reset to their starting positions.
`BREAK-19C`	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-19D`	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-19X`	Cheat Key: Custom	Variation[6]	Design and implement a cheat key with a custom behavior you define.

Design Specifications

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. For each project 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 feature “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	Divide 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	Consistent	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.

GIT Specifications

Version control is a critical skill to learn to manage the many changes that occur to your files over time. It allows you to revisit previous versions of your code, work with different versions at the same time, and work in teams and track who made which changes. Knowing how to use a source control system will be an invaluable tool for you going forward, perhaps personally or even potentially for changes in laws, but especially in a team setting.

To show you are practicing the process of using GIT effectively, your project repository must show many, purposeful commits rather than just one or two large “kitchen sink”, submission-style commits you are likely used to using.

ID	Name	Adherence	Description
`GIT-01`	Commit Message Format	Consistent	Commit messages must follow this format and must always reference either a feature or design requirement.
`GIT-02`	Feature Commits	Consistent	Make at least one commit for each feature you implement
`GIT-03`	Refactor Commits	Consistent	Make at least two commits for each design requirement that show the results of refactoring existing code to improve its design
`GIT-04`	Fix Commits	Consistent	Make at least one commit for each bug you fix after you have committed an existing feature
`GIT-05`	Close Issues	Forthcoming	Close or update Feature Issues as you make progress on them (sort of like a progress bar for programming). You can do this either on your project's Gitlab Issue page or by using keywords within your commits.
`GIT-06`	Tag Significant Commits	Forthcoming	Use Tags to identify important commits by memorable label instead of indistinguishable hash value. `git tag example`: use after an important commit (like completion of several related features or after the final version) `git push --tags`: use to push your tags to the course repository so others can see them