代做program、代写Python，Java程序

日期：2023-09-10 10:13

Assignment 1

Learning Outcomes & Materials

This assignment is intended to develop and assess the following unit learning outcomes:

LO1. Iteratively apply object-oriented design principles to design small to medium-size software systems,

using standard software engineering notations, namely UML class diagrams and UML interaction diagrams.

LO2. Describe the quality of object-oriented software designs, both in terms of meeting user requirements

and the e ective application of object-oriented design concepts and principles.

L03. Apply object-oriented programming constructs, such as abstraction, information hiding, inheritance, and

polymorphism, to implement object-oriented designs using a programming language (namely, Java).

LO5. Apply principles of software engineering practice to create object-oriented systems with peers using tools

including integrated development environments (IDEs), UML drawing tools, and version control systems.

To demonstrate your ability, you will be expected to:

read and understand UML design documentation for an existing Java system

propose a design for additional functionality for this system

create UML class diagrams to document your design using a UML drawing tool such as

diagrams.net, UMLet or plantuml – you are free to choose which one

write a design rationale evaluating your proposed design and outlining some alternatives

implement the features of the system that you designed

use an integrated development environment to do so

use git to manage your team's  les and documents

The marking scheme for this assignment will re ect these expectations

Learning Materials

The base code will be automatically available in your group's repository (Gitlab).

Repeat this mantra: Design, write code, test,  x design,  x code, repeat  

Note: You must NOT follow demo apps' design decisions; they only show how to use the engine, NOT how

to design a proper system with object-oriented principles.

Introduction

For the rest of the semester, you will be working on a relatively large software project. You will design

and implement new functionalities to an existing system that we will provide to you.

IMPORTANT: A document explaining the FIT2099 Assignment Rules is available as the Assignment Survival

Kits lesson. Please read it and make sure you understand BEFORE you begin the project – you are expected to

follow what it says and will almost certainly lose marks if you do not.

In this assignment (Assignment 1), you will be working individually to implement the  rst few

features of the game. We highly recommend starting by extracting the whole game features. Then,

proceed with designing, testing, and repeating the process as needed. This iterative approach will

help ensure a well-developed and re ned system.

Getting Started

The initial codebase will be available in a repository that will be created for you on

git.infotech.monash.edu. In the meantime, please go through the assignment support modules on Ed

Lesson to familiarise yourself with the game engine that you will use during the assignment.

You do not need to submit an interaction diagram (e.g. sequence diagram or communication diagram) in

assignment 1. However, you will need to submit these documents for Assignment 2 and Assignment 3. For

assignment 1, you may still create these documents if you  nd them useful for designing the system.

General background

You will be working on a text-based “rogue-like” game. Rogue-like games are named after the  rst

such program: a fantasy game named Rogue. They were very popular in the days before home

computers were capable of elaborate graphics and still have a small but dedicated following.

If you would like more information about rogue-like games, a good site is http://www.roguebasin.com/. The

initial codebase will be available in the repository mentioned above. It includes a folder containing design

documents for the system.

Designborne

In this assignment, we will be developing the “Designborne” game, inspired by the games such as

Dark Souls, Elden Ring and Bloodborne. We may use several similar names (characters, items,

locations) and concepts. The purpose of using an actual game’s concepts is to help you visualise the

required features, such as watching the video gameplay from the actual game to illustrate features

that you may  nd di cult to comprehend. We also believe that using actual game references can

bring fun while working on the assignments.

All of the linked game contents, videos, and images belong to the respective owners and are subject

to copyright. We mainly use the concepts for educational purposes and provide credit to the original

creators accordingly. We may also add, alter, and reduce the original content and features to make

them more suitable to the game engine, unit outcomes, and assignments’ time frame.

What’s next?

Below are  ve slides (REQ1-REQ5) describing the requirements you need to complete. Each

requirement includes game features that include background stories, entity descriptions (actors,

items, or ground), relationships between entities, and actions between them. We suggest extracting

these features into a list and discussing it with the TAs to ensure all features are included (this

discussion is not assessed, but highly recommended). Following these requirement slides, we will

outline the deliverables necessary for the Assignment 1 assessment.

REQ1: The Player

