INFO1113 Assignment

Due: 1 May 2022, 11:59PM AEST
This assignment is worth 18% 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 avoid enemies that are
bouncing around the map, whilst capturing area. Once a percentage of the map area has been captured,
the level is won.
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 8

Gameplay
The game contains a number of entities that will need to be implemented within your application.
Map
The map consists of a grid of tiles 64x32. Each tile is 20x20 pixels, so the total is 1280x640 pixels. The
player always begins in the top-left corner of this grid. However, the top 80 pixels of the window are
reserved for the information bar which contains text to display the current number of lives, progress
towards the goal, level number, and timer remaining on the powerup’s effect. The window size is
therefore 1280x720.

There are 3 main types of tiles:
• Cement
• Grass (filled)
• Dirt (empty)
• Path (green - in progress)
• Path (red – hit by enemy)
The map is always surrounded by cement tiles. Additional cement tiles may be placed as specified by the
level file in the config (see below).





INFO1113

Page 3 of 8

Config
The config file is in located in config.json in the root
directory of the project. Use the simple json library to
read it. Sample config and level files are provided in
the scaffold.
The config sample as shown to the left, contains the
names of the level files. These are also located in the
root directory of the project. The level files will
contain a grid of text characters, where each
character represents what should be in that tile cell. X
marks where cement tiles should be placed. Spaces
are empty space (dirt/soil). Note that a map is valid if
it has a bounding border of cement tiles. (all maps
used for marking will be valid, but you should write
your own tests for invalid maps and handle them as
you see fit).
Type 0 enemy is the standard worm. Type 1 is the
beetle.
The spawn location of the enemies can either be
“random” (within the current empty space) or a
specified coordinate value such as “10,23” to signify
row 10, column 23 on the tile grid. Or “3,18” to signify
row 3, column 18”. The enemy should spawn in a
random pixel location within that tile.




Player
The player character is controlled using the arrow keys (up, down, left, right). Movement should be
smoothly transitioning from one tile space to another. The player always begins in the top-left corner of
the map. While on cement tiles, the user must be actively holding the movement key for movement to
occur, otherwise movement stops. When the player enters a dirt (empty) region, movement continues
even if the user releases the movement key. The same velocity and direction is maintained until another
direction key is pressed (if it’s the opposite direction, nothing happens).
For example: the down key is pressed. The player enters the soil region. The down key is released, but the
player keeps moving downwards. If the up key is pressed, the player continues moving downwards. If the
left key is pressed, then the player makes a left turn and starts moving left. This behaviour is the same for
filled regions (grass).
INFO1113

Page 4 of 8

The player’s goal is to fill as much of the soil with grass while avoiding enemies. It does so by laying a
green path behind it as it moves, and when it closes the path by reaching a safe tile (either a concrete tile
or a grass tile), the regions enclosed on either side of the path will be filled with grass if there are no
enemies within them. If there are enemies within both, then only the path itself becomes grass.
If an enemy hits the path while the player is laying it out and before it has reached a safe tile, the path tile
it hits will turn red and propagate outward towards the player at a rate of one tile every 3 frames. If the
red path hits the player before it reaches a safe tile, one life is lost and the player respawns in the top left
corner.
If the player circles back and hits their own in-progress path, they lose a life and respawn.
The player’s movement speed is 2 pixels per frame.
Enemies
There are two main enemies: worms and beetles. The worm is the basic one and the beetle has the same
functionality as the worm, except when it hits a grass tile, it becomes soil (empty) again. And it also has a
different sprite.
These enemies move always in only one of 4 diagonal directions. Upon hitting a wall, they bounce off and
start moving in the reflected direction.
The initial enemy positions are determined by the configuration file. It can either be “random”, to spawn
randomly in a location within the empty space, or a specified coordinate value on the board.
Enemy movement speed is 2 pixels per frame in both the x and y directions.
Powerups
A powerup is an item that can be collected by the player upon moving to that location on the board
(player character collides with it directly). Powerups should always spawn in the empty area (soil) so there
is some risk for the player in retrieving them. Please be creative in designing the sprite for the powerup
you decide to implement. The functionality could be any one of the following things:
• Make enemies slow down for a timed period
• Make the player speed up for a timed period
• Make the player invincible for a timed period (if enemies hit the path being laid, then they just
bounce off) – (optional: if the player hits an enemy, it respawns somewhere else on the empty
areas of the map). Enemies should have some kind of visual indication that their behaviour has
changed – maybe a border around them, or different colour.
• Make enemies freeze for a timed period
• Decrease the propagation speed of red path tiles for a timed period
Please ensure that the duration of the timer remaining is made clear to the player. (maybe there is a
counter in the top bar, with the name of the powerup’s effect). You should determine the time interval it
lasts for (maybe around 10 seconds is reasonable). You may also choose to implement a sound effect
when the powerup is collected, and choose to animate it.
The powerup should not spawn immediately when the level loads, but only after some delay interval
(within 10 seconds). And when collected, only after another randomised delay interval, with this process
INFO1113

