用Swing代写一款打砖块游戏，碰撞、反弹需要遵守物理公式。
Requirement
The wall is packing a thermonuclear device deep inside if its layers of bricks; two players must work together, firing shots to chip away at the bricks in an attempt to safely detonate the bomb before it goes off. Of course, once the wall is out of the way it’s all about being the last trebuchet standing! Players will earn points for:
- Hitting a brick.
- Taking out an entire horizontal row of bricks (causes the wall to drop vertically).
- Detonating the bomb.
- Collapsing the wall.
- Destroying the other trebuchet!
As with project 1, each player chooses and angle and a velocity for their shots. The trajectory is calculated in the same way.(https://en.wikipedia.org/wiki/Trajectory_of_a_projectile)
When a player fires a trebuchet, it has one of several results:
- It hits the ground - points are subtracted.
- It escapes the gravity of the planet - points are subtracted.
- It hits the enemy trebuchet, destroying it and awarding points.
- It hits a brick; points are awarded and the brick is destroyed.
- It hits the bomb; the bomb is safely detonated but destroys several bricks in every direction.
Depending on the bricks that are destroyed, the wall may change in some way.
Of course many other patterns of brick destruction are possible! Both players may chip away at their side of the wall, but if they do not destroy the bomb quickly enough it will detonate and end the game.
Please note that animation is not required! You simply need to display the “outcome” of the most previous round of play. It is OK if the game transitions instantly from the previous state (e.g. before the bomb is detonated) to the next state (e.g. after the bricks are destroyed)! But you will need to show which bricks are destroyed (see below).
Basic Rules
- At the beginning of the game, the wall will extend from the “horizon” to the top of the window. It should not be possible for a trebuchet to shoot over the wall. If the trajectory of a fired projectile causes it to “hit” the top of the window before it hits the wall, that projectile is considered to have escaped the planet’s gravity and will continue off into space, losing points for the player that fired the projectile. This means that players must break bricks in the wall in order to fire over the wall (and attack their frenemy).
- During each round of play, bothplayers must specify values for angle and velocity of the projectile and fire their trebuchets before the results are shown. This means that one player may go quickly while another thinks longer before moving. No results are shown until both players fire.
- Points are awarded as follows:
- a. -10 points for a shot that misses. This includes shots that hit the ground or escape the planet’s gravity.
- b. 10 points for each brick destroyed.
- c. 200 points for firing the shot that detonates the bomb.
- d. 500 points for destroying the frenemy’s trebuchet before the bomb is detonated.
- e. 150 points for destroying the frenemy’s trebuchet after the bomb is detonated.
- f. -400 points if the bomb detonates.
Graphical Requirements
- The wall, trebuchets, horizon/ground, and sky must all use different colors or in some other way be visually distinguishable from each other.
- The most recently destroyed brick(s) must be displayed in a different color for one round (e.g. the wall is red, recently hit bricks are pink).
- a. This includes entire rows that are destroyed (e.g. by a bomb detonating).
- b. This also means that the wall may be (significantly) shorter than it appears to be when shots are fired (i.e. because one or more rows have been destroyed). This is part of the strategy of aiming a shot.
- Bricks destroyed before the previous round should be displayed as “transparent” (e.g. using the color of the sky/background) to indicate that they are destroyed.
- The arc of the most recent shot from both players must be drawn after each round of play.
- a. The arc must extend through any destroyed bricks to hit bricks that are deeper into the wall.
- The name of each player (e.g. “Player 1” and “Player 2”), the current round’s score for each player, and total score (across multiple rounds of play) of each player should be displayed somewhere on the screen.
Suggestions
- Consider using a two-dimensional array to keep track of the state of the wall. Each element in the array is one “brick” that is either destroyed or not. Your custom JComponentcan use the array to determine whether or not to draw individual bricks. It’s also relatively easy to eliminate an entire row from a 2D array.
- Class design and reuse will be a BIG part of your grade for this assignment. While your main game may be implemented as a single custom JComponent, it will be extraordinarily difficult for a single class to keep track of all of the variables that make up this game. It will make implementing the game much easier if the JComponent uses different classes that are responsible for managing different parts of the game including:
- Trebuchets for both players.
- The wall.
- The bricks in the wall.
- The bomb.
- The trajectory of shots.
- Each of your classes should be relatively small and simple (compared to trying to write one giant program with hundreds or thousands of lines of code). You will be able to test these smaller classes individually to make sure that they work before piecing them together.
- Start early! You are given three weeks to complete this project and you will likely need to spend some time during each of those three weeks working on it. If you wait until the last minute to start you will find the project very challenging.
- Start simpleand work your way up to the more complicated requirements. You will earn a far higher grade by submitting a working game that doesn’t implement the most advanced features (e.g. the wall dropping when a row is destroyed, the bomb, drawing the trajectory of the projectiles, etc.) than you will submitting a broken game. Keep in mind that extra credit features can more than compensate for core features that are missing.
Miscellaneous Requirements
Your program must be well-formatted according to standard conventions for Java as seen in the textbook and in class.
Your program must be well-commented to explain what the code is doing. Code with no comments, or code whose comments are not correct will be penalized.
Your submission must be a ZIP archive containing your Java source files and any supporting files.
Your submission must also include a file named “README.txt” describing how to run your program, any design decisions you made that you feel the need to explain, and anything else that you think will help us understand your project.
Your program must keep track of each player’s total score across multiple rounds of play.
The players must be allowed to quit after (but not during) each game.
Extra Credit (not to exceed 20%)
You can get full points for accomplishing the requirements as described above. The following are some ideas for extra credit, up to a maximum of 20%.
Consider implementing a computer opponent that will play the game against a human player. The challenge is making a computer player that is challenging without being “too good” (it would be trivial to make a perfect AI for this). [up to 5%]
Consider randomizing characteristics (e.g. gravity, wind resistance) so that projectiles behave differently from one round to the next. [up to 5%]
Consider implementing keyboard controls rather than having users manually type in the angle and velocity (e.g. left arrow/right arrow to adjust angle, and up arrow/down arrow to adjust velocity of projectiles). You will need to include some visual cue that is not a preview of the projectile’s complete arc (this will make aiming trivial). You may consider an arrow that shows the starting angle and velocity (the longer the arrow, the faster the velocity). [up to 5%].
Consider implementing “bonuses” that are unlocked when specific bricks are broken (these should appear to be normal bricks). Maybe a player gets a “super shot” that breaks all of the bricks in its path, or a “bomb shot” that blows up on impact and destroys a 3x3 section of bricks, or gets to fire two shots in one round, or gets a preview of the arc of the next shot, or… [up to 10%]
Consider levels of difficulty: fatter walls, fewer rounds before the bomb blows up, lower gravity (and higher likelihood of “escaped” projectiles), random gravity!, etc. [up to 5%]
Any improvement to the user experience. Graphical improvements. Customized names. Animations. Images. [up to 5%]
Other ideas: document what you did clearly and prominently in your documentation. We’ll give you credit based on our assessment of how hard it was to do (but the total extra credit can never be more than 20%).