In “Designborne”, you play as “The Abstracted One”, who has been revived by an unknown entity in

the starting location, “The Abandoned Village”.

At the beginning of the game, the player has 150 hit points (the health attribute) and 200 stamina.

They start the game by waking up in the building in the middle of the map. A building is simply

several squares of  oor (`_`) and dirt (`.`), surrounded by walls (`#`). The display character of the

player is “@”.

Figure 1. Example of buildings in the game (red squares). They consist of walls, dirt, and  oor grounds.

Since the actor cannot walk over the wall, a building may have various openings at various sides (replaced

with dirt or  oor). For example, the middle building has an opening on the south side (a  oor _ ). The

player starts the game in the building in the middle of the map(This image does not contain the player

symbol).

The player can use their limbs to attack the enemies, dealing 15 damage with 80% attack accuracy.

Make sure to display the player’s hit points and stamina before printing the menu on the console!

In the building, there is a “Broadsword”, which is a starting weapon that the player can pick up and

use to attack enemies. This weapon can deal 110 damage with 80% attack accuracy. This weapon is

represented by the character “1”. It also has a special skill, “Focus”, that can increase the weapon’s

damage multiplier by 10% for 5 turns and set (not increase) the weapon’s hit rate to 90% while the

weapon is in the player’s inventory. If the player drops the weapon while the skill is active, the

weapon’s damage multiplier and hit rate will revert back to the previous state.

For simplicity, If the player uses the skill again while the skill is still active, you can simply re-apply the damage

multiplier increase and reset the turns back to 5. For example, if the weapon skill was activated once, the

damage multiplier is up by 10% and assume that the skill has 2 turns left. If the skill is activated at this point,

the damage multiplier is up by 20% (increased by another 10%), and the turns would be reset to 5.

You can assume that all weapons have either one skill or none. The stamina points used by activating weapon

skills vary between di erent weapons.

Whenever the player uses “Focus”, which is the Broadsword’s weapon skill, their stamina is reduced

by 20% of their maximum stamina.

At each turn, the player’s stamina will recover by 1% of their maximum stamina.

REQ2: The Abandoned Village’s Surroundings

After the player exits the building, they notice that there are several bottomless pits within the village.

This bottomless pit is also known as the Void, and it is represented by the display character “+”. Any

entity, including the player, will be killed if they step on it.

If the player dies, make sure that the game ends and a “YOU DIED” message is displayed on the console (see

the FancyMessage class).

The player also notices that there are several graveyards in the village. The graveyard is displayed as

“n”. As the player gets closer to one of the graveyards, a  gure rises up and attacks the player! This is

because the graveyard is occupied by the former inhabitants of the village (see REQ3). The graveyard

can spawn this enemy with a 25% chance at every turn of the game.

Edit (27/08/2023): For simplicity, you can assume that the graveyard can spawn a WanderingUndead with a

25% chance at every turn, regardless of the player's location.

Hint: if you need to pass in arguments to a ground’s constructor, you can do the following

gameMap.at(30, 11).setGround(new ConcreteGround(input1, input2));

REQ3: The Wandering Undead

The  rst enemy that the player encounters is the “Wandering Undead”, which is displayed as “t”. If the

player is not within the surrounding of the enemy, it will wander around. However, when the player

is nearby (within the surrounding of the enemy or one block away from the enemy), it will attack the

player. This type of enemy has 100 hit points and can attack the player with its limbs, dealing 30

damage with 50% accuracy. An enemy cannot attack another enemy.

This enemy cannot enter a  oor, represented by the display character “_”, so that the player can run

back to safety if their health is low. Furthermore, both the player and the enemy cannot enter walls.

They, however, can walk around freely in the Void*, on puddles and dirt.

* with consequences (see REQ2)

REQ4: The Burial Ground

After defeating the enemy, the player explores the deeper section of the village until they reach a

locked gate (represented by the display character “=”), leading to a new region of the abandoned

village, which is known as the burial ground. Since the gate is locked, the player will not be able to

proceed without a key.

A sample burial ground map

The burial ground must be implemented as a new map (separate from the abandoned village map). Make sure

to add another Gate in the Burial Ground map to go back to the Abandoned Village map. You can assume that

