INFO1113 / COMP9003 Assignment
Due: 22 October 2023, 11:59PM AEST
This assignment is worth 20% of your final grade.
Task Description
In this assignment, you will create a game in the Java programming language using the Processing library
for graphics and gradle as a dependency manager. In the game, the player must be able to place and
upgrade towers strategically on a map to prevent enemies from reaching the wizard’s house. Mana is the
currency of the game used to buy and upgrade towers. Each time an enemy reaches the wizard’s house,
mana must be expended to banish it. The goal is to survive all waves of enemies without letting the
wizard’s mana run down to 0.
You have been given the task of developing a prototype of the game. A full description of gameplay
mechanics and entities can be found below. An artist has created a simple demonstration of the game
and has posted it on your online forum (Ed). You can also play a similar game here.
You are encouraged to ask questions on Ed under the assignments category if you are unsure of the
specification – but staff members will not be able to do any coding or debugging in this assignment for
you. As with any assignment, make sure that your work is your own, and do not share your code or
solutions with other students.
Working on your assignment
You have been given a scaffold which will help you get started with this assignment. You can download
the scaffold onto your own computer and invoke gradle build to compile and resolve dependencies. You
will be using the Processing library within your project to allow you to create a window and draw
graphics. You can access the documentation from here.
INFO1113
Page 2 of 11
Gameplay
The game contains a number of entities that will need to be implemented within your application.
Board
The board consists of a grid of tiles 20x20. Each tile is 32x32 pixels, so the total is 640x640 pixels.
However, there are 40 pixels at the top reserved for information such as the timer indicator for when the
current wave will end or the next one will start, and the wizard’s current mana. There is also 120 pixels on
the right sidebar for the gameplay action buttons and information about upgrade cost. The window size is
therefore 760x680.
There are 4 main types of tiles:
• Grass – towers can be placed here
• Shrub – towers cannot be placed here
• Path – enemies traverse the path to try and reach the Wizard’s house
• Tower – it shoots fireballs at enemies within its range
• Wizard’s house – there can only be one on each map. If enemies reach here, they are banished by
the wizard, causing loss of mana equivalent to the monster’s remaining HP and then the monster
is respawned on the map.
The initial map layout is defined in a file named in the “layout” attribute of the JSON configuration file
described below.
Figure 1.
The cost tooltip is
shown when the
user hovers over the
“Build tower” or
“Mana pool” action
buttons with their
mouse.
INFO1113
Page 3 of 11
Config
The config file is in located in config.json
in the root directory of the project (the
same directory as build.gradle and the
src folder). Use the simple json library to
read it. Sample config and level files are
provided in the scaffold.
The map layout file is also located in the
root directory of the project. The layout
file will contain a grid of text characters,
where each character represents the tile
that should initially be in that position on
the map.
• Spaces are Grass
• S = Shrub
• X = Paths
• W = Wizard’s house
Note that the wizard’s house is 48x48
pixels and should be centred within its
tile. It is rendered on top of nearby tiles
and any enemies.
A function has been provided to you in
the scaffold code to rotate the path tiles
in order to create the full set of possible
path tiles that may be needed.
Waves
The configuration file contains a list of waves in the “waves” attribute. Each wave occurs in the sequence
it is provided there. During a wave, monsters spawn randomly on paths leading outside the map. A wave
is defined in the config file with the following properties:
• pre_wave_pause: Number of seconds to wait before the wave begins. This begins counting
after the duration of the previous wave has ended (or in the case of the first wave, immediately
when the game starts).
• duration: Seconds during which this wave spawns monsters. The monsters will spawn
randomly in equal intervals. For example, if the duration is 5 seconds, and there are a total of 25
monsters in this wave, there should be 5/25 = 0.2 seconds between each monster spawn, or at 60
frames per second (FPS), 12 frames in between monster spawns.
INFO1113
Page 4 of 11
• monsters: A list of monster types to spawn during this wave. The wave may contain multiple
different types of monsters, and will choose a type at random when spawning each one (as long
as there is quantity of that type remaining for this wave). The total number of monsters in the
wave is the sum of quantities for all types provided in this list.
The top left corner of the GUI should indicate the time in seconds until the next wave begins with “Wave
starts: ”. If the last wave has begun, display nothing.
Once the last wave has been completed and all monsters are dead, the player wins the game.
Monsters
Monsters initially spawn outside the map on paths that join with the edge of the map. The spawn point is
determined randomly out of all available locations. They travel on paths towards the Wizard’s house. The
below configuration options define a monster type (as part of a wave):
• type: the sprite image to use for the monster (png file extension)
• hp: amount of max hit points (initial health) the monster has
• speed: how fast the monster’s movement is in pixels per frame
• armour: percentage multiplier to damage received by this monster
• mana_gained_on_kill: How much mana the wizard gains when this monster is killed
A monster’s current hp should be shown as a proportion of their original hp above their sprite, with a
green and red bar (see image on page 2).
When a monster dies, there is a death animation with each image lasting 4 frames:
Towers
Towers can be placed by the player in empty grass tiles, by first activating the tower action (either clicking
on the T button in the right sidebar, or pressing the key ‘t’), then clicking on the space they want the
tower to be placed. The following configuration options are relevant for towers:
• tower_cost: The cost in mana to place a tower. Depending on if upgrades are selected, the
initial tower cost may have +20 (one upgrade), +40 (two upgrades) or +60 (three upgrades).
• initial_tower_range: The radius in pixels from the center of this tower within which it is
able to target and shoot at monsters.
• initial_tower_firing_speed: Fireballs per second rate that this tower shoots at.
• initial_tower_damage: Amount of hitpoints deducted from a monster when a fireball from
this tower hits it. If the monster’s health reaches 0, then it dies.
Towers may be upgraded by the player by selecting the upgrade action for either range, speed or damage
(either via clicking the option in the left sidebar, or pressing keys ‘1’, ‘2’ or ‘3’ respectively). Then, the
player must click a tower to upgrade. Before clicking the tower, just by hovering over it, the cost of the
upgrade will be shown in the bottom right corner of the screen, as below.
Multiple upgrade options may be selected at the same time. If the wizard doesn’t have enough mana for
all of them, then only the ones they can afford will be purchased (in order as they appear in the actions
column: range, speed, then damage). The player cannot cause themselves to lose on purpose by spending
more mana than they have.
INFO1113
Page 5 of 11
The player may also build towers with initial upgrades of level 1 by having the upgrades action selected
together with the “build tower” action when placing the tower.
Examples of tower upgrades and how they appear
on the tower image:
Range level 1
Damage level 1
Speed level 1
Speed level 3
Range level 3
Range level 2 and damage level 3
Range, speed and damage all lvl 1
Level 1 in range and damage, level
2 in speed.
Range level 3, speed level 2
Range, speed and damage all lvl 2
Tower upgrade cost:
The upgrade cost depends on the level. It is 20 mana for level 1, then increases by 10 for each subsequent
level. This means level 2 costs 30, level 3 costs 40, etc. This cost is for each upgrade, so to upgrade to level
Figure 2.
The upgrade cost is
shown only for
upgrade options
that have been
selected. In this
case, the tower was
already upgraded to
damage lvl 1, so the
upgrade cost is 20
for speed lvl1 and
30 for damage lvl2.
Note that the
tower’s range
radius is also
highlighted in
yellow when the
player’s mouse
hovers over it.
Upgrade symbols:
The range upgrade level is denoted by magenta
“O”s at the top of the image.
The speed upgrade level is denoted by the thickness
of a blue border in the centre of the image.
The damage upgrade level is denoted by magenta
“X”s at the bottom of the image.
Once level 1 of all upgrades is reached, the tower
becomes orange (and no longer displays the
indicators for level 1, only levels 2+). Similarly, if
level 2 is reached in all upgrades, then it becomes
red (and will only use the individual symbols X, O
and blue border for levels 3+).
INFO1113
Page 6 of 11
1 fully in all of range, speed and damage, would cost 60 mana. Then to upgrade to level 2 fully would cost
another 90 mana.
Tower upgrade effects for each upgrade level:
• Range upgrade: tower range radius increases by 1 tile (32 pixels)
• Speed upgrade: Firing speed increases by 0.5 fireballs per second
• Damage upgrade: Damage dealt increases by half of initial_tower_damage
Fireballs
Fireballs are created by towers to shoot an enemy currently within their range. The choice of which
enemy to shoot is arbitrary. Fireballs move at a speed of 5 pixels per frame. A fireball originates at the
centre of the tower and targets the centre of the enemy it was fired at. When it reaches the centre of that
enemy, it damages the enemy.
Wizard
The Wizard’s house is the destination for monsters. When a monster reaches the wizard’s house, the
monster is ‘banished’ – mana equal to the monster’s remaining HP is expended in order to make the
monster respawn and navigate the path again.
The Wizard’s house should be rendered
on top of other tiles and any monsters.
Mana
The wizard’s mana is visible in an aqua bar at the top of the screen, as shown in images previously. There
is a mana cap – additional mana is not gained if the cap is reached. The initial values of these are set by
the configuration options initial_mana and initial_mana_cap. A small trickle of mana is also
gained as time passes, specified in the configuration attribute
initial_mana_gained_per_second.
Mana Pool Spell
The mana pool spell is a special action that can be done at any time to increase the wizard’s mana cap and
add a multiplier to mana gained from monster kills and the mana trickle. The following configuration
options are relevant:
Figure 3.
Note that the yellow tower range
radius indicator (when the mouse
hovers over a tower) should appear
behind the top bar of the GUI that
contains the mana indicator and
wave timer, as well as behind the
right bar containing the action
buttons.
INFO1113
Page 7 of 11
• mana_pool_spell_initial_cost: The initial cost of
the spell, in mana.
• mana_pool_spell_cost_increase_per_use: How
much the spell’s cost should increase after each use.
• mana_pool_spell_cap_multiplier: The multiplier
to use for increasing the mana cap when the spell is cast (its
effect is multiplied when activated multiple times).
• mana_pool_spell_mana_gained_multiplier:
The multiplier to use for increasing mana gained from killing
monsters and the mana trickle when the spell is cast. Its
effect is added if the spell is cast multiple times (eg. 1.1 is
+10% bonus to mana gained, which would become +20% if
the spell is cast twice, or +30% if cast 3 times).
Gameplay Actions
The gameplay actions available to the player are listed in the right sidebar. When the player hovers their
mouse over one of these options (when unselected), it should turn grey. When selected, it should be
highlighted yellow. If clicked while selected, it will be unselected. Multiple options may be selected at
once. Each action has a corresponding key that also may be pressed to toggle the option. The actions are:
• Fast forward (FF) – key: f. The game will run at 2x speed – meaning anything that takes time is
sped up, including monster movement, wave timers, tower firing speed, and mana increment.
Unselecting this option will resume normal speed.
• Pause (P) – key: p. The game will be paused and in a frozen state. Unselecting this option resumes
the game. While paused, the player is still able to build and upgrade towers or cast the mana pool
spell.
• Build tower (T) – key: t. When selected, allows the player to click a grass tile on the map to place a
tower there (provided they have enough mana). If they don’t click a grass tile, or don’t have
enough mana, this selection has no effect. The cost should be displayed when the mouse hovers
over this option. The cost is only deducted when the tower is placed though, not when this option
is selected.
• Upgrades (U1, U2, U3) – keys: 1,2,3. Allows the player to upgrade towers. May also be combined
with build tower.
• Mana pool spell (M) – key: m. When selected, will activate the Mana Pool spell (see above on
page 6) and then immediately deactivate. Cost should be displayed when the mouse hovers over
it, and in the text description.
Win and lose conditions
The game ends in a win for the player when all waves are over and all monsters have been defeated.
Display “YOU WIN” on the screen.
The game ends in a loss when a monster reaches the wizard’s house with a banishment cost (current HP)
greater than the wizard’s current mana balance. Display “YOU LOST” on the screen, along with an option
to restart the game by pressing the ‘r’ key. Restarting should cause everything in the game to be reset to
its original state.
INFO1113
Page 8 of 11
Application
Your application will need to adhere to the following specifications:
• The window must have dimensions 760x680
• The game must maintain a frame rate of 60 frames per second.
• Your application must be able to compile and run using Java 8 and gradle run. Failure to do so, will
result in 0% for Final Code Submission. Later versions of Java may work, but you should not use
any newer Java language features.
• Your program must not exhibit any memory leaks.
• You must use the processing library (specifically processing.core and processing.data), you cannot
use any other framework such as javafx, awt or jogl
You have been provided a /resources folder which your code can access directly (please use a relative
path). These assets are loadable using the loadImage method attached to the PApplet type. Please refer
to the processing documentation when loading and drawing an image. You may decide to modify these
sprites if you wish to customise your game. You will be required to create your own sprites for any
extensions you want to implement.
Extension
The extension is worth 2 marks maximum. For an extension, you can choose to implement one of the
following:
• New type of tower with special behaviour (eg. freeze enemies, poison, splash damage)
• New type of building construction (eg. walls or traps)
• New type of user gameplay action (eg. inventory containing items that can be purchased and
dropped on monsters to cause damage to them)
• New game mode (specified in config or initial game start menu) with unlimited waves where
monsters get progressively stronger
• Ability to save and load games to and from a save file
• Sound effects (partial marks only unless another extension is also attempted)
• Multiple levels specified in the config that are loaded after the current level is beaten
OR, a feature you come up with which is of a similar or higher level of complexity (ask your tutor)
Please ensure you submit a config and level layout file with the features of your extension, and ensure the
extension doesn’t break any of the default behaviour. Also, describe your extension functionality in the
report.
Marking Criteria (20%)
Your final submission is due on Sunday 22 October at 11:59PM. To submit, you must upload your
build.gradle file and src folder to Ed. Please also include sample config and layout files that you have
tested with your program to ensure it works. Do NOT submit the build folder (unless you only include the
build/reports/ folder which contains the results of your testing and code coverage). Ensure src is in the
root directory with the other files, and not part of a zip, then press MARK. Submit your report and UML to
canvas.
INFO1113
Page 9 of 11
A demo of your assignment will be conducted during labs in week 12 where you will demonstrate the
features you have created to your tutor.
Final Code Submission and Demo (12%)
You will need to have implemented and satisfied requirements listed in this assignment. Make sure you
have addressed the following and any other requirements outlined previously.
• Window launches and shows map layout correctly.
• Path display is correct
• Configuration file is correctly read in – initial values for game state are used from config
• Waves of monsters spawn according to the configuration
• Wave timing is correct
• Game action buttons respond to mouse hover and click. Key press also works as an alternative to
toggle the selection.
• Can place a tower only in empty grass cells
• Mana cost is correctly deducted for purchases and insufficient mana disallows purchases
• Can upgrade towers
o Indicator is shown correctly for different individual upgrades (speed, range, damage)
o Tower image changes to orange and red when all of level 1 or level 2 upgrades are done
o Upgrades cause noticeable changes in tower behaviour for range, speed and damage
dealt
o Towers can be built with some initial upgrades if the upgrade option is selected
• Enemies spawn correctly outside of the map and come from paths connected to the edge of the
map (randomly chosen).
• Enemies move only on paths
• Enemy movement is smooth and correct speed
• Enemies accurately traverse junctions towards the Wizard’s house
• Towers shoot fireballs at enemies within their range
• Fireballs are displayed correctly and move at the correct speed
• Fireballs cause loss of health to enemies, and when the monster’s health reaches 0, it dies
• Death animation for monsters with each image lasting 4 frames
• If an enemy reaches the wizard’s house, it is banished
• Banished monsters respawn correctly and cause a deduction of mana equal to their remaining hp
• Mana pool spell causes an increase to the mana cap and multiplies mana gained
• GUI elements:
o Tooltip for upgrade cost
o Tower range radius highlighted on hovering over it
o Health bar displayed above enemies
o Mana bar displayed correctly
• Fast forward doubles the game speed, and pause action freezes the game
• Game ends in a loss if wizard doesn’t have enough mana to banish a monster
• Game ends in a win if all waves are complete and all enemies defeated
• Player can restart the game by pressing ‘r’
• Ensure that your application does not repeat large sections of logic
• Ensure that your application is bug-free
INFO1113
Page 10 of 11
Testcases (3%)
During development of your code, add testcases to your project and test as much functionality as
possible. You will need to construct unit test cases within the src/test folder using JUnit. To test the state
of your entities without drawing, implement a simple loop that will update the state of each object but
not draw the entity.
Ensure your test cases cover over 90% of execution paths (Use jacoco in your gradle build) Ensure your
test cases cover common cases. Ensure your test cases cover edge cases. Each test case must contain a
brief comment explaining what it is testing. To generate the testing code coverage report with gradle
using jacoco, run “gradle test jacocoTestReport”.
Design, Report, UML and Javadoc (3%)
You will need to submit a report that elaborates on your design. This will include an explanation of any
object-oriented design decisions made (such as reasons for interfaces, class hierarchy, etc) and an
explanation of how the extension has been implemented. This should be no longer than 500 words. This
report will be submitted through Canvas.
You will need to submit a UML diagram in PDF form to Canvas to provide a brief graphical overview of
your code design and use of Object Oriented Principles such as inheritance and interfaces. Markers will
use this to determine whether you have appropriately used those principles to aid you in your design, as
well as figure out whether more should have been done. A general guideline is that markers will be
looking for some use of inheritance or interfaces, how extensible the code is, and penalising repeated
code. Note that you should not simply use a UML generator from an IDE such as Eclipse, as they typically
do not produce diagrams that conform to the format required. We suggest using software such as
LucidChart or draw.io for making your diagrams.
Your code should be clear, well commented and concise. Try to utilise OOP constructs within your
application and limit repetitive code. The code should follow the conventions set out by the Google Java
Style Guide. As part of your comments, you will need to create a Javadoc for your program. This will be
properly covered in week 11 but the relevant Oracle documentation can be found here.
Report, UML and OO design: 2%
Javadoc, comments, style and readability: 1%
Extension (2%)
Implement an extension as described above. Partial marks may be awarded if you choose a more limited
extension or it is partially completed. Please specify what extension you decided to implement within
your report.
Suggested Timeline
Here is a suggested timeline for developing the project. Note that it is released on September 12 (start of
week 7) and due October 22 (end of week 11).
Week 7: Familiarise yourself with gradle and processing, utilising the processing Javadoc and week 8
supplementary lecture. Identify opportunities to utilise Object Oriented Design principles such as
inheritance and interfaces and begin to plan a design for the codebase with regards to the classes that
you will need to make. Make a rough UML diagram for your design that you can base your codebase from.
INFO1113
Page 11 of 11
Week 8: Begin writing the actual code for the program. Start small, for example by initially creating the
map layout and tiles, then gradually add more elements. At the end of the week, you should have loading
in the map and enemy movement finished, as well as some sprite management. If confident, use Test
Driven Development (writing test cases at same time as writing the code). Conduct a large amount of user
testing to ensure the initial mechanics work as expected.
Weeks 9-10: Develop more gameplay features, such as the action buttons (adding and upgrading towers),
shooting fireballs, mana display and the mana pool spell. Sprite management should be streamlined at
this point. You should have a fairly high code coverage for your test cases at this stage. If you are noticing
any questionable design decisions, such as God classes or classes that are doing things they logically
should not be doing, this is the time to refactor your code. Think about what extension you want to make
and start to implement it.
Week 11: Finish developing the remaining features for your program, notably the configuration file, GUI
enhancements, and timer for waves. Additionally, finish writing your testing suite. Create the UML and
Javadoc for the program. Fix any remaining bugs that your code exhibits. Submit your code to Ed (by
uploading the entire project and pressing MARK) and submit your UML to Canvas in PDF form.
Week 12: Demonstrate the completed program to your tutor during the week 12 lab. They will check each
criteria item has successfully been completed, and may ask you questions about how you implemented it
to test your understanding.
Academic Declaration
By submitting this assignment you declare the following:
I declare that I have read and understood the University of Sydney Student Plagiarism: Coursework Policy
and Procedure, and except where specifically acknowledged, the work contained in this
assignment/project is my own work, and has not been copied from other sources or been previously
submitted for award or assessment.
I understand that failure to comply with the Student Plagiarism: Coursework Policy and Procedure can lead
to severe penalties as outlined under Chapter 8 of the University of Sydney By-Law 1999 (as amended).
These penalties may be imposed in cases where any significant portion of my submitted work has been
copied without proper acknowledgment from other sources, including published works, the Internet,
existing programs, the work of other students, or work previously submitted for other awards or
assessments.
I realise that I may be asked to identify those portions of the work contributed by me and required to
demonstrate my knowledge of the relevant material by answering oral questions or by undertaking
supplementary work, either written or in the laboratory, in order to arrive at the final assessment mark.
I acknowledge that the School of Computer Science, in assessing this assignment, may reproduce it
entirely, may provide a copy to another member of faculty, and/or communicate a copy of this assignment
to a plagiarism checking service or in-house computer program, and that a copy of the assignment may be
maintained by the service or the School of Computer Science for the purpose of future plagiarism checking.