Part Two: The Belly of the Beast
COMP2511 23T2 Assignment II: Dungeonmania
1. Getting Started
Task 1) Code Analysis and Refactoring (40 marks)
a) From DRY to Design Patterns (7 marks)
b) Observer Pattern (5 marks)
c) Inheritance Design (6 marks)
d) More Code Smells (6 marks)
e) Open-Closed Goals (6 marks)
f) Open Refactoring (10 marks)
Task 2) Evolution of Requirements (50 marks)
a) Microevolution – Enemy Goal (15 marks)
b) Bosses (10 marks)
c) Swamp Tile (10 marks)
d) Sun Stone & More Buildables (15 marks)
e) Dungeon Generation (15 marks)
3.12.1 Generating a Dungeon – Randomized Prim’s Algorithm
3.12.2 Frontend Code
f) Logic Switches (20 marks)
g) Time Travel (Bonus – 0 marks)
i) Time Turner
ii) Time Travelling Portal
iii) Time Travel Rules
Task 3) Investigation Task (5 marks core + 5 marks bonus)
3. Tidbits
4.1 Individual Blogging
4.2 Interview
5. Assessment
5.1 Marking Criteria
5.2 Automarking
This page contains the tasks youʼll need to complete for this assignment, and how youʼll be
5.3 Submission
5.4 Late Penalties
5.5 Extenuating Circumstances
5.6 Other Expectations
5.7 Plagiarism
1. Getting Started
You can access your pair repository via the following URL:
https://gitlab.cse.unsw.edu.au/COMP2511/23T1/teams/YOUR_TEAM_NAME/assignment-ii
Replace YOUR_TEAM_NAME with your team name (e.g. M18A_ALPHA )
Watch the following video which goes through approaching the codebase and some VSCode tips and
tricks to help you out.
COMP2511 Assignment II: Dungeonmania – The Belly of the Beast
Tip: Explore and code along with the video to get the most out of it!
Task 1) Code Analysis and Refactoring (40 marks)
In this task, you will need to analyse the design of the monolith, including the patterns and smells present
in the implementation, and apply refactoring techniques discussed in the course in order to improve the
quality of the code.
For this assignment, you will need to make two sets of blog posts:
One which is a pair-completed blog post, which will contain your answers to questions in Task 1, designs for Task 2 and
completion of Task 3.
Here is a template for your pair blog post.
One is your individual blog post/s. Similar to Assignment I we recommend you write 2-4 blog posts (they donʼt have to be
long!) over the course of the assignment.
Important Breadcrumbs…
This Assignment has three tasks. However, we recommend you read the whole spec before
starting Task 1. Parts of different tasks may affect how you complete the assignment. Follow the
trail of breadcrumbs that leads to Task 3…
Put all of your answers to the following theory questions in your pair blog post.
For each refactoring change, before you start coding take some time to plan and write up a
design in your pair blog post. This should include:
a) From DRY to Design Patterns (7 marks)
i. Look inside src/main/java/dungeonmania/entities/enemies . Where can you notice an instance of
repeated code? Note down the particular offending lines/methods/fields.
ii. What Design Pattern could be used to improve the quality of the code and avoid repetition? Justify your
choice by relating the scenario to the key characteristics of your chosen Design Pattern.
iii. Using your chosen Design Pattern, refactor the code to remove the repetition.
b) Observer Pattern (5 marks)
Identify one place where the Observer Pattern is present in the codebase, and outline how the
implementation relates to the key characteristics of the Observer Pattern.
c) Inheritance Design (6 marks)
Currently, there is a significant flaw in the inheritance structure of entities.
Consider the following three methods in the Exit entity class.
What fields/methods you will need to add/change in a class
What new classes/packages you will need to create
After you finish coding, make a Merge Request into the master branch of your repository with
the following:
A meaningful MR title that encompasses the changes
A brief description which outlines the changes being made
Make sure to keep the MR as small as possible – don’t make any extra changes that arenʼt
absolutely necessary. Try to keep the number of files the changes touch to a minimum.
Make sure all the Continuous Integration checks (regression tests, linting, coverage) remain
Your partner will need to code review and either:
Leave comments in the MR with things to fix (you can do code reviews sync or async), requiring
you to iterate on the MR and resubmit for review; or
Approve the MR.
Once the MR is approved, copy and paste the link to your MR into your blog post.
Make sure to do this for each part of the question if you don’t you will lose marks.
public void onOverlap(GameMap map, Entity entity) {
public void onMovedAway(GameMap map, Entity entity) {
i. Name the code smell present in the above code. Identify all subclasses of Entity which have similar
code smells that point towards the same root cause.
ii. Redesign the inheritance structure to solve the problem, in doing so remove the smells.
d) More Code Smells (6 marks)
The previous engineering team has left you with the following note:
Collectable entities are a big problem. We tried to change the way picking up items is handled, to
be done at the player level instead of within the entity itself but found that we had to start making
changes in heaps of different places for it to work, so we abandoned it.
i. What design smell is present in the above description?
ii. Refactor the code to resolve the smell and the underlying problem causing it.
e) Open-Closed Goals (6 marks)
Look inside the goals package at the code provided.
i. Do you think the design is of good quality here? Do you think it complies with the open-closed principle?
Do you think the design should be changed?
ii. If you think the design is sufficient as it is, justify your decision. If you think the answer is no, pick a
suitable Design Pattern that would improve the quality of the code and refactor the code accordingly.
f) Open Refactoring (10 marks)
Make any other refactoring improvements you see fit to the codebase. This can include resolving Design
Smells, using Design Patterns discussed or any other general improvements to the health and quality of
Some areas and questions you can consider:
Look for violations of the Law of Demeter/Liskov Substitution Principle;
The effects of potions (invisibility and invincibility) has been implemented using a State Pattern.
However, the State Pattern hasn’t been used particularly effectively here and as a result, there is poor
The current implementation of buildable entities contains a significant amount of hard coding. Think
about how you can improve this.
The above list isnʼt exhaustive; there are plenty of other areas to improve the quality of the code.
public void onDestroy(GameMap gameMap) {
Task 2) Evolution of Requirements (50 marks)
In this task, you and your partner/group will need to complete Part A – Microevolution and the same
number of the following tasks as there are members in your group:
b) Bosses (10 marks)
c) Swamp Tile (10 marks)
d) Sunstone & More Buildables (15 marks)
e) Dungeon Generation (15 marks)
f) Logic Switches (20 marks)
The Time Travel task is an optional extension and are worth 0 marks.
E.g. If there are two of you, you need to pick two of the above tasks, if there are three of you, you pick
three. Each task has a different mark allocation based on its difficulty. You should pick tasks you feel
comfortable completing. If you complete extra tasks, that is fine – we will take your performance in the
best N tasks, where N is the number of people in your team.
If you are in a group of 3, your mark will be out of 65 and scaled to 50.
Write all your tests for this question inside the task2 folder.
Don’t make solutions to problems that donʼt exist yet! 🙂 Avoid over-engineering or over-abstracting
in places where you might want to improve the design for some future change in requirements –
instead improve the design of the current system. This will inherently make your software open-
Youʼll also want to split this task into one MR for each refactoring change you make.
Software Delivery – Task Lifecycle
For each part of this task, you will need to undertake the following process. This will help your tutor
assess your design during marking.
�. Requirements Engineering. Analyse the task requirements, including the technical and
product specifications. If you need to, make some assumptions and document these in your pair
blog post.
�. Detailed Design. In your pair blog post, plan out a detailed design for the task. This should
What fields/methods you will need to add/change in a class
What new classes/packages you will need to create
�. Design Review. Have your partner review the design, and go back and iterate on the design if
�. Create a Test List. Once the design is approved, write a test list (a list of all the tests you will
write) for the task. Map out each of the conceptual cases you want to test. This can be written
in your blog post, or if you want make function stubs for JUnit tests and put up a Merge Request
(link in your blog).
�. Test List Review. Have someone else in your team review the test list to make sure the test
cases all make sense and cover the input space.
You will need to write tests for the new functionality in an appropriate section of the test suite.
a) Microevolution – Enemy Goal (15 marks)
In this section you will need to make a series of small-scale changes and additions to the code based on
the following new requirements.
The following new goal has been introduced:
Destroying a certain number of enemies (or more) AND all spawners;
Other goal rules, including rules of conjunction/disjunction and exits must be completed last, still apply.
b) Bosses (10 marks)
In this task, you need to implement the following new entities.
Bosses are moving entities which are harder to defeat/conquer than normal enemies.
�. Create the Skeleton. Stub out anything you need to with class/method prototypes.
�. Write the tests, which should be failing assertions currently since the functionality hasn’t been
implemented.
�. Development. Implement the functionality so that your tests pass.
�. Run a usability test (check your functionality works on the frontend).
��. Where needed, refactor your code to improve the style and design while keeping the tests
��. Put up a merge request with your changes into master . The CI should be passing. The merge
request should have a meaningful title and contain a description of the changes you have made.
In most cases you should just be able to link them to your design/test list blog.
��. Code Review from your partner, iterate where needed then they should approve the MR.
Feel free to split tasks further where you see fit, especially for larger tasks (e.g. Time Travel). Keep
your Merge Requests small and make the iteration cycle short, incrementally building your MVP as
If you’ve done Task 1 well and have a nice healthy codebase, this task should be relatively
straightforward! If you’re finding parts of this task difficult to integrate with the existing design,
that’s probably a sign you need to do some more refactoring 🙂
Assassin Assassins are exceptionally powerful mercenaries which deal significantly
more damage. When bribing an Assassin, there is a certain chance that the
bribe will fail; the gold will be wasted and the Assassin will remain hostile.
Battles still do not occur with an Assassin when the player is invisible.
Hydra Hydras are generally considered to be a special creatures similar to
Zombies. Hydras are limited by the same movement constraints as
Entity Image Description
https://unswcse.atlassian.net/wiki/spaces/C2/pages/202965268/Part+One+Product+Specification+-+MVP#3.7.2-Complex-Goals
c) Swamp Tile (10 marks)
As part of this, you will need to extend your solution to accommodate the idea of a swamp tile. These are
tiles that have an x and y position and remain fixed throughout the entire game. They slow the
movement of all entities through them, except for the player and allies adjacent to the player. Each swamp
file has a movement factor which is a multiplying factor of the number of ticks it takes to traverse the tile.
For example, let us say the movement factor for a swamp tile is 2:
Tick 1: Move onto the swamp tile;
Tick 2: Stuck on the swamp tile;
Tick 3: Still stuck on the swamp tile;
Tick 4: Move off the swamp tile.
d) Sun Stone & More Buildables (15 marks)
i) a) Further Collectable Entities
In this task, the following collectable entities need to be added:
i) b) Further Buildable Entities
In this task, the following buildable entities have been added:
Zombies. In each round, when a hydra is attacked by the player, there is a
certain chance that its health will increase rather than decrease by the given
t t h d h b k h i t ff
Swamp Tile
Entity Image
Sun Stone A special form of treasure, hard and
treasuable. It can be picked up by the
player. Can be used to open doors, and
can be used interchangeably with
treasure or keys when building entities.
But it cannot be used to bribe
mercenaries or assassins. Since it is
classed as treasure it counts towards the
treasure goal. When used for opening
doors, or when replacing another material
such as a key or treasure in building
entities, it is retained after use. When
used as a listed ingredient in crafting, it is
Entity Image Description
Entity Image Description
https://simple.wikipedia.org/wiki/Lernaean_Hydra
e) Dungeon Generation (15 marks)
In this extension, instead of specifying an existing dungeon to play, players can choose specify a dungeon
to be automatically generated when creating a new game.
As part of this, you will need to be able to automatically generate dungeons. Furthermore it’s important
that you have an exit at the end position and that you have exit goals setup for this created dungeon.
3.12.1 Generating a Dungeon – Randomized Prim’s Algorithm
You will need to generate dungeons according to the following maze generation algorithm (which is just a
randomised version of Prim’s).
3.12.2 Frontend Code
In order to implement the frontend for this task youʼll need to modify the TypeScript code inside
client/src .
More Guidance
f) Logic Switches (20 marks)
There are three new entities in this extension:
Sceptre Can be crafted with (1 wood OR 2 arrows)
+ (1 key OR 1 treasure) + (1 sun stone). A
character with a sceptre does not need to
bribe mercenaries or assassins to
become allies, as they can use the
sceptre to control their minds without any
distance constraint. But the effects only
last for a certain number of ticks.
Midnight Armour Can be crafted with (1 sword + 1 sun
stone) if there are no zombies currently in
the dungeon. Midnight armour provides
extra attack damage as well as
protection, and it lasts forever.
This task involves modifying the frontend code; if you’re interested in learning a bit of frontend and
trying TypeScript then have a go!
If you attempt this task we canʼt guarantee assistance on the forums for the frontend component.
Light Bulb Light bulbs cannot be collected, but can
be lit up by satisfying the logical
Entity Image Description
If a switch cardinally adjacent to a wire is activated, all the other logical entities cardinally adjacent to
the wire are activated. This allows for the creation of dungeons with logic circuits. For example:
v) a) Logical Entities
Entities which interact via switches can become “logical” entities with a specified configuration value:
Light Bulbs (see above)
Switch Doors (see above)
Bombs also now have the option to be created as logical entities with a specified configuration value.
Bombs which have this attribute will only explode when their logical condition is fulfilled. Bombs created
without this value will interact with switches in the same way as they do in the MVP, and do not interact
with other logical entities or wires.
Switches are not logical entities, but instead activate cardinally adjacent logical entities, also known
as conductors when they are switched on. When placed next to another already activated entity, they
behave akin to wires in a circuit if they are switched on. Light bulbs and switch doors do not act as
wires in a circuit.
All switches will be created in inactive state as well as all the logical entities.
All other entities cannot be part of the circuit. They can be placed adjacent to the logical circuit but donʼt
have any effects.
v) b) Logical Rules
Entities will be logical according to one of the following rules:
condition. They are always created as a
logical entity.
Light bulbs will always be created off.
Wire Wires cannot be collected, but form part
of a circuit as a conductor and are
connected to a switch and can also
connect to any entity that can be
activated via switches (Light Bulb, Switch
Door). Wires are not themselves logical
entities. Any moveable entity can walk
onto a wire.
Switch Door Switch doors are always created as a
logical entity, and can be opened when
their logical condition is satisfied.
They cannot be opened with a key. The
door should only remain open as long as
its condition for opening is still true.
AND – the entity can be activated if there are 2 or more cardinally adjacent activated conductors. If
there are more than two conductors, all must be activated
OR – the entity will be activated if there is 1 or more cardinally adjacent activated conductor
XOR – the entity will be activated if there is 1 and only 1 cardinally adjacent activated conductor
CO_AND – the entity will only be activated if there are 2 or more cardinally adjacent activated, which
are all activated on the same tick, e.g. if a switch activates two wires that are both cardinally adjacent
to a logical entity with the CO_AND condition, it should be activated.
g) Time Travel (Bonus – 0 marks)
This task isnʼt worth any marks. It s̓ just a hard problem
i) Time Turner
This part of the extension includes the following new entity:
If the player has collected a time turner, then two rewind buttons will appear on the frontend. When
clicked, these buttons move the state of the game back one tick and 5 ticks respectively and “transport”
the current player back to those game states in a time travelling fashion.
ii) Time Travelling Portal
This part of the extension includes the following new entity:
If a player travels through a time travelling portal, they end up on the same square as the portal, except
the dungeon state is that of 30 ticks previously. If less than 30 ticks have passed, then the dungeon state
is simply the initial dungeon state.
iii) Time Travel Rules
When a character has time travelled, either by the rewind buttons or via a time travelling portal:
Their ‘older self’ still exists in the dungeon as its own entity. If they encounter their older self and are
invisible, then nothing happens. If not, then a battle ensues.
The older self should take the same path as was taken initially, and unless they encounter their ‘current
self’ (they character being controlled), should eventually travel through the time portal and disappear
from the map.
The player’s inventory persists across time travelling. This means that if a player picks up a sword then
travels through a time portal, the sword remains in their inventory as well as being back on the map
available to pick up.
The older self is in the enemy party and doesnʼt fight the enemies.
Time Turner
Entity Image
Time Travelling Portal
Entity Image
Mercenaries and assassins follow the current player, not the older player
The behaviour when time-travelling occurs more than once in a single game instance is undefined.
Only the player can travel through time travel portals.
The older player should still collect items and play out all tick and interact movements with those
items as they did before.
Note that usage of a time turner (a rewind operation) is not the same as travelling through a time
portal – the latter takes up a tick, whereas the former does not.
The following diagram should help you understand the state transitions for time travel.
Tick Diagram: Time Travel
Implementation Hint
Task 3) Investigation Task (5 marks core + 5 marks bonus)
How confident are you that your software satisfies the requirements?
You will need to review the codebase and specification to ensure that all the requirements are correctly
implemented, including the MVP implementation (provided by the previous engineering team). If you
discover that the software fails to correctly implement any of the requirements, explain how you came to
your conclusions in your blog post and outline the steps you took to address the problems in your pair
blog post.
This task is intentionally meant to challenge your ability to think outside the box, explore and investigate.
3. Tidbits
Git Practices
We will not be assessing your commit messages, though for the sake of good practice you
should write meaningful commits.
Instead, when you merge a branch into master select the Squash Commits option. This will
squash all of your branch-specific commits into a single commit during merge. Make sure to
uncheck the delete branch option so that your branch is preserved.
The master branch should always remain stable – the pipeline should always be passing. You
are welcome to comment out some of the example tests we have provided until you can get
them working locally.
When putting up Merge Requests, all changes in the diff should be relevant to the task which
they relate to (not polluted with irrelevant changes, as this makes it difficult for reviewers);
Code reviews should occur as comments on Merge Requests – if you are doing the code review
synchronously leave comments on the MR as your minutes/action items
Assumptions
As you develop your implementation of the Tasks you will undoubtedly come across scenarios
where the behaviour is not defined by the rules of the specification. This is a complicated
assignment if we defined every single scenario, the spec would go on forever. Unlike previous
4.1 Individual Blogging
As well as your pair blog, you will need to complete individual blog post/s each week. These can be more
reflective than descriptive, since your design decisions should be documented in your pair blog post.
Each week you can give a brief summary of how things are going, what challenges you are facing and
what you want to change next week. In the final blog post you will also need to briefly write about how you
think you went overall in the assignment, the challenges you faced and what you learned completing the
You will also need to put in links to all your Merge Requests.
We will use these blog posts to determine individual marks in the case where pair contribution is not
equal. You can make your individual blog accessible to staff only if you like.
courses this course is about design, we are not trying to catch you out by testing every single edge
case imaginable. The autotests are there to check you followed the spec and check you did the
work, not to catch you out on niche edge cases.
Here are the steps you should follow if you are unsure about something in the spec:
�. Double check the spec, do a ctrl/command-f to check it isn’t mentioned elsewhere, in a lot of
situations this will be the case.
�. Check the Approved Assumptions document, all of the approved assumptions from
previous terms are there and new ones will be added if they come up.
�. Make a post in the forum (please search first) asking the Course Staff whether you are able to
make an assumption about the behaviour in this case.
We will either:
a. Approve the assumption and add to the Approved Assumptions page
b. Update the specification if appropriate, or
c. Respond explaining how the behaviour is defined in the scope of the specification.
Any ambiguities/assumptions that we have listed as approved we will not be testing in
automarking.
Test Design
When it comes to writing tests for the new features, you should write functional tests on the
controller.
All of the existing tests in the monolith are written in this way, and you can structure your tests
similarly.
Dungeon Map Helper
Weʼve provided a dungeon map helper for you here to assist with visualising and creating test
maps. Please note it may contain some bugs!
4.2 Interview
During your Week 10 Lab, you and your partner will have a short (7 minutes) interview with your tutor or
lab assistant regarding the design of your solution.
You will not be directly assessed on this interview – it is an opportunity for your tutor to give you some
initial feedback on your design, and demonstrate an understanding of your refactoring changes,
extensions and mystery task if you completed it.
You will not be able to take any notes into the interview, as you should be familiar enough with your
solution to speak to it in depth. Your tutor will lead the interview and give you prompts for you to talk
about your design. You can also consider the writing of your blog posts as preparation for the interview.
5. Assessment
5.1 Marking Criteria
Put links to all your individual posts and your pair post inside blog.md in your repository.
a) From DRY to Design Patterns (7 marks) Has the smell been pinpointed?
Has a suitable Design Pattern been selected and
justified?
Was the pattern well implemented?
b) Observer Pattern (5 marks) Was the pattern identified, with key characteristics in the
implementation described in sufficient depth?
c) Inheritance Design (6 marks) Was the design smell identified? Were all the relevant
classes identified?
Was the design flaw resolved?
d) More Code Smells (6 marks) Was the design smell identified?
Was the design flaw resolved?
e) Open-Closed Goals (6 marks) Is the stance justified according to the design?
If applicable, was any refactoring done to improve the
f) Open Refactoring (10 marks) For 3 marks, some additional smells/flaws are identified and
For 5 marks, listed additional smells/flaws (or equivalent)
are identified and resolved.
For 10 marks, all additional smells/flaws are identified and
Task Subtask Criteria
5.2 Automarking
5.2.1 Autotest Feedback
We will provide you with some formative autotest feedback prior to submission. On Tuesday 25th July
(Week 9) at 8am, we will take the latest commit on your master branch and run that against our autotest
suite. By 6pm that night, we will provide you with a set of results that contain:
For a subset (a) of our tests, the name of the test, whether you passed or failed it, and if you failed
what the error was;
For each subtask completed;
a) Microevolutions – Enemy Goal (15 marks)
Number of team members of:
b) Bosses (10 marks)
c) Swamp Tile (10 marks)
d) Sunstone & More Buildables (15 marks)
e) Dungeon Generation (15 marks)
f) Logic Switches (20 marks)
Software Correctness (40% of the marks for the
This section will be automarked.
Software Design (50% of the marks for the subtask)
Is the design seamlessly integrated into the existing
infrastructure?
Does the design adhere to principles discussed in the
Does the design contain any smells?
Software Testing (10% of the marks for the subtask)
Have functional tests on the controller been written?
Do the tests cover a range of cases?
Are the tests well designed?
Task 3 5 marks core + 5 marks bonus How well was the investigation completed?
Easy Marks
CodeHygiene You will get 0/5 marks in this Easy Marks section if the
following are not maintained:
All regression tests remain passing
Code Coverage remains above 80%
The linter remains passing
In simpler terms, you must maintain a passing pipeline on
the master branch of your repository throughout the entire
assignment.
Merge Requests You will get 0/5 marks in this Easy Marks section if the
following are not maintained:
Have Merge Requests that are too large and contain too
many changes
Donʼt link your Merge Requests in your blog post
This is to make it easier for your marker to award you for
your work. If you stick to the blog template you will be fine
For another subset (b) of our tests, whether you passed or failed, with all other output redacted. The
test name will be redacted to “Hidden test”, though the section under which it is testing will be made
available.
The autotest mark you would receive if that was your submission.
There will not be more than one feedback run prior to the deadline for each submission.
In some cases we may update our autotests between the initial feedback run before the deadline and the
actual marking of your submissions, as our tests may contain some small errors due to the nature and
scale of the project. If this occurs we will post on the forum informing which tests are changing and how
they have been changed/corrected.
If you are unsure why you are failing a specific test, review your code and the specification, and if you are
still unsure please post on the forum and we will be able to provide you with some support.
5.2.3 Autotest Re-Runs
Following the release of automarks, pairs may request a re-run if the pair has failed more than 30% of the
autotests due to one or two minor issues in their code. The pair can make a patch of up to 20 lines
difference and push this patch to a branch wh