this is a separate gate that the player also needs to unlock.

The wandering Undead has a 25% chance of dropping an “Old Key” (represented by “-”) once they are

defeated by the player. For the sake of simplicity, multiple key instances are expected in the game.

The player can pick up this key and use it to unlock the gate leading to the burial ground.

In this game, only the player is able to use the gate for travelling (once they have the old key). Other actors

may step into the gate once it is unlocked, but they will not be able to use it for travel.

You can assume that the old key is reusable. That is, you don’t need to remove the old key from the player’s

inventory after the player uses it.

REQ5: The Inhabitants of The Burial Ground

The graveyards in the burial ground are occupied by a di erent type of enemy, known as the Hollow

Soldier, displayed as “&”. This type of enemy has 200 hit points and can attack the player with its

limbs, dealing 50 damage with 50% accuracy. The graveyard can spawn this enemy with a 10%

chance at every turn of the game.

Similar to the wandering Undead (see REQ4), if the player is not within the surrounding of the enemy, it will

wander around. However, when the player is nearby (within the surrounding of the enemy), it will attack the

player. An enemy cannot attack another enemy.

This enemy cannot enter a  oor, represented by the display character “_”, so that the player can run back to

safety if their health is low. Furthermore, both the player and the enemy cannot enter walls. They, however,

can walk around freely in the Void*, on puddles and dirt.

* with consequences (see REQ2)

Once defeated, this enemy has a 20% chance to drop a healing vial (represented by the display

character “a”), which can be consumed by the player to heal 10% of their maximum health. It also has

a 30% chance to drop a refreshing  ask (represented by the display character “u”), which can be

consumed by the player to increase their stamina by 20% of their maximum stamina. Each instance

of both healing vials and refreshing  ask can be consumed by the player only once.

For simplicity, the calculation of the probability of each item dropping is independent of the other item, so the

player can get lucky and get both items after killing one Hollow Soldier.

Healing vials and refreshing  asks cannot be consumed directly from the ground. That is, they must be picked

up by the player before being consumed.

The wandering Undead that the player met earlier in the Abandoned Village map (see REQ3), once

defeated, also has a 20% chance to drop a healing vial. Similar to the Hollow Soldier, the calculation

of the probability of the Healing vial dropping is independent of the Old key.

Submission Instructions

Not following any one of the instructions below will result in penalty being applied to your  nal submission.

You do not need to submit an interaction diagram (e.g. sequence diagram or communication diagram) in

assignment 1. However, you will need to submit these documents for assignment 2 and assignment 3. For

assignment 1, you may still create these documents if you  nd them useful for designing the system.

We will mark your assignment based on the latest commit in the branch in your GitLab repository by the due

date, not in the branch. main master

Class Diagrams & Documentation Submission

As mentioned in the Design & Diagrams section, you MUST create one design diagram per

requirement. In other words, each requirement must be represented in its own separate

diagram. Organising them in one large design diagram or combining requirements based on

their packages is not allowed. Doing so may reduce the clarity of your design diagram or could

be seen as an attempt at reverse engineering. Penalties will be applied if this occurs. Please

keep each requirement diagram distinct and avoid any attempts to merge or combine them.

You MUST save your design documentation, including design diagrams, rationale and report

(diagram + rationale combined into a single document), in the

"docs/design/{assignmentName}" directory. So, for Assignment 1, you must save all design

documentation in the "docs/design/assignment1" directory.

TAs cannot be expected to look at other directories, except for "docs/design/{assignmentName}", when

marking the design diagrams and rationale.

All design documentation must be saved in PDF format (or PNG/PDF for diagrams, such as

REQ1.png, REQ2.png, and so on).

A Moodle submission is compulsory, and it must be done before the deadline. Please,

compress ALL  les (code, documentation, and diagrams) as one zip  le, and submit the

compressed  le.

Disclaimer: Although there are multiple ways to design the game, there are also bad designs and good designs

- we will mark your submission not against one design but based on the design principles

Design Diagrams

We expect you to produce  ve UML class diagrams following the FIT2099 Assignment Rules. These

Rules are available on EdLesson.

