AB202 Assignment 1: Arkapong

程序代写 CS代考 / c++代做

CAB202 Assignment 1: Arkapong

Due Date: 11:59PM Sunday 19 April 2015 Submission: to AMS
Marks: 30 (30% of your final mark)

For this assignment, you will be writing a program for a game called Arkapong, which is based on the arcade games Pong and Arkanoid / Breakout.

Requirements

Your task is to implement the Arkapong. You have been provided with skeleton code that uses the ZDK library. You have also been shown a demo version of the game (see the week 4 lecture), which implements some of the requirements for the assignment. You are not required to use the skeleton code or the ZDK library, but you are encouraged to do so. WARNING: We take plagiarism very seriously. If your assignment has material which has been copied from other class members, previous assignments, or code from any other source you will be penalised.

The score in the game should increase by 1 each time the ball is hit by a paddle on either side of the screen. The player starts with three lives. A life is lost when there are no active balls left on the screen. When the player has no lives left, a Game Over screen should be shown, and the Player should have the option to restart or quit.

All versions require the following basic functionality: [8 marks]

  • The game should start immediately
  • The paddle on right hand side of screen, initial height 5 characters, should be controlled by the up

    and down arrow keys

  • The paddle on the left hand side of the screen should be a large un-moving paddle that covers the

    screen from the top to the bottom

  • An information panel across the top of the screen should display the score, lives, and an indication

    of which features are currently in play

  • A line underneath the information panel should be the wall at the top of the game area
  • The score should be updated and displayed in the top left hand side of the screen within the

    information panel, where the score should be equal to the number of times ball collides with

    paddles and blocks (but not walls)

  • Lives should be updated and displayed in the top right hand side of the screen within the

    information panel, where the player starts with 3 lives and a life is lost when there are no active

    balls left on the screen

  • At the start of each game, the ball should start in the centre of the screen and move to the left at a

    random angle

  • A ball is considered inactive when it reaches the left or right wall (the side of the screen), and

    should disappear at this point

  • A ball that collides with the top or bottom wall (line across the top of the screen, bottom of the

    screen) should rebound off the wall at the reflected angle (that is, angle of incidence is equal to the

    angle of reflection, see Figure 1)

  • A ball that collides with the left or right paddle should rebound off the paddle at the reflected angle

    (that is, angle of incidence is equal to the angle of reflection, see Figure 1)

  • A game over screen should be shown when all lives have been lost, giving the player the option to

    quit (q) or restart (r)

  • The player should have the option to quit (q) and restart (r) at any point in the game

Figure 1 Angle of incidence = Angle of reflection

In addition to the basic functionality, the game should have the following options that can be toggled on and off during game play, by pressing the respective number of the option:

1. Left paddle [2 marks] Off:

  • The paddle on the left should be a large un-moving paddle that covers the screen from the top to

    the bottom On:

  • The paddle on the left should be controlled by simple AI that moves the paddle to the predicted location of the next ball to come to the left hand side

2. Straight vs Curved paddle [2 marks] Off:

  • A ball that collides with the left or right paddle should rebound off the paddle at the reflected angle

    (that is, angle of incidence is equal to the angle of reflection) On:

  • A ball that collides with a paddle on the left or right hand side of the screen should rebound off the paddle at the reflected angle, where the paddle is modelled as a curved surface (see Figure 2)
  • The paddle should correspond to an arc of at least 10 degrees
  • The paddle should still occupy the same space and can remain the same visually

    Figure 2 Curved Paddle

3. Points blocks [3 marks] Off:

  • No points blocks should appear on the screen On:
  • 10 blocks should be added at random locations on the screen that increase the score and disappear

    when hit by the ball

  • The ball should bounce off at the reflected angle as the block disappears
  • The size of each block should be at least 4 characters (2 by 2)
  • The whole block should disappear when one of the characters is hit (not just the hit character)
  • A new block should appear at a new random location after the hit block disappears

