Reference no: EM131188379
Assignment: Pong
Overview-
The assignment is a variation on the Pong theme. The player controls a game paddle positioned near one edge of the terminal window which moves vertically but not horizontally. A ball flies within the playing area of the game, bouncing off floor and ceiling and one of the walls, but passing through the remaining wall.
Requirements-
Your task is to implement the Pong game. Throughout the semester, you have been provided with a number of examples of skeleton code for implementing games with the CAB202 ZDK library. You have also been shown a demo version of the game (see the Topic 3 lecture), which implements some of the requirements for the assignment. You are not required to use the ZDK library, but you are strongly encouraged to do so.
Game Specification-
The game has four levels which entail qualitatively distinct modes of play. Pressing the key labelled 'L' at any time during play advances the level by 1. After Level 4, the level cycles back to Level 1. There is no other way to progress between levels. For all levels, the following basic game functionalities need to be implemented in order for the game to work properly:
1. The game must adapt itself to occupy the full expanse of the terminal window at the time the program starts.
a. You may assume that the width of the terminal window is at least 60 units and the height of the terminal window is at least 10 units.
b. You may assume that the user will not resize the window while the game is running.
2. Help screen is displayed at commencement of game, prior to moving on to game itself.
a. Help screen must show the name and student number, plus a list of keyboard commands required to play the game.
b. Help screen exits when user "Presses any key".
c. Also displayed when user presses 'h'.
d. Also displayed after the game over dialogue, if user has selected "Play again", before moving on to restart the game.
e. While the help screen is displayed, all other game dynamics are frozen, including the elapsed game time.
3. After help screen at the start (or restart) of game, borders and game status display is shown. The status display shows:
a. Lives, initially 10 (or 3, or something reasonable).
b. Score, initially 0.
c. Level, initially 1.
d. Elapsed game time, measured in minutes and seconds, initially 00:00.
4. Ball is spawned at the beginning of play, and re-spawns each time it leaves the playing area, unless the game is over. Ball spawns in two stages.
a. Countdown (3, 2, 1...) for 0.3 seconds.
b. During the countdown all other game dynamics are frozen, including the elapsed game time.
c. Launch from centre of screen, travelling towards the player's end of the game in random direction within ±45° of horizontal. The speed of the ball at spawning should be set to some fixed value that yields a playable game, neither too slow nor impossibly fast.
5. Game border and info panel during play
a. Lives are reduced by 1 every time the ball passes out of the play area at the player's end.
b. Score increments by 1 every time the player's paddle strikes the ball (or vice versa).
c. Current level accurately reflects state of game.
d. Ball, paddles and other sprites never pass onto or over the boundaries.
e. Elapsed game time is updated in a timely manner once per second.
f. Elapsed game time records time spent in game. While any dialog (help screen, spawn countdown, or game over) is being displayed, the clock is stopped. After a dialog is cleared, elapsed game time resumes from the value it had at the time the dialog opened. That is, the clock is stopped while the game is paused.
6. The player's game paddle:
a. The player controls a paddle which is constrained to move vertically at one side of the playing area.
b. The paddle is placed so that there are exactly two columns of empty space between the paddle and the nearest vertical wall of the playing area.
c. The paddle must never protrude beyond the playing area, overlap the boundary, be obscured (in part or whole) by the boundary, or in any other way not fit properly inside the playing area.
d. The paddle must have a width of 1 screen unit and the height must be the minimum of the two values listed below:
1. 7 screen units; or
2. (h - hs - 1)/2 screen units, where h is the height of the screen and hs is the height of the status display.
When the ball hits the player's paddle, or the computer-controlled paddle (when in play, see Level 2) (NOTE: This section outlines the physics required for criteria on row 42 of the marking spreadsheet):
a. If the point of contact is not one of the endpoints of the paddle, the ball is reflected horizontally.
b. If the point of contact is the top endpoint of the paddle:
i. If ball is moving downward, AND distance from top of paddle to ceiling is greater than height of the ball - ball is reflected vertically, that is, it bounces off the top of the paddle and continues moving with its current horizontal velocity. If necessary, the ball may be shifted to the screen location immediately above the paddle to ensure it does not get stuck.
ii. Otherwise - ball is reflected horizontally, that is, it bounces off the side of the paddle, reversing its horizontal velocity.
c. If the point of contact is the bottom endpoint of the paddle:
i. If ball is moving upward, AND distance from bottom of paddle to floor is greater than height of the ball - ball is reflected vertically, that is, it bounces off the bottom of the paddle and continues moving with its current horizontal velocity. If necessary, the ball may be shifted to the screen location immediately below the paddle to ensure it does not get stuck.
ii. Otherwise - ball is reflected horizontally, that is, it bounces off the side of the paddle, reversing its horizontal velocity.
d. We are aware that this may occasionally produce slightly unrealistic physics: this is by design.
The assignment is to be done using cygwin. you would ZDK librqry file which i have attached.
Attachment:- Assignment.rar