代写COMP2011J、Java程序设计代做

日期：2024-11-14 08:50

Beijing-Dublin International College

COMP2011J - Object Oriented Programming

Individual Assignment: Defender

Assignment Details

Due date: 6

th of December 2024

Language: Solution must be completed in Java

Game Description

Defender is a classic arcade game where the player flies a spaceship destroying alien invaders over a planet.

Defender is a side-view, horizontally scrolling shooter set on the surface of an unnamed planet. The player

controls a spaceship flying either to the left or right. The player can control the elevation of the ship as well as

fire weapons and make a hyperspace jump.

The object is to destroy all alien invaders, while protecting astronauts on the landscape from abduction.

Landers pick up humans and attempt to carry them to the top of the screen at which point they turn into

fast-moving mutants. A captured human can be freed by shooting the lander, then catching the human before

it falls to its death, and dropping it off on the ground.

Defeating the aliens allows the player to progress to the next level. Failing to protect the astronauts results

in the level being lost (and started again if you have remaining lives). A ship is lost if it is hit by an enemy or

its projectiles, or if a hyperspace jump goes wrong (as they randomly do). After exhausting all ships, the game

ends.

1

Movement

The players ship can move up and down on the screen. When it does the screen does not move. The players

ship can not go any lower than the bottom of the screen or any higher than the top of the screen.

As the player moves left and right the screen should move to show more of the level. The player ship should

be kept in the middle half of the screen. That is when the player is in this area, the screen should not move.

However, if the player is going to move outside of this area, then the view of the level should be changed so the

player remains in the middle half of the screen.

For the players ship moving left and right the important element of movement is momentum. The player’s

ship should continue travelling in the same direction at the same speed unless some acceleration is applied. So

when the players ship begins moving and no more thrust is applied, it will continue in the same direction and

at the same speed forever unless the ship crashes into an alien. The direction that the ship travels is based on

the direction that the ship was facing when the thrust was applied. If no thrust is being applied, then the ship

can face in any direction while it keeps moving in the direction of the original thrust.

Enemies

There are two types of enemies in the game, Landers and Mutants.

Landers will fire at the player’s ship, but their primary goal is to grab on of the humans from the surface

and carry them to the top of the screen. One the lander reaches the top of the screen carrying a human they

will become a mutant. If a lander is destroyed while they are carrying a human, the human is dropped and

must be caught by the player. If the player does not catch the human, they will die when they hit the ground.

If the player catches a human, they can place them back on the ground by dropping down to that level.

Mutants are much faster than landers. Instead of attempting to pick up humans, mutants only purpose is

to kill the player. They will chase after and fire at the player.

Points/Scoring

Points are awarded for destroying the asteroids based on the following calculations:

• Lander destroyed → 150 points each

• Mutant destroyed → 300 points each

• Human captured and mutated → -150 points each

• Human saved → 500 points each

Levels

The number of humans and enemy landers is based on the level. As levels increase there should be more landers

and less humans on the level.

A level is not completed until all of the enemy ships have been destroyed. This may require the player to

search across the landscape to find the remaining enemies.

Example

To get an example of the how the defender game plays, go to the https://www.free80sarcade.com/defender.

php and play the game there. This version of the game has a larger number of enemy types and is quite difficult.

The version I am requiring you to create only requires two types of enemies and can be made easier (by making

the enemies move more slowly).

Assessment

This section gives a breakdown of the approximate marking criteria for the assignment. The final marking

scheme may vary slightly but will be relatively similar. Your submission should contain the following files

• A zip file containing the entire project code and any other files required for the code to be executed

(exported from IntelliJ IDEA or Eclipse)

2

• A report explaining what you have achieved for each of the criteria in the marking scheme (estimate fail,

pass or excellent) based on the template provided

• A short video (less than 3 min) showing a screen recording of the game with your explanation voiced over

it

Each file should be named only with your UCD student number and the correct file extension (e.g. 1234567.zip,

1234567.pdf, and 1234567.mp4).

Zip File

This must contain all of the code required to execute the project. If I am unable to execute your code, it will

reduce your grade. If there are any requirements to setup and execute your code you should include these in

the zip file.

I will be testing the code using IntelliJ IDEA (unless you specifically mention that I should use Eclipse). I

would recommend that you create the project using the Intellij IDEA IDE and export the entire project to a

zip file for submission.

Assignment Report

This document should be in PDF format and contain your name and student number as well as a table explaining

what you estimate of how your project will be graded against the marking criteria in the next section. For each