4. Increase paddle length block [2 marks] Off:

  • No increase paddle length block should appear on the screen, the right paddle should be 5

    characters high, the left paddle should be either 5 characters high or be the height of the window,

    depending on option 1 On:

  • A behaviour block should be added that increases the length of the paddle that hit the ball last
  • The block size should be at least 5 characters wide
  • The block should be located at a random position on the screen that changes every time the game

    is reset

  • Paddle sizes should be odd numbers between 3 and the height of the window
  • The ball should bounce off the block at the reflected angle
  • The block should disappear when hit, and a new block should appear at a new random location

5. Decrease paddle length block [2 marks] Off:

  • No decrease paddle length block should appear on the screen, the right paddle should be 5

    characters high, the left paddle should be either 5 characters high or be the height of the window,

    depending on option 1 On:

  • A behaviour block should be added that decreases the length of the paddle that hit the ball last
  • The block size should be at least 5 characters wide
  • The block should be located at a random position on the screen that changes every time the game

    is reset

  • Paddle sizes should be odd numbers between 3 and the height of the window
  • The ball should bounce off the block at the reflected angle
  • The block should disappear when hit, and a new block should appear at a new random location

6. Splitter block [4 marks] Off:

  • No splitter block should appear on the screen, a single ball should be used in the game On:
  • A behaviour block should be added that splits 1 ball into 2 balls
  • Up to 10 balls should be able to be in play at one time
  • When a ball collides with the block, one ball should bounce off the block at the reflected angle, and

    the other should reverse the direction (that is, go back the way that it came from), see Figure 3

  • The block size should be at least 5 characters wide
  • The block should be located at a random position on the screen, that changes every time the game

    is reset

  • The block should disappear when hit, and a new block should appear at a new random location

Figure 3 One ball splits into Two balls

7. Wind block [3 marks] Off:

  • No wind block should appear on the screen, the ball should move at the same speed throughout

    the game On:

  • A behaviour block should be added that toggles between no wind, wind to the left, wind to the right, wind up, and wind down, where all balls are affected
  • There should be some visible indication of the current wind, for example an arrow within the information panel
  • The speed of the ball should be increased in the direction of the wind and decreased in the opposite direction
  • The block size should be at least 5 characters wide
  • The block should be located at a random position on the screen, that changes every time the game

    is reset

  • The block should disappear when hit, and a new block should appear at a new random location

8. Ball Muncher [4 marks] Off:

  • No “Ball Muncher” should be implemented On:
  • A “Ball Muncher” sprite should be added with graphics, movement, timing, and behaviour
  • Minimum requirements are that the sprite should have a unique appearance made up of at least 10

    characters, should move around the screen, should appear at certain times (set or random), and

    should make balls disappear when hit (and therefore cause the player to lose a life)

  • Other actions could include decreasing the size of a player’s paddle, changing behaviour blocks

    Note that the game is not fully specified. It is up to you to choose which characters to use to represent each of the features of the game, how fast the ball moves, and any other details that have not been specified. However, to ensure that your game can be marked, you should be careful to follow all details that have been specified, and ensure that your game is playable. For example, if the ball moves so fast that it is difficult to play, or if selecting the option number does not toggle that option, we may not be able to test the different options that you have implemented.

    Marking

    The assignment will be out of 30 marks and will be worth 30% of your total grade in this subject.
    WARNING: If your code does not compile, you will get 0 marks for the entire assignment. If some of the options in your game results in a segmentation fault you will get 0 marks for this option. We will not debug your code to make it compile or run.

    Submission

    Your assignment is due on Sunday 19 April 2015 at 11:59pm. Submission will be online through the AMS used in the tutorials. In order to submit, you must use “Assignment_1” as the subject of your email. You should include all files used for your solution in a zip file as an attachment to the email. Your submission should include a README file indicating which options have been implemented. The format should follow the example file provided to you. You can include brief comments on additional functionality that you have implemented or known bugs.

    AMS will check that your code compiles but will not be testing that your program runs, and will not be testing for functionality. You will be able to submit the assignment up to 10 times. The functionality of your games will be tested by the lecturers/tutors based on the output from AMS. If your code does not compile and run, the lecturer/tutor marking your assignment will not test the functionality of your game, and you will receive 0 for the assignment.

Related Posts