1. Design and implement a custom environment for your maze game. This requires producing
your own unique hand-drawn map of the maze game environment and changing the
HardCodedData file to reflect the locations and items on your map. At least M (M>4) locations,
including Exactly N (N>2) shops with a condition M>N, must be included, as well as enough
items to allow for proper testing of the game functionality. For example, there must be sufficient
items to verify that a player cannot collect an item if the weight restriction has been met. Note:
you should not retain the original locations or items from the provided code base in your version
of the game.
2. Implement each of the following deliverables / milestones:
a. functionality as detailed in Lab 8 and Lab 9
b. commands to manage the various item management commands:
i. listItems, getItem and dropItem, to allow listing of all held items, collect a new item
and drop a held item.
ii. equipItem and unequipItem, to wear / wield a held item, and to stop wearing or
wielding an equipped item.
iii. purchaseItem and sellItem, to buy an item from a vendor and to sell an item to a
iv. getmazestatus to show the status of the maze (i.e., value of M and N)
Ensure that weight restrictions are not exceeded and that the context for each command is
appropriate. For example, purchasing and selling of items should only occur in a shop.
c. Basic combat functions, allowing a player to attack or to be attacked by a non-player
character (NPC). A player may flee combat or continue to attack until such time as one
combatant loses all life points. The end result must not be hard-coded, and neither the
hostile NPCs nor player may have their attributes configured in such a way that the final
outcome is pre-determined. Note that combat functions should only be available when the
player is in the presence of a hostile NPC, and combat may take whatever form is
appropriate for your game context rather than being limited to just hits with a weapon.
3. Write Three Unit test cases for each of the methods you are developing.
You can write the test cases in any Java framework, but Junit is preferred.
4. Prepare a Jira account (one account for a team), and create Tickets (story) that you are planning
to do. A jira ticket/story is a small job that is assigned to any of you and there is an estimation
of how long it will take time to finish the job. You can divide the jira board into 5 vertical sections:
Ready to Development, In Development, Ready to Test, In Test and Done. Once a ticket is
ready to move from one column to another, move it accordingly. Prepare a nice summary of your Jira activity which will include the screenshot of your Jira board and the burndown chart.