Page 5 of 8

continuing. You may choose to implement multiple powerups and choose which one to randomly spawn
in. Note that the powerup system must be able to work with all map types.
If a powerup is captured within a region that turns to grass, it is removed (discarded) with no effect.
Win and lose conditions
The current level is completed when the area of soil is covered with grass matching at least the
proportion defined in the goal (round up fractional values). If there is another level, that level is then
loaded with the player starting in the top-left corner again. The player retains the number of lives they
had previously.
If there are no more levels and the player wins, display a screen saying “You win”.
If the player loses all of their lives, display a screen saying “Game over”.

Application
Your application will need to adhere to the following specifications:
• The window must have dimensions 1280x720
• The game must maintain a frame rate of 60 frames per second.
• Your application must be able to compile and run on any the university lab machines (or Ubuntu
VM) using gradle build & gradle run. Failure to do so, will result in 0% for Final Code Submission.
• Your program must not exhibit any memory leak.
• 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 the
powerup and any extensions you want to implement.

Extension
The extension is worth 2 marks. For an extension, you can choose to implement:
• New enemy type with special behaviour
o Spawns and moves in grass areas?
o Travels along the boundary of safe areas and soil?
OR
• More than 1 type of powerup (randomly choose which powerup to spawn, or specified in the
config?)


INFO1113

Page 6 of 8

Marking Criteria (18%)
Your final submission is due on Sunday 1 May at 11:59PM. To submit, you must submit your build.gradle
file and src folder to Ed (ensure src is in the root directory with the other files, and not part of a zip, then
press MARK) and your UML to Canvas. In addition, please include a sample config and level files that you
have tested with your program to ensure it works.
Final Code Submission (10%)
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 brown background.
• Configuration file is correctly read in
• Map loads and cement tiles are displayed in correct positions
• Player and enemies are correctly loaded in
• Player is controlled by input as described above
o Is there movement at all – in correct directions, cannot turn backwards, etc.
o Is the movement smoothly transitioning from one tile to the next
o Movement requires key to be held when on a cement tile
o Movement is continuous even when key is released whilst on soil or grass
• Player begins a path when travelling onto soil
• Enemies move correctly – movement is diagonal and smooth
• Enemies bounce off tiles in the reflected direction
• Enemies cause the player’s path to become red upon collision
• Red path propagates along green path and causes player to lose a life
• Red path propagation speed is 1 tile every 3 frames
• The beetle enemy destroys grass tile upon collision
• Player loses a life with self-intersection of their own path
• Player respawns in top-left corner upon life lost and is stationary
• Paths the player makes capture territory which becomes grass when the player reaches a safe
area
• Both regions either side of the path are checked and if no enemy resides within, that soil area
becomes grass also.
• Powerups spawn in a random area of soil, some time after the level loads (within 10s)
• There is only ever one powerup present on the board, and it respawns a while after collected
(again, within 10 seconds)
• The powerup has one of the desired effects
• All useful info is displayed correctly in the topbar of GUI (number of lives, progress towards goal,
current level number, timer remaining on powerup)
• The next level is loaded if the proportion of territory captured reaches the goal
• The win screen is shown if Player reaches the goal in the final level
• The game over screen is shown if the player loses all lives
• Ensure that your application does not repeat large sections of logic
• Ensure that your application is bug-free

INFO1113

Page 7 of 8

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 at least three levels in a class hierarchy (similar to how in Question 2 of the Week 5 tutorial,
Teacher extends Employee which extends Person). 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 and comments: 1%
Extension (2%)
Implement an extension as described above. Partial marks may be awarded if you choose a more limited
extension, such as an additional powerup that results in the goal proportion decreasing by some amount
(for example, the goal may be 80%, collecting the powerup reduces it to 75%, and collecting another one
reduces it to 70%).
Or another basic extension might be to add a sound effect to events such as collecting a power up, losing
a life, etc. Please specify what extension you decided to implement within your report.



INFO1113

Page 8 of 8

Suggested Timeline
Here is a suggested timeline for developing the project. Note that it is released on April 4 (start of week 7)
and due May 1 (beginning of week 10).
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.
Begin writing the actual code for the program. Start small, for example by initially creating the map and
the player, and gradually add more elements. At the end of the week, you should have loading in the map
and player 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.
Week 8: Develop more gameplay features, such as enemies, paths, and capturing territory. 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.
Week 9: Finish developing the remaining features for your program, notably the configuration file, level
system, lives management and powerups. 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.

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.