of the criteria mark an X under Fail, Pass, or Excellent and optionally include some text to explain why you

believe you have merited that level. You may also include details in this report of any additional functionality

that you have added that you believe should be worth extra credit.

Marking Scheme

The marking scheme shown in table 1 is subject to change. This means that it may be changed at any time

without notice if I feel some parts were too easy or too hard and additional criteria may be added. The final

grade from this section will be based on a weighted sum of the individual parts. The weights for each part will

be based on the difficulty and importance. For example, design and cohesion is very important and will likely

be weighted much higher than any other component.

The text explaining each can be used as a guide to the amount of work expected for the different parts of

the assignment.

You should also note that it is required that your project is programmed using one of the two libraries avail able on moodle (https://csmoodle.ucd.ie/moodle/mod/folder/view.php?id=74336 or https://csmoodle.

ucd.ie/moodle/mod/folder/view.php?id=74337). If you do not use one of these libraries, then you will get

0 for your assignment grade.

Additional Criteria

In addition to the above, your submission will also be considered under some more criteria. These however are

only used to reduce your grade if you have performed poorly and will otherwise have no effect.

• Naming of variables, methods, class, interfaces, enumerated types or anything else in your code

• Following naming conventions for the above

• Code formatting and commenting1

• Correct formatting of submitted files (e.g you will lose points for submitting a doc file instead of a pdf,

mkv instead of mp4, or rar instead of zip)

• Incorrect naming of any submitted files

• Not including name and student number in report (or including an incorrect student number)

1

I do not expect a large amount, but at the least there should be an explanation of the use of each class

3

Item Fail Pass Excellent

Design and Cohesion

Package Struc ture

No packages are used Separate packages are used, but the

classes are not well organised (split be tween game model and UI)

Separate packages are used and each

class is placed in a sensible package

(split between game model and UI and

potentially with subpackages)

Logical Struc ture

The structure of the

classes is unnecessar ily complicated

There is a logic to the structure of the

code (use of inheritance, composition

and interfaces) but it is not always well

applied

There is an excellent logic to the struc ture of the code (use of inheritance,

composition and interfaces) and it is al ways well applied

Responsibilities

of Classes

Many classes are

created with too

much responsibilities

within them

Some classes are created with too much

responsibilities within them

All of the classes defined have a reason able level of responsibilities

Cohesion Responsibilities of

many classes are not

related

Responsibilities of some classes are not

related

All of the classes defined have responsi bilities that are related to each other

Methods Methods are poorly

named, do not use

camelCase and are

frequently longer

than 30 lines of code

Some methods have descriptive names,

and are mostly not larger than 30 lines

of code

All methods have descriptive names, are

written in camelCase and are mostly

not larger than 30 lines of code

Other Criteria

Input User input is not com pleted

User input is completed but not all ac tions are implemented

User input is completed and all actions

are implemented

Display No shapes are drawn

on the game screen

Some of the shapes are drawn on the

screen, or they are implemented using

images loaded from files

All required drawable objects are imple mented in code by specifying the coor dinates that individual pieces should be

drawn at

Menu No menu or other op tions are shown, game

moves straight into

gameplay

Main menu is shown before gameplay

starts

Game contains a main menu, hall of

fame display (high scores) and an info

screen showing the controls for the game

Collisions Collisions between

the players ship or

bullets and other ob jects is not completed

Some of the collisions are detect, but

some others are not

All required collisions are detected by

the game

Difficulty/Levels There is no change to

difficulty or multiple

levels are not imple mented

There are some changes in difficulty, but

they are not consistent (too big or small)

There are small but consistent changes

in the difficulty of the game as the levels

increase

Movement of

Player

Movement is not as

specified in the de scription above

Movement is implemented correctly, but

there some problems

Movement is implemented correctly

Movement of

Aliens

Aliens are not imple mented or move in

simple straight lines

Aliens are implemented and move to wards the humans on the ground

Aliens are implemented and move in

correct directions (lander to humans,

lander with human to top, mutant to wards player)

Alien Shooting Aliens are not im plemented or do not

shoot

Aliens are implemented and shoot in

random directions

Aliens are implemented and shoot in the

direction of the player

Appraisal No Appraisal was in cluded

The appraisal was very inaccurate, and

claimed the project was better than the

code showed

The appraisal was very accurate, and

highlighted areas where the project met

or exceeded the project specifications as

well as areas where it did not meet them

(if applicable)

Table 1: Indicative Marking Scheme for Assignment

4