Authors
- Angel Ortega (GitHubID:
agortega
) - Ben Patient (GitHubID:
bpatient24
)
W16_lab05 4PM
Mentor: Omeed Rabani (GitHubID: omeedrabani
)
The project is the game of pong, where two paddles hit a ball on opposite sides to try to get the ball past the opponent's paddle.
- As a player I can select pong difficulty level, so I can challenge myself or my opponent.
- As a player I can play with two players, so I can play with my friend near my keyboard.
- As a game winner I can set a highscore, so that I can attempt to beat other highscores.
- As someone who has never played cs56-pong, I can look at game instructions, so that I can learn how to play cs56-pong.
Yes, the game is in a running state, players can paddle the ball back and fourth till there is a winner & loser, but the highscore feature crashes when selected.
- As someone who likes customizing games, I can customize paddles or balls with colors or images so that my game looks prettier.
- As someone who likes interesting game modes, I can hold onto the ball when the ball hits my paddle.
- As someone who is prone to seizures, I can turn off the flickering balls and paddles so that I do not get a seizure.
- As someone who dislikes default Java Buttons, I can select game difficulties with paint graphics so that my pong game feels more authentic.
- As someone who wants the Pong UI to be extended across all the gameplay, I can enter a highscore in-game instead of with a pop-up.
- As someone who likes audio I can hear the ball hit the paddle, so that I can get direct feedback from the gameplay.
- As an audiophile, I can adjust audio volumes so that I can tailor the volume to my preference.
- As someone who has no friends to play cs56-pong with, I can play with an AI so that I can play all the time.
- As someone who can't see small objects, I can adjust the ball size so that I can see the ball better (or worse).
The description is great.
The diagram could use UML's instead of class diagrams. If methods and fields were indicated, then this would better show possible areas to refactor because we could see duplication or dependencies.
The build.xml could have a few more comments on targets.
Yes, there are enough issues for 1000 points and they are clear on expectations.
- High score feature crashes #37
- Pausing does not pause paddles #38
- Return to the menu button only works when a player scores #39 Features
- Add an AI opponent #40
- Add audio for when the ball is hit by a paddle #41
- Game menu uses paint graphics instead of default Java Buttons #43
Code is organized well. Some variables are named clearly. Theres also many comments indicating what each portion of code does.
Packages could be improved by seperating them. For example, GUI elements could be in a separate package and GameLogic in another.
Encapsulation should be enforced. All variables and methods are mostly public. This leaves the code open for anyone to modify existing elements. We wouldn't want a Ball object modifying a Screen object.
Many setters are called, perhaps we could use a builder pattern.
There are a few tests for the constructor but they are commented out, probably because they are failing. I'd say 1% is covered by tests.
To expand testing, we should start with each object separately. Then once each object was tested separately, we could test each of their separate method calls to make sure they are doing their expected behavior.
Some example tests are below: Test a ball being drawn, test a paddle being drawn. Test a paddle moving up, test a paddle moving down. test the score change. Test the ball doesnt move when the game is paused. Test the paddles don't move then the game is paused.