Shadow Bounce的開發

原文地址： Shadow Bounce的開發

Introduction

使用Bagel庫做爲GUI庫，實現一個叫Shadow Bounce的遊戲。

Game overview

Shadow Bounce is an arcade game where the player must attempt to clear the game board of pegs with a limited number of shots. Once the board is cleared, the player can progress to next board, and so on until all boards are cleared or the player runs out of shots, whereupon game should end. A turn begins either when the board is first loaded, or when all balls from previous turn have fallen o the bottom of the screen. red the the the

The player begins with 20 shots.

The game can be divided into three main types of objects: pegs, which can be destroyed to advance to the next level; balls, which are used to destroy pegs; and a powerup, which can be activated by striking it with the ball to get a bonus.

Boards are loaded from comma-separated value (.csv) files, numbered 0.csv (the first board) to 4.csv (the final board). You will not be tested on any other boards. Boards 1 through 4 will be released at a later date. Each line of these files is in the following format: type,x,y where type is the type of peg to be created, x is an integer representing the x-coordinate to create the peg at, and y is an integer representing the y-coordinate to create the peg at. The pegs should be created with their centre at these coordinates.

The pegs

Pegs come in three shapes:

• Normal pegs:

These are the usual circular pegs from Project 1.

• Horizontal pegs: these pegs are a horizontal rectangle shape.
• Vertical pegs: these pegs are a vertical rectangle shape.

They come in four types. Blue and grey pegs are specified in the board files; the others are created after the board is loaded.

• Blue pegs: these pegs have no special behaviour.
• Grey pegs: these pegs behave as the blue pegs, but cannot be destroyed.
• Red pegs: at the start of each board, one fifth (rounded down) of the blue pegs should become red instead. When all red pegs are destroyed, the game should advance to the next board.
• Green pegs: at the beginning of each turn, a random blue peg should become green. If the green peg is destroyed, two balls of the striking ball's type should be created at the green peg's position, with an initial velocity of 10 pixels per second diagonally upwards and to the left and right respectively. At the end of each turn, if the green peg was not destroyed, it should become blue again.

The balls

There are two types of ball the player has access to. In Project 2, balls should bounce o pegs they strike. If the ball strikes the peg from the top or bottom, it should reverse its vertical direction. Similarly, if the ball strikes the peg from the left or right, it should reverse its horizontal direction. The Rectangle class in Bagel contains a method to help you with this.

• The normal ball: this ball has no special behaviour. It is created in the same way as Project 1, and moves with the same gravity. Note: If your screen is too small to display the window fully, you may reduce the size of the window (by calling AbstractGame's constructor). The ball should then be created with an x value of half the window width, and a y value of 32. All pegs must remain visible.
• The fire ball: the fire ball behaves as the normal ball, except when it strikes a peg, all pegs within 70 pixels of the struck peg are destroyed. When the turn finishes, the ball returns to normal.

The powerup

At the start of each turn, with a 1/10 chance an powerup should be created at a random position on the screen. The powerup should choose a random position on the screen and move towards it at a speed of 3 pixels per frame. When the powerup is within 1 pixel of its destination, it should choose another random position. If the ball strikes the powerup, the powerup is activated and destroyed.

• Fire Ball: when this powerup is activated, the player's ball should be replaced with the fire ball.

The bucket

The bucket begins at the coordinate (512, 744). Note: As with the ball, if you need to reduce the window size, you can; the bucket should begin with an x value of half the window's width, and a y value equal to the window's height minus 24.

The bucket moves left at a rate of 4 pixels per frame. When any part of the bucket reaches the left or right sides of the screen, it should reverse direction.

If a ball leaves the bottom of the screen while making contact with the bucket, the player should get an additional shot.

Implementation checklist

This project may seem daunting. As there are a lot of things you need to implement, we have provided a feature checklist, ordered roughly in the order we think you should implement them in, together with the marks each feature is worth:

1. The board is loaded and visible on screen (1 mark)
2. Grey pegs cannot be destroyed (0.5 marks)
3. Pegs are randomly chosen to be red when the board is loaded (0.5 marks)
4. The game advances to the next board when all red pegs are cleared (1 mark)
5. The game ends when all boards are cleared or the player runs out of shots (0.5 marks)
6. A peg is randomly chosen to be green pegs each turn (0.5 marks)
7. When the green peg is destroyed, the extra balls appear and move correctly (1 mark)
8. Powerup appears and moves as described (1 mark)
9. Powerup causes fire ball (0.5 marks)
10. Fire balls destroy multiple pegs (0.5 marks)
11. The bucket functions correctly (1 mark)

Customisation

Optional: we want to encourage creativity with this project. We have tried to outline every aspect of the game design here, but if you wish, you may customise any part of the game, including the graphics, types of units, buildings, resources, game mechanics, etc. You can also add entirely new features. However, to be eligible for full marks, you must implement all of the features in the above implementation checklist.

For those of you with too much time on your hands, we will hold a competition for the best game extension or modification, judged by the lecturer and tutors. The winning three will be demonstrated at the final lecture, and there will be a prize for our favourite. Past modifications have included drastically increasing the scope of the game, implementing jokes and creative game design, adding polish to the game, and even introducing networked gameplay.

If you would like to enter the competition, please email the head tutor with your username and a short description of the modifications you came up with. I can't wait to see what you've done!

If you like, you may submit a minimal version of the game to be assessed, and email a second extended version to Eleanor. Extensions submitted this way may use any libraries you like, not just Bagel and the Java standard library.

The supplied package

You will be given a package, oosd-project2-package.zip, which contains all of the graphics and other files you need to build the game. You can use these in any way you like.

Submission and marking

Technical requirements

• The program must be written in the Java programming language.
• The program must not depend upon any libraries other than the Java standard library, the Bagel library, and Bagel's dependencies.
• The program must compile fully without errors.
• Every public method, attribute, and class must have Javadoc comments, as explained in later lectures.

Submission will take place through the LMS. Please zip your project folder in its entirety, and submit this .zip file. Do not submit a .rar, .7z, .tar.gz, or any other type of compressed folder.

Ensure all your code is contained in this folder.

Extensions and late submissions

If you need an extension for the project, please email explaining your situation with some supporting documentation (medical certificate, academic adjustment plan, wedding invitation). If an extension has been granted, you may submit via the LMS as usual; please do however email Eleanor once you have submitted your project.

(本文出自csprojectedu.com，轉載請註明出處)