辅导案例-FIT2099-Assignment 1
Monash University FIT2099 Object-Oriented Design and Implementation 2020 S1 Assignment 1: Planning and Design Braaaains Due: Friday of Week 7 at 11:55pm, your local time For the rest of the semester, you will be working in teams on a relatively large software project. You will design and implement new functionality to add to an existing system that we will provide to you. A document explaining the FIT2099 Assignment Rules has been uploaded to the Assessments section in Moodle. Please read it and make sure you understand it before you begin the project – you are expected to follow what it says, and will almost certainly lose marks if you do not. Background You will be working on a text-based “rogue-like” game. Rogue-like games are named after the first 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 roguelike games, a good site is http://www.roguebasin.com/. In this game, you are a survivor of the Zombie Apocalypse. The dead have risen from their graves and destroyed society as we know it. You and a small group of other people have retreated to a compound in the woods to defend it as best you can. If you’re not familiar with zombies in popular culture, don’t worry. You don’t have to know about any particular game, movie, or TV show to complete this assignment. If you like, you can get an overview of the sort of situation we’re talking about at https://tvtropes.org/pmwiki/pmwiki.php/ Main/ZombieApocalypse. As it stands, the game functions, but is missing a lot of desired functionality. Over the course of this project, you will incrementally add new features to the game. Assignment 1 and 2 Requirements Here are the features we would like you to add to the game in the first round. In Assignment 1, you will design the code that you will use to implement these features; in Assignment 2, you will implement your design, refactoring it if required. Assignment 3 will add more features for you to design and implement. You are not required to write any code for Assignment 1. You may do so if you like, but your marker will ignore it. Zombie attacks At the moment, the Zombies in the game are boring. They chase the nearest human and attack them. You need to make Zombies and their attacks more interesting. • Zombies should be able to bite. Give the Zombie a bite attack as well, with a 50% probability of using this instead of their normal attack. The bite attack should have a lower chance of hitting than the punch attack, but do more damage – experiment with combinations of hit probability and damage that make the game fun and challenging. (You can experiment with the bite probability too, if you like.) • A successful bite attack restores 5 health points to the Zombie • If there is a weapon at the Zombie’s location when its turn starts, the Zombie should pick it up. This means that the Zombie will use that weapon instead of its intrinsic punch attack (e.g. it might “slash” or “hit” depending on the weapon) 1 Monash University FIT2099 Object-Oriented Design and Implementation 2020 S1 • Every turn, each Zombie should have a 10% chance of saying “Braaaaains” (or something simi- larly Zombie-like) Beating up the Zombies Zombies are well-known to fall to pieces quite readily due to decay, but keep on going regardless. • Any attack on a Zombie that causes damage has a chance to knock at least one of its limbs off (I suggest 25% but feel free to experiment with the probabilities to make it more fun) • On creation, a Zombie has two arms and two legs. It cannot lose more than these. • If a Zombie loses one arm, its probability of punching (rather than biting) is halved and it has a 50% chance of dropping any weapon it is holding. If it loses both arms, it definitely drops any weapon it was holding. • If it loses one leg, its movement speed is halved – that is, it can only move every second turn, although it can still perform other actions such as biting and punching (assuming it’s still got at least one arm) • If it loses both legs, it cannot move at all, although it can still bite and punch • Lost limbs drop to the ground, either at the Zombie’s location or at an adjacent location (whichever you feel is more fun and interesting) • Cast-off Zombie limbs can be wielded as simple clubs – you decide on the amount of damage they can do Crafting weapons Now that you have zombies dropping bits of themselves everywhere, you can make the game more interesting by letting the player craft better weapons out of them. • If the player is holding a Zombie arm, they can craft it into a Zombie club, which does significantly more damage. • If the player is holding a Zombie leg, they can craft it into a Zombie mace, which does even more damage Rising from the dead As everybody knows, if you’re killed by a Zombie, you become a Zombie yourself. After a Human is killed, and its corpse should rise from the dead as a Zombie 5-10 turns later.1 Farmers and food You must create a new kind of Human: Farmers. A Farmer shares the same characteristics and abilities as a Human, but: • when standing next to a patch of dirt, a Farmer has a 33% probability of sowing a crop on it • left alone, a crop will ripen in 20 turns • when standing on an unripe crop, a Farmer can fertilize it, decreasing the time left to ripen by 10 turns • when standing on or next to a ripe crop, a Farmer (or the player) can harvest it for food. If a Farmer harvests the food, it is dropped to the ground. If the player harvests the food, it is placed in the player’s inventory • Food can be eaten by the player, or by damaged humans, to recover some health points 1You do not have to literally turn the corpse object into a Zombie object; objects in Java cannot change their types. Just make it look to the player as though the corpse is rising from the dead. 2 Monash University FIT2099 Object-Oriented Design and Implementation 2020 S1 Bear in mind as you design that you may not change any code the engine package. You can do what- ever you like to code in other packages, and you may call methods in the engine package if it’s public (or if it’s protected and you’re calling it from a subclass). You may also inherit from classes in the engine package, if they are public. A note about requirements You will see that these requirements are imprecise. In many cases, this is because we want to give you the opportunity to experiment with different values – probabilities, damage levels, and so on – to find one that makes the gameplay more fun. This will not be marked. Changing these values should not affect the structure of your system, so feel free to play with them, especially if you are studying Game Development or are otherwise interested in game design. If you’re wondering why we have only told you what the game needs to do and not told you how to do it, that’s because we are marking you on your ability to make good design choices – that is, to make designs that fit in with the design principles covered in lectures, in the compulsory readings, and in the Object-Oriented Fundamentals in Java notes. Getting Started The initial code base is available in a repository that has been created for you on git.infotech.monash.edu. It includes a folder containing design documents for the system. Download it and familiarize yourself with the code and its documentation. Your repository is ready for you to clone and use, so you don’t need to create a new local one and push it. Instead, follow the instructions on the last page of the Supplementary Notes on git that tell you how to check out a fresh copy of your repo. A video walkthrough will be posted under Assessments in Moodle when your repositories are created to show you how this can be done. What to submit for Assignment 1 You are expected to produce the following three design artefacts in Assignment 1: • Class diagrams • Interaction diagrams • A design rationale You will be implementing your design later, but for Assignment 1 you are not required to write any code. Instead, you must produce preliminary design documentation to explain how you are going to add the specified new functionality to the system. The new functionality is specified in the Assignment 1 and 2 Requirements section, above. We expect that you will produce UML class diagrams and UML interaction diagrams (i.e. sequence dia- grams or communication diagrams) in accordance with the FIT2099 Assignment Rules. These Rules are available on Moodle. Your class diagrams do not have to show the entire system. You only need to show the new parts, the parts that you expect to change, and enough information to let readers know where your new classes fit 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 this class diagram. However, the overall responsibilities of the class need to be documented somewhere, as you will need this information to be able to begin implementation. This can be done in a separate text document if you prefer. To help us understand how your system will work, you must also write a design rationale to explain the choices you made. You must explain both how your proposed system will work and why you chose to do it that way. The design (which includes all the diagrams and text that you create) must clearly show: • what classes will exist in your extended system 3 Monash University FIT2099 Object-Oriented Design and Implementation 2020 S1 • what the roles and responsibilities of any new or significantly modified 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. Work Breakdown Agreement We require you to create a simple Work Breakdown Agreement (WBA) to let us know how you plan to divide the work between members of your team. There is more information on WBAs in the FIT2099 Assignment Rules. These are available on Moodle in the Assessment section. Submission instructions You must put your design documents and work breakdown agreement (in one of the acceptable file formats listed earlier) in the design-docs folder of your Monash GitLab repository. The due date for this assignment is Friday of Week 7 (8th May) at 11:55pm, your local time. We will mark a snapshot of your repository as it was at the due time. This means that you will need to notify your marker if you finished late and let them know which version they should check out. Our git server has limited bandwidth and in previous years some students have experienced timeouts when pushing to the server. If this happens to you, don’t panic: try again ten minutes later. Your sub- mission time is the timestamp on the commit (i.e. to your local repo), not the timestamp on the push to server, so as long as you finish and commit on time, it’s okay if it takes a while to get it uploaded. Unless a team member has applied for and received special consideration according to the Monash Special Consideration Policy,2 late submissions will be penalized at 10% per working day late. It is both team members’ responsibility to ensure that the correct versions of the documentation are present in the repository by the due date and time. Once both teammates have agreed on a final As- signment 1 submission, do not make further commits to the master branch of the repository until the due date has passed unless your teammate agrees. Marking Criteria This assignment will be marked on: Design completeness Does your design support the functionality we have specified? Design quality Does your design take into account the programming and design principles we have discussed in lectures? Look in lecture slides, and check the Object-Oriented Fundamentals docu- ments for principles like Do Not Repeat Yourself Practicality Can your design be implemented as it is described in your submission? Following the brief Does your design comply with the constraints we have placed upon it — for in- stance, does your design leave the engine untouched, as required? Documentation quality Does your design documentation clearly communicate your proposed changes to the system? This can include: • UML notation consistency and appropriateness • consistency between artefacts • clarity of writing 2http://www.monash.edu/exams/changes/special-consideration 4 Monash University FIT2099 Object-Oriented Design and Implementation 2020 S1 • level of detail (this should be sufficient but not overwhelming) Explanation Can you adequately explain your design and the reasoning behind it, both in your ratio- nale and in response to interview questions from your marker? Learning outcomes for this assignment This assignment is intended to develop and assess the following unit learning outcomes: 1. Iteratively construct object-oriented designs for small to medium-size software systems, and de- scribe these designs using standard software engineering notations including UML class diagrams (in conceptual and concrete forms), UML interaction diagrams and, if applicable, UML state diagrams; 2. Evaluate the quality of object-oriented software designs, both in terms of meeting user requirements and in terms of good design principles, using appropriate domain vocabulary to do so; 5. Use software engineering tools including UML drawing tools, integrated development environ- ments, and revision control to create, edit, and manage artifacts created during the development pro- cess. 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 and interaction diagrams to document your design, using a UML drawing tool such as UMLet or Visual Paradigm – you are free to choose which one • write a design rationale evaluating your proposed design and outlining some alternatives • use git to manage your team’s files and documents The marking scheme for this assignment reflects these expectations. 5