代写COMP2011J、Java程序设计代做

项目预算：开发周期：发布时间：要求地区：

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