Reference no: EM131507929

Assignment: Brickles

Need solution for

https://www.expertsmind.com/questions/program-for-users-to-play-the-game-of-brick-30137058.aspx

Task

Write a Java program that allows users to play the game of Brickles. Download and unzip Brickles.zip, which provides a skeleton version of the program (note: it is up to you whether you want to use the skeleton). The program uses a predefined component, named BrickWall (provided in BrickWall.jar), to implement the game field. Consult the file javadoc/index.html for API information about BrickWall and its associated listener and event classes (CollisionEvent and CollisionListener). Note: (i) only use the provided BrickWall game field rather than implementing your own, and (ii) you need to include the BrickWall.jar file in your classpath by adding it to the Libraries in your NetBeans project.

Background
Games usually have relatively simple interfaces but need to be designed with considerable attention to appearance and aesthetics. The player will want to have the current state of the game clearly displayed during play, but will not want the screen cluttered up with less important information that is only needed occasionally. There are no hard and fast rules; you're welcome to implement the interface any way you think appropriate. Your goal here is to make a game that is "playable". Without going overboard, try to make the game something that people might actually want to pay money for. An example user interface is shown below.

Function Points

1. Reset and quit. Provide a way to reset the game and a way to quit the program. The operations should be subject to confirmation; if the operation is not confirmed, the action is abandoned.

2. Scoring. Add scoring to the game. The count of the number of bricks removed since reset should be displayed. For example, bricks in the topmost row (coloured red) might be worth 10 points each, with subsequent rows worth 5 points (yellow), 2 points (green) and 1 point (blue). If all bricks are removed, the game field is restored and the score continues. You also need to provide an interface for the user to specify the number of wall rows when the game starts.

3. Endpoint. Give the game a definite endpoint. For example, you might begin with a fixed number of balls (e.g. 3), and have the game stop when all balls have been lost. You also need to provide an interface for the user to specify the number of balls when the game starts and to view the number of balls available.

4. Difficulty levels. Provide a way to set the difficulty level of the game so that it is suitable for a variety of skill levels. For example. A game with a higher ball speed and a smaller bat size is more difficult to play.

5. High scores. Keep a list of the high scores for each game. When a new high score is posted, prompt for a player name and add the new score to the list. You'll also need a way to reset the list.

6. Save and restore. Add the ability to save and restore the high scores list and the state of any unfinished game. On shut down, the program should ask if the state should be saved. On start up, it should ask if the user wants to restore the saved game or start a new game.

7. Game types. Provide an interface that allows the user to choose between several games. For example, you might offer a Classic game with a single bat, a Ping Pong game with bats at both top and bottom, and an All In game with bats on all 4 sides.

8. Themes. Provide a way for the user to choose different colour schemes for the walls, the ball, and the bat. You may either give the user a set of predefined themes (choose your favourite colour combinations) to choose from or allow the user to individually specify the colours for the ball, the bat, and each wall.

9. Game dynamics. Make the game get progressively more challenging as the score increases. For example, you could have the ball move faster or the bat get smaller. You'll have to experiment with the various factors to strike a balance. You want it to be hard enough to be challenging, but not so hard as to be over too quickly.

10. Manual and Look-and-Feel. The user can set the look-and-feel of the program among a number of choices such as Metal, Nimbus, CDE/Motif, Mac OS X etc. The user can also access the manual describing how to play the game. The manual should be properly formatted with sensible choices of fonts, colours, images and so on.

Style Points

11. Appearance. The program presents an attractive appearance, including careful choice of colours and fonts, sensible choice and arrangement of components, and appropriate use of borders and other decoration.

12. Geometry. The program window opens at a suitable size and maintains an appropriate layout of components when made (reasonably) larger or smaller.

13. Code layout. Use indentation and white space to clearly display organisation and function. Apply layout rules universally and consistently.

14. Code structure. Match control structures to the tasks they perform. Declare variables only when necessary, and use appropriate scopes and types.

15. Code documentation. Document all external interfaces according to accepted conventions. Use internal documentation where necessary and where it adds value to the code.