用Java实现游戏Ballboy, 并且编写Unit test.
Problem Overview
You are required to design and implement an application model for a classic shoot ‘em up video game Ballboy in three stages. The video game consists of a character on the screen that bounces up and down, can move left and right, and has the ability to modify how high they bounce. There are enemies that can be defeated with the help of Ballboy’s ally, Squarecat.
Assignment 3 Requirement
In assignment 3, you are going to test, review and extend an existing implementation of ‘Ballboy’ (that is not your own) to add features, leveraging your knowledge of OOP and design patterns. Please find the detailed tasks below.
Implementation Task
What we provide to you?
- Codebase: the codebase is provided to youhere.
Please note that, your goal is to extend and maintain this implementation. What this means is to add features to the existing implementation by using OO design principles and appropriate patterns you have learnt throughout this UoS, without breaking the implementation (it runs - rule #1 is don’t break working code) or using unnecessary ‘hacks’.
You are not required to correct the existing design of the implementation - you must retain the existing design wherever changes are not required and will be penalised should this be changed without cause (for example, replacing the given implementation with your own assignment 2 code). The idea here is that you work with the existing design rather than against it, and minimise required changes to the existing structure (reasonable, limited scope refactoring to support extensions is encouraged).
What we expect from you?
Testing
You are required to write JUnit 5 testsfor the code provided to youfor the submitted code. These tests must cover the functionality of each class and must be runnable using ‘gradle test’ (included in ‘gradle build’). Ensure your test casescover over 80% of the codeand cover both common and edge/corner cases.
Extension
Your Ballboy game is now expected to support the following 4 features in your code:
- Level Transition
- moving from level 1 to n, then showing ‘Winner’ when level n is completed as the Ballboy achieves the goal (finish flag touched).
- These levels can either be contained within the same configuration file, or you can use multiple configuration files.
- You must provide at least 3 levels to demonstrate levels and level transition.
- It must be possible to have more levels by editing the json configuration, i.e., without further code changes.
- Squarecat
- Ballboy will be ‘orbited’ by Squarecat. Squarecat will move in a square shape around Ballboy.
- It is acceptable for Squarecat to pass through objects, unlike Ballboy who must not.
- Enemies touched by Squarecat will be removed from the level.
- Ballboy will be ‘orbited’ by Squarecat. Squarecat will move in a square shape around Ballboy.
- Score (Observer design pattern)
- Each level displays one to three colour scores (RGB), set in the json configuration file. Enemies are colour coded, and a colour score increments when an enemy of that colour is dealt with.
- The game must display on the screen a continually updating score. You must display the current level’s scores (initially all at 0) on screen during the level, as well as the total scores for all previous levels.
- Save and Load (Memento design pattern)
- The player must be able to save the state of the game (quicksave), then reload that saved game at any point in time (quickload).
- This should be controlled using keyboard keys - ‘q’ to load ‘s’ to save.
- The full state of the game must be reverted to the saved state at that time (including Level, Score, and all Entities).
- This must be a single saved state that is not written to disk, and each subsequent quicksave overwrites the existing saved state.
- Quickload reverts the game state to the single saved version.
- Quickload does not remove the saved state, so it can be loaded multiple times.
An entirely optional feature:
- Cheatmode
- E.g., pressing ‘r’ will immediately remove all red enemies (or a single random red enemy) as if Squarecat had touched them.
- Likewise for ‘g’ and ‘b’
- This feature is optional, but will make testing and demonstration easier.
- E.g., pressing ‘r’ will immediately remove all red enemies (or a single random red enemy) as if Squarecat had touched them.
Report Task
Your report in this assignment must concisely cover the followings:
- Code review on the existing codebase provided to you, which includes
- discussion on the use of OOP design principles (be specificto the given code, a UML snippet would be helpful)
- discussion on the use of design patterns(be specificto the given code, a UML snippet would be helpful)
- discussion on the documentation (e.g., readme file, comments, etc.) discussion on how easy or difficult the above made it to achieve your required functionality and the reason
- A discussion on your feature extension including
- Describe the actual extension you have made in your code
- Highlight your application of OO design principles in your extensions and explain what they motivated you to do and why (be specificto your code, a UML snippet would be helpful)
- Document any design patterns used and rationalise their usage in terms of SOLID and GRASP (be specificto your code, not the pattern in general, a UML snippet would be helpful)
- Reflect on your extension design, highlighting any outstanding issues or improvements or discussing your impact on the extensibility of the code
- A UML class diagram of the after-extension version of your codebase, highlighting the design patterns you have used for your extension and identifying the participants in each design pattern you have used.
- Any acknowledgement/reference required.
Submission Details
You are required to submit all assessment items by the due date listed on Canvas.
- Report: Submit your UML class diagram and your reportas a SINGLE pdf document.
- If your diagram is unreadable at 200% magnification (maximum zoom with the turnitin tool) then consider how to improve it
- You must include the entire UML diagram, but you may also include enlargements of specific parts for reference in the discussion
- As a last resort, you may submit the full UML diagram as a separate ‘appendix’ document for readability purposes. If you do this, make sure that the report contains enlarged, readable, snippets of the UML where needed.
- Code: Submitted separately
- ‘gradle run’ will start the game.
- ‘gradle test’ will run the tests.
- ‘gradle build jacocoTestReport’ will generate a coverage report.
- A readme file named “A3_readme.txt” should cover any point you would like your marker to know
- how to run your code (e.g., any quirks to run your application).
- List features (i.e., Level Transition, Squarecat, Score, and Save/Load) youhave implementedin your extension.
- List the names of the design patterns you have usedin your extension and provide the corresponding class and file names regarding these patterns.
- Code that is not listed here will not be assessed as part of the design pattern.
- If cheatmode is implemented, this would be a good place to describe how to use it.
- Any other info you would like your marker to know regarding your implementation.