Onboarding Project: Breakout Game, Part 3

This exercise is the final part using Breakout Game and is intended for you to practice creating abstractions, i.e., superclasses, and using them polymorphically, i.e., without worrying about the exact subclass implementation. Thus best way to think about abstractions is to focus on their active behavior, i.e., methods, rather than state, i.e., instance variables, so that the public methods do rely on different implementation details.

It will not be explicitly graded but, instead, serve as a starting point for us to see your coding strengths and weaknesses (and how well you follow directions). Thus, you will get the most out of this assignment by putting in a good faith effort.

Submitting Your Work

Continue to work in your provided GIT repository, breakout_NETID, hosted in the course's Gitlab group.

As your submission for this project, use GIT to add, commit, and push the following:

• src/main/java folder: all project code
• src/main/resources folder: any images or block configuration files
• top-level (no separate folder): project README, and otherwise no other files created by you

Your code is expected to follow the course coding conventions and be reasonably commented (full Javadoc comments are encouraged but not required yet).

Specifications

Individually, continue to work on your game of Breakout, refactoring your existing code to improve its design while creating abstractions to support as many of these new functionality features as you can:

• Blocks. Make at least three functionally different kinds of blocks, denoted by different values in the level data file and displayed differently on the screen
  Such as requiring multiple hits to destroy (include some indication of this, like changing color on each hit or displaying a countdown, so it is clearly a feature and not a bug), exploding and destroying nearby blocks, moving or spinning, etc.
• Paddle. Make at least three different abilities for the paddle, one for each level
  Such as making the ball bounce differently depending on where it hits, "catching" the ball when it hits the paddle and releasing it at a later time when a key is pressed, warping from one side of the screen to the other when it reaches the edge, etc.
• Power-ups. Make at least three functionally different kinds of power-ups, these can either be made randomly or included in your level data file
  Such as making the paddle longer, speeding up the ball, giving the player extra bouncing balls to use to clear blocks, giving the player lasers with which to destroy blocks, etc.
• Levels. Make at least three different kinds of levels that differ functionally, in addition to having a different starting configuration of blocks
  Such as neighboring blocks of the same type are destroyed together, special non-block areas of the screen change the ball's speed, direction, etc., new blocks randomly fill in empty spaces left by destroyed blocks, a boss enemy hiding behind the blocks, etc.
  Note, this cannot be simply making the game "harder" by only changing some variable values like the ball's speed, the paddle's size, or the blocks' position
• Cut Screens. Make at least four different screens: starting the game, between each level, and at the end of the game that stay visible until the user clicks or presses a key and whose displayed text is read from a file
  Each kind of screen should have a different behavior, such as: scrolling the text, showing progress on a "quest", adding time or life-based bonus scores to the current score, showing simple "scripted "animation (e.g., telling a "story"), allowing the user to restart playing the game without quitting, prompting the user to input a name or initials if they achieved a high score, etc.
• Cheat keys. Add additional cheat keys, documented in your README, including at least the following:
  • 'D': destroys the "first" remaining block on the screen (your team should decide, and document, what first means for your version of the game)
  • 'X': change the ball's direction to turn towards a block (it could be the nearest one, a random one, or whatever makes sense for your game)
  • at least three other actions of your choice: here are tons of ideas for other cheat codes

The basic version of Breakout was designed by Steve Jobs and Steve Wozniak (the founders of Apple, Inc.) and it continues to have appeal because it easily supports complex variants, such as:

• Super Breakout: power ups such as multi-ball triggers and laser shots from the paddle
• Jet Ball: variety of blocks that move in interesting patterns, advertised as "the most challenging block-breaker in the app store"
• Brick Breaker Escape: includes coins and inventive power-up options and level changes
• Vortex: originally for the iPod, puts the blocks in the middle of the screen with the paddle moving around the outside (like a scroll wheel :)
• Pinball Breakout: this is just one of the many attempts to combine Pinball and Breakout style games
• Bricks n Balls: adds mechanics of aim, tap, and shoot from Bubble Shooter games to create a puzzle game feel
• Centipong: the moving centipede is the blocks and when they are hit it generates more balls
• Brick Breaker Hero: few, but interesting, blocks but incorporates boss enemies as the primary goal
• Devilish: a scrolling version of the game, where clearing the blocks just opens up the passage allowing you to the fly through
• Fairy Treasure: amazingly beautiful, fantasy version of the game with many different kinds of balls, power ups, blocks, and other kinds of obstacles
• Here is a (long) video of the original Arkanoid game play and here is an entire YouTube channel devoted to it!

Study these for their ideas for functional variations, not their appearance or level of sophistication.

We strongly suggest you refactor the code, creating more methods and classes, before attempting to implement any of the new features.

GIT

Practice using GIT effectively using many, small, purposeful commits with good commit messages rather than just one or two large "kitchen sink" or "submit-only" commits.

Design Goals

Practice the following mindsets about code to help you acclimate you to the course's overall Design Goals:

• multiple classes: divide your code into several classes that each have a single, useful, purpose (i.e., non-get/set methods) to avoid these code smells: Large Class and Data Clumps
• abstractions. create inheritance hierarchies to define common methods that can be implemented in multiple ways in separate concrete classes to avoid these code smells: "Switch" Statements and Data Class
• encapsulation. hide implementation details such that they can be changed while minimizing the need to think about or impact on other classes to avoid these code smells: Inappropriate Intimacy and Divergent Change

We strongly recommend refactoring your code at least twice beyond getting it working, like making multiple drafts, to ensure your code is as readable as possible and that every line works together and shows your design intent.

Resources

• Refactoring code automatically with IntelliJ