代写一款叫Foon的RPG游戏,需要使用Java的 Inheritance
, Association
, Overriding
等概念。
![Inheritance](https://upload.wikimedia.org/wikipedia/en/thumb/0/0e/Multilevel_Inheritance.jpg/170px-
Multilevel_Inheritance.jpg)
The Assignment
This assignment is about effectively using inheritance, association,
overriding, and constructors. You’re going to work alone or with a partner to
translate a description of the inhabitants of a game world into a set of
classes that could serve as part of a model for a game or gaming utility, draw
the UML class diagram for these classes, and then implement them in Java.
Read the descriptions below carefully and try to take every detail into
account in your design. There might be multiple ways to implement each
attribute and ability. Just because your idea is different, doesn’t mean it’s
wrong.
The Inhabitants of Foon
In town of Hogsface in the magical land of Foon there are three kinds of
Humanoids: Elves, Hobbits, and Humans.
Attributes
All Humanoids have names that cannot change. They all have numeric ratings for
four attributes that describe their abilities: Strength, Dexterity, Armour and
Moxie. These attributes can be raised or lowered by one point at a time,
within the range 0 to 20. The name and basic attributes of a humanoid are
obvious and can be easily retrieved by anyone.
All Humaniods have 0 or more coins. They all have a numeric health rating. If
they have health greater than 0 they are alive, otherwise they are dead.
Every Elf belongs to either the “forest” or “city” clan. They proudly display
their allegiance and never change it.
Every Elf has exactly one Hobbit that they consider their best friend. But
they are fickle and frequently change their minds about who their best friend
is.
Many Humans have an Elf who is their sworn enemy. This enemy is fixed at birth
and never changes, even if it dies.
A Human can be a Fighter or a Wizard. Wizards have a numerical magic rating
from 0 to 20.
Abilities
Attack and Defense
When a Humanoid other than a Fighter attacks, it produces a damage score equal
the average of its strength, dexterity, and health. When a Fighter attacks, it
does twice the normal damage.
When a Humanoid defends itself against an attack, it will lose health points
equal to the damage score of the attack divided by its armor rating (or 1,
whichever is greater).
Dead humanoids cannot attack or defend themselves.
Stealing
A Hobbit can steal money. When a Hobbit steals, it produces a success score
equal to its dexterity divided by 2. Dead Hobbits can’t steal.
Healing
When a wizard casts a healing spell, it produces a health boost score equal to
its magic rating divided by 2, but it loses 3 points from its magic rating. If
its magic rating is 0 or less, it cannot cast the spell. Dead Wizards can’t
heal.
The Design
Draw a UML class diagram for a set of classes to represent the inhabitants of
FakeWorld. Make sure to represent all instance variables, parameters, return
values, and relationships between classes. You can create your UML diagram on
paper, using UMLet or using draw.io. If you want to use a different piece of
software, check with your instructor first.
Use inheritance to eliminate code duplication and overriding to avoid if
statements (e.g. don’t have an if statement to check if the humanoid is a
fighter before reporting damage).
Use encapsulation to restrict access to the instance variables.
Include the minimum set of methods to implement the world as described above.
Include two constructors for each class: one that sets all instance variables,
and one that sets just the name and fills in default parameters for everything
else.
Include a toString() method for every class that prints the class name, the
name of the humanoid, whether they are alive or dead, and all their ratings
(health, strength, etc.). Make sure the output is easy to read.
The Implementation
Implement the classes you designed in Java.
It would be a good idea to test each class by creating at least two instances
(one for each constructor), calling each method, and printing the results of
each method to standard output. But this is not required. For this assignment,
you are developing the model but not the view.
Use automatic code generation as much as you can (“Insert Code” to create
constructors, getters, setters and toString() methods).
Use the super and this keywords to eliminate code duplication wherever
possible.
Check for errors in all methods (e.g. parameters out of range, null
parameters, actions can’t be taken when the Humanoid is dead, etc.). If an
error happens, print a meaningful error message to standard output and return
immediately from the method. Make sure you test the error cases.
Optional Extras
This is purely a design exercise, but maybe it could be turned into some sort
of a game. For example, can you simulate turn-based combat between a Hobbit
and a Wizard? Can you make it graphical? Is there anything else you can do to
make the town of Hogsface to life?
Handing In
You have approximately 1 week to complete this assignment. See the due date
and time on the drop box. Hand in by attaching a zipped version of your .java
(not .class) files and your class diagram to the drop box.
Make sure you follow the Documentation Standards for the course.
Special Instructions for Pairs
If you work with a partner, follow these special instructions:
- Both partners should work together on the design and the implementation. Use pair programming when writing the code.
- Both partners must hand in a copy of the design and the implementation for this assignment. Late days for each partner will be tracked separately.
- Each partner must also fill out the “statement of effort” and include that in the hand in.
Warning: If you do not include a statement of effort, it will be assumed that
you worked alone, which means that your solution better not match anyone
else’s!
Evaluation
Your assignment will be evaluated for design (40%), implementation (40%), and
documentation (20%) using the rubric in the drop box.