You should not create one class diagram that shows the entire system. The sample diagram in

the base code shows the whole system to help you understand how the works with the . But, in this

assignment, you only need to show the following: game engine

the new parts,

the parts you expect to change, and

enough information to let readers know where your new classes  t into the existing system.

As it is likely that the precise names and signatures of methods will be refactored during

development, you do not have to put them in these class diagrams. Instead, the overall

responsibilities of the classes need to be documented somewhere, as you will need this information to

begin implementation. This can be done in a separate text document ( markdown format) or

spreadsheet, which you should put inside the directory. We will not assess this document, but we

believe it will be handy during the implementation phase. .md docs

Design Rationale

To help us understand how your system will work, you must also write a design rationale to explain

your choices. You must demonstrate how your proposed system will work and why you chose to do

it that way. Here is where you should write down concepts and theories you've learnt so far (e.g.,

DRY, coupling and cohesion, etc.). You must consider the pros and cons of the design to justify your

argument.

The design (which includes all the diagrams and text that you create) must clearly show the following:

what classes will exist in your extended system

what the roles and responsibilities of any new or signi cantly modi ed classes are

how these classes relate to and interact with the existing system

how the (existing and new) classes will interact to deliver the required functionality

You are not required to create new documentation for components of the existing system that you do

not plan to change.

IMPORTANT! We will not accept any Word document because it cannot be opened/displayed in Gitlab.

Implementation

A reminder: you must not modify the game engine, as stated in the assignment rules document.

Your implementation must adhere to the Google Java coding standards.

Google Java coding standards: https://google.github.io/styleguide/javaguide.html#s5-naming

Write Javadoc comments for at least all public and protected methods and attributes in your classes.

You will be marked on your adherence to the standards, Javadoc, and general commenting guidelines

that were posted to EdStem earlier in the semester.

To ensure that your work adheres to good coding practices in this unit, we encourage you to minimise the use

of and/or downcasting, as they are considered code smells. It's important to note that if there are any

instances where you need to use them, please provide appropriate justi cations in code comments or design

rationale. We believe learning how to properly utilise polymorphism is crucial in addressing this code smell,

and we are committed to teaching you how to do so e ectively. instanceof

Marking Rubric

Assignment 1 rubric

Prerequisite for marking: Design documents (UML diagrams and design rationale) and

implementation need to be submitted for the assignment to go through the marking process. Missing

any of these will result in 0 marks.

Overview:

Total: 28 points

Feature implementation completeness (6 points)

Implementation quality: design principles (8 points)

Design rationale (4 marks)

Integration with the existing system (2 points)

UML syntax and clarity (2 points)

Alignment and design consistency (2 points)

Style & Javadoc (1 point)

Git usage (2 points)

Format and directory structure (1 point)

Detailed rubric items:

Feature implementation completeness (6 points)

6 marks - The system runs and perfectly meets all functional expectations as per the relevant

requirement(s) with no runtime errors. All required classes and relationships are implemented, and

the program's behaviour aligns perfectly with the speci cation.

5 marks - The system runs and meets all functional expectations (with some minor errors or

punctual omissions) as per the relevant requirement(s). All necessary classes and relationships are

included, and the program's behaviour largely matches the speci cation, except for one or two

minor unexpected behaviours. No runtime errors occur.

4 marks - The system runs and partially meets all functional expectations, displaying several

minor functional errors or omissions as per the relevant requirement(s). Despite this, the majority

of necessary classes and relationships are included, and only a few minor unexpected

behaviours occur. No runtime errors are present.

3 marks - The system runs and all functional expectations were addressed to some extent,

(with one or two major functional errors) as per the relevant requirement(s). Most important classes

and relationships are included but at least one or two major unexpected behaviors are

observed. A major unexpected behaviour is that which a ects considerably the completeness of at

least one requirement. No runtime errors occur.

2 marks - The system runs but several functional expectations were not addressed as per the

relevant requirement(s) (e.g. the notion of Behaviour is not included even though it is a part of the

requirement). Alternatively, runtime errors occur during the execution of the system but they can be

easily  xed.

1 mark - The system runs but addresses only some functional expectations and shows major

omissions as per the relevant requirement(s) (important classes or relationships are missing).

Alternatively, runtime errors occur during the execution of the system without a clear idea of the

cause or cannot be easily  xed.

0 marks - The system runs but it poorly addresses or doesn’t address the functional

expectations as per the relevant requirement(s). Alternatively, the system might not run at all.

Implementation quality: design principles (8 points)

This item applies across all functional expectations as per the relevant requirement(s)

8 marks - The implementation of all functional expectations as per the relevant requirement(s)

awlessly adheres to good design principles and concepts (e.g., DRY and SOLID principles),

making the design easy to extend and maintain. Any punctual violations are convincingly justi ed in

the design rationale (e.g., using singleton to implement a feature). All relevant requirements have

been addressed.

7 marks - The implementation follows good design principles nearly perfectly making the design is

easy to extend and maintain (if some punctual principles are violated, the trade-o  is somewhat

justi ed in the design rationale. All relevant requirements have been addressed.

6 marks - The implementation involves one or two minor violations of design principles (could

be easily  xed) across all functional expectations as per the relevant requirement(s) (e.g., some

attributes are not set to private without any justi cation). All relevant requirements have been

addressed.

5 marks - The implementation involves minor violations of design principles in multiple places

(could still be easily  xed) across all functional expectations as per the relevant requirement(s). All

relevant requirements have been addressed.

4 marks - The implementation involves one or two non-severe violations of design principles

that could be implemented in a better way (no trade-o s are convincingly provided in the

design rationale) across all functional expectations as per the relevant requirement(s) (e.g. some code

repetitions are found in the implementation that would require some refactoring to be  xed). All

relevant requirements have been addressed.

3 marks - The implementation involves non-severe violations of design principles in multiple

places (no trade-o s are convincingly provided in the design rationale). All relevant requirements

have been addressed.

2 marks - The implementation involves one or two severe violations of design principles that could

be implemented in a better way across all functional expectations as per the relevant requirement(s),

e.g. violating the basic principles covered so far. Fixing them would require substantial refactoring.

Alternatively, not all relevant requirements have been attempted.

1 mark - The design/implementation can be considered hacky or various instances of procedural

programming are found. For example, the implementation uses downcasting and ‘instanceof’ in

various cases without a convincing justi cation. Alternatively, it can also be the case that abstraction

is not used, making the design di cult to extend and maintain. Alternatively, only some relevant

requirements have been attempted.

0 marks - The implementation mainly follows a non-OO paradigm; or the UML class diagram(s) or the

implementation is missing. Alternatively, most relevant requirements have not been attempted.

Design rationale (4 points)

4 marks - The design rationale includes a description of what has been done and why, focusing on

the principles and concepts taught in the unit (such as DRY and SOLID principles) and not in terms of

game design. The rationale discusses the advantages and disadvantages of the design (pros and

cons), the reasons for choosing the current design, and ways in which it can be easily extended

(e.g. my design achieves OCP because if a new character is added in the future ...). All relevant

requirements have been addressed.

3 marks - The rationale describes what has been done and why, based on the principles and

concepts taught in the unit. It also includes some discussion of the pros and cons of the design and

the reasons for the current design choice but lacks examples of future extensibility. All relevant

requirements have been addressed.

2 marks - The rationale describes what has been done and why, aligning with the principles and

concepts taught in the unit. However, it lacks a discussion on the pros and cons of the design

and/or examples of future extensibility. All relevant requirements have been addressed.

1 mark - The rationale primarily describes what has been done without a thorough explanation

of the decision-making reasons. For instance, it may mention design principles ad concepts without

providing convincing explanations, discussion of pros and cons, or examples of how the system can

be extended. Alternatively, not all relevant requirements have been attempted.

0 marks - The design rationale is either very challenging to read, is missing, or the submitted work

omits more than one relevant requirement.

Integration with the existing system (2 points)

This item applies across all relevant requirements.

2 marks - The implementation e ectively uses the engine classes (e.g. the submitted work

demonstrates that the students understand the di erence between actions and behaviours). All

relevant requirements have been addressed.

1 mark - The implementation does not use some engine classes as intended (e.g. behaviours are

created for some actions that do not need it, such as actions performed by the player) or includes

custom classes for functionality that could be implemented with the engine class (e.g.

created a custom ground class instead of using the ground class given in the engine package). Most

relevant requirements have been addressed.

0 marks - The engine has been modi ed in a minor or signi cant way OR the UML class diagram OR

the implementation is missing

UML syntax and clarity (2 points)

This item applies across all relevant requirements.

2 marks - Relevant (static and/or dynamic) diagrams are perfect in terms of syntax, with no

missing multiplicities, correct arrowheads for all relationships, and appropriate usage of realisation

for classes implementing interfaces, generalisation for classes or interfaces inheriting others, etc.

Diagram formatting is consistent and clear. All requested diagrams have been submitted.

1 mark - Diagram(s) contain some minor syntax errors, such as missing multiplicities for several

associations, inappropriate use of generalisation for classes implementing interfaces, realisation for

classes extending others, or classes extending multiple classes, etc. Nonetheless, the design can still

be understood by the TA with a little e ort. Alternatively, there are several inconsistencies across

diagrams. All necessary diagrams have been submitted.

0 marks - Diagram(s) are signi cantly hard to understand or show major inconsistencies in formatting

and clarity, OR more than one required diagram is missing, OR they do not resemble a UML diagram

as required.

Alignment and design consistency (2 points) - incl.

Design rationale, code and UML diagrams

2 marks - The design rationale and UML diagrams are in perfect alignment with each other and

with the code implementation across all functional expectations, as per the relevant requirement(s).

All relevant requirements have been addressed or attempted and they are covered in the

implementation, UML diagrams and design rationale.

1 mark - There are some small inconsistencies (that can be easily  xed) between the design

documents and the implementation, but all relevant requirements have been addressed or

attempted, and they are covered in the implementation, UML diagrams and design rationale.

0 marks - There are major inconsistencies (which would necessitate signi cant changes for

correction) or numerous smaller discrepancies distributed throughout the design documents and

the implementation. Alternatively, one or more than one required diagram or implemented

requirement is missing, or some submitted design documents do not resemble the required UML

diagram format.

Style & Javadoc (1 point)

1 mark - The code is properly documented with Javadoc across all functional expectations as per the

relevant requirement(s), including class-level and method-level documentation. The Google Java Style

guide is followed properly (e.g. package names are written in lowercase, attributes and variables

names are written in lowerCamelCase, class names are written in UpperCamelCase, etc.). All relevant

requirements have been addressed or attempted.

0.5 marks - Some classes and methods are missing Javadoc documentation OR some classes do not

follow the Google Java style guide

0 marks - Most classes and methods are missing Javadoc documentation OR The Google Java style

guide is not followed.

Git usage (2 points)

2 marks - At least 15 meaningful commits have been logged (with meaningful comments) each with

a descriptive commit comment (note: default comments from the web UI don't count.), ideally, one

commit per week previous to the submission deadline.

1 mark - Between 7 and 14 meaningful commits have been logged (with meaningful comments)

each with a descriptive commit comment (note: default comments from the web UI don't count.). OR

there are more than 10 commits but ALL were done on the week of the submission deadline.

0 marks - There are less than 7 commits.

IMPORTANT: if most of the code has been (in practice) uploaded in one go the whole assignment will not be

marked and 0 marks will be awarded.

Project formatting and directory structure (1 point)

1 mark - If the directory structure suggested in the speci cation has been followed. All the documents

are easily found where expected.

0 marks - The suggested directory structure was not followed and some  les may be hard to  nd.

Handover Interview (Compulsory)

COMPLETED - The student can answer all (or at least 2) questions during the handover interview

satisfactorily. The responses need to demonstrate that the student understands the various parts of

the submitted assignment.

NOT COMPLETED If two or more questions are not responded to adequately and sensibly. The

remaining question(s) is/are partly responded to, but it is unclear whether the student understands

their own work.

IMPORTANT: Failing to have meaningful commits (i.e. showing that the task was progressively completed)

and/or failing the handover interview would automatically  ag this as a potential case of plagiarism, it will be

further investigated using a similarity check software, and zero marks would be awarded for the full

assignment.

Assignment 1 Q&A Session