1. Regarding the paddle, typically, you want to allow the player to move the paddle only when
the ball is in their court. This ensures that they have control over their gameplay and can
attempt to hit the ball back to the opponent. When the ball is in the opponent's court, the player
shouldn't be able to move the paddle to maintain fairness.
2. When the ball is in your court, your program should allow the player to move the paddle to hit
the ball back to the opponent. On the other hand, when the ball is in the opponent's court, your
program should wait for the opponent to hit the ball back. The transition between these states
can be managed through communication between the two processes, indicating when the ball
has crossed over the net.
3. The ball travels from court to court through communication between the two processes,
representing the players on each side. The other process needs to know the position and
velocity of the ball, allowing it to accurately track the ball's movement. When the other process
sends the ball back, your program needs to know the updated position and velocity of the ball to
continue the game.
4. Keeping score can be done by tracking the number of successful hits made by each player.
Each time a player hits the ball back and the opponent lets it go by, a point is awarded to the
player. The game can be structured to end after a certain number of points or when a player
reaches a predefined score threshold.
5. The SPPBTP (Symmetric Paddleball Protocol for Two Players) helps address the challenges
posed by the preceding questions by providing a standardized protocol for managing
communication and gameplay between two symmetric programs. Unlike traditional client-server
pairs, where one side typically has more control, SPPBTP ensures fairness by allowing both
sides to send the ball over the net and potentially miss the ball. This symmetric approach
maintains balance and fairness in the gameplay experience.