INFO1113 / COMP9003 Assignment

Due: 12 May 2024, 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, players control tanks which can aim and
fire at each other. Players gain score for hitting another player’s tank, causing them to lose health. After
all levels are completed, the player with the highest score wins.

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 / COMP9003

Gameplay
The game contains a number of entities that will need to be implemented within your application.

Level
Each level is read from a text file of characters 28x20. The size of the window should be 864x640, meaning
each character in the file corresponds to 32x32 pixels.

Figure 1.
Player A (blue) has
their turn first. The
arrow pointing
down to their tank
exists for 2 seconds
to remind them
where they are –
this appears at the
beginning of each
player’s turn.

There are 5 main types of characters that could be present in the file:

• X – denotes the terrain height. This can change during gameplay when hit by projectiles. To
smooth out the terrain, see the section on page 3.
• Letters (A,B,C,D,E, etc.) – starting position of human players. The order of player turns, and the
order in the scoreboard, is alphabetical order.
• Numbers (0,1,2,3,4,5,6,7,8,9) – starting position of AI players (optional for extension, otherwise
they can just be normal human players as well)
• T – location of trees. They are always present on top of the terrain – so if the terrain changes, so
do any trees on top of it. The initial position of trees is randomised up to 30 pixels around its
starting point.
• Spaces – empty space, just ignore it.

The level layouts are defined in files provided in the “layout” attribute of the JSON configuration file
described below. Each level must have an associated layout file.

Note that the file does not need to contain exactly 28x20=560 characters. It may have less than this if
they are not necessary (such as spaces at the end of a line, or missing lines at the bottom). In such
situations, your program should still work, and just assume those are empty spaces.

Page 2 of 11
 INFO1113 / COMP9003

Figure 2.
Example level1.txt file (rendered in figure 1)
provided in the scaffold code. You should make your
own level file to test out different configurations.

How to smooth the level terrain:

The terrain should comprise of a smooth curve that is formed
from computing the moving average of 32 values twice. See
below:

Step 1.
Terrain directly from file
without any smoothing (each
character is 32 pixels wide)

Step 2.
Moving average of 32 values,
once.

Step 3.
Moving average of 32 values,
again.

Page 3 of 11
 INFO1113 / COMP9003

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 files will also be located in

the root directory of the project. However,
sprites or images such as the background,
and trees will be located in the resources
folder (src/main/resources/Tanks/) or
(build/resources/main/Tanks/).

In addition to providing the filenames of

these files, the configuration file also
provides the colours that should be used for
the foreground of each level, and players.
The format is “R,G,B” containing the red,
green and blue components of the colour (0-
255) respectively. If it is “random”, then
choose the colour randomly.

For each level, the following properties are provided in the config:

• layout: the level file containing the characters determining the initial terrain, player positions,
and trees (see pages 2 and 3 above).
• background: the image which should be displayed in the background, behind the terrain and
everything else.
• foreground-colour: the colour to render the terrain in for this level.
• trees (optional): The sprite image to use for trees in this level. If not specified, your program
should not crash (either assume the level contains no trees so don’t render any, or use a default
sprite such as tree1.png).

Page 4 of 11
 INFO1113 / COMP9003

Tanks
Initial positions of tanks are provided in each level’s layout file. Each player can control the tank’s turret
movement, move it across the terrain, or increase and decrease the power level (the key must be held for
these actions). Once they fire a shot (pressing the spacebar), their turn ends. A summary of the player
input actions are in the table below:

Keyboard input Action Rate of change

UP arrow Tank turret moves left +3 radians per second
DOWN arrow Tank turret moves right -3 radians per second
LEFT arrow Tank moves left across terrain -60 pixels per second
RIGHT arrow Tank moves right across terrain +60 pixels per second
W Turret power increases +36 units per second
S Turret power decreases -36 units per second
SPACEBAR Fire a projectile (ends turn)
Note: the rate of change should be continuous (ie. per frame) and does not have to be exact, but is an
indication to guide you in optimising user experience.

Tanks can only move across the terrain as long as they have fuel ( denoted in the top right corner).
Movement consumes 1 unit of fuel per horizontal pixel moved. Tanks start with 250 initial fuel in each
level.

Tanks have initial health of 100, and power of 50, set at the beginning of each level. This is displayed in
the HUD bar at the top. Power determines the speed (distance trajectory) of projectiles, and can never
exceed the tank’s remaining health. Once the tank’s health reduces to 0, it explodes with an explosion
radius of 15. If a tank goes below the bottom of the map, it explodes with a radius of 30.

How to change the turret’s position using the angle from the vertical:

Figure 7. (left)
Recall the parametric form of a circle
(rsin, rcos). In this case, the turret
length should be 15 pixels (r=15).

Note that the coordinate system in

computer graphics has +x values going
from left to right, and +y values going
top-down, which is different from what
you are familiar with in maths (x axis is
the same, but in maths the y axis +ve
values go from bottom to top).

Parachutes
A parachute is deployed for a tank when it is hovering in midair, due to the terrain
below it having been destroyed by a projectile. Each player has 3 parachutes per game.
If using a parachute, the tank descends at a rate of 60 pixels per second and sustains no
damage. If no parachutes are available, it descends at a rate of 120 pixels per second
and sustains damage of 1hp for each pixel of height (this is added as score to the player
who fired the projectile that caused the terrain to be destroyed).

Page 5 of 11
 INFO1113 / COMP9003

Projectiles
Projectiles spawn from the tank’s location and follow a trajectory that is determined by the tank turret’s
vector. The magnitude of this vector is determined by the tank’s power level at the time the missile is
fired. The power level cannot exceed the tank’s health. The minimum magnitude of the projectile’s initial
velocity is 1 pixel (power level 0), and the maximum is 9 pixels (power level 100). You can assume
acceleration due to gravity is a constant rate of 3.6 pixels per second (applied per frame).

The player’s turn ends after they fire a projectile (press spacebar).

Explosions
When a projectile makes contact with the terrain, it causes an explosion. The default explosion radius is
30 pixels. Any tanks within the radius will sustain up to 60 hp lost depending on how close they are to the
impact site, reducing linearly the further the distance away. For example, with radius=30, a tank which is
distance 15 pixels away (half the radius) from the impact will sustain only 30hp damage. A tank which is
10 pixels away will sustain 40hp damage, and a tank which is 20 pixels away will sustain 20hp damage. A
tank which is 31 pixels away will sustain no damage since it’s outside the radius.

The animation (shown above) comprises of 3 concentric circles that expand continuously over a period of
0.2 seconds. During this time:

• Red circle expands from radius 0 to explosion radius (in this case 30px)
• Orange circle expands from 0 to 50% of the explosion radius (in this case 15px)
• Yellow circle expands from 0 to 20% of the explosion radius (in this case 6px)

The terrain will also be destroyed in a radius of 30 pixels around the impact site. Note that terrain cannot
be floating, so if the impact is on the side of a hill, terrain above falls to fill the crater. Any trees on the
terrain also fall to remain on top of the terrain. Trees are not destroyed by impacts.

Wind
Wind is a force that acts on projectiles in the air, in the horizontal (x) direction. It can blow either left or
right, denoted by the different icons (shown above) and has a magnitude. The force imparted by wind is
an acceleration of approximately w*0.03 pixels per second.

Wind is initially a random value between -35 and 35 (where negative values represent wind blowing to
the left, and positives values are blowing to the right). After each turn, it changes by a random value from
between -5 to 5 (inclusive of both).

Wind is displayed in the top right corner of the screen.

Page 6 of 11
 INFO1113 / COMP9003

Powerups
During their turn, players can purchase powerups by using their score as currency. Powerups can only be
purchased when the player can afford it, otherwise the action does nothing.

INFO1113 students must implement the following powerups:

• Repair kit (key: r, cost: 20) – repairs the player’s tank by increasing health by 20 (maximum health
is 100).
• Additional fuel (key: f, cost: 10) – increase the player’s remaining fuel by 200.

COMP9003 students must implement the following powerups:

• Additional parachute (key: p, cost: 15) – increase the player’s remaining parachutes by 1.
• Larger projectile (key: x, cost: 20) – the next shot fired by this player will have double the radius
(60 instead of 30). Projectile damage is not increased, but will affect tanks within the radius
according to the previous rules (proximity distance). A visual indication needs to be shown in the
GUI / HUD that the next projectile to be fired will be a larger one.

Scoreboard
The scoreboard is persistent across levels. When a projectile fired by a player
damages another player’s tank, the player who fired that projectile gains
score equal to the hp damage caused. A player does not gain score when a
projectile they fire damages their own tank.

The scoreboard is ordered by player character (alphabetical order) and

displayed in the top right corner. The text colour for each player is the same
as their tank colour.

Level End and Game End

A level ends when there is only one tank remaining in play. The next level is loaded after 1 second, or
whenever this tank fires a shot. The sequence of levels is the order they are provided in the configuration
file.

When the last level ends, the game ends – display the player with the highest score as the winner (eg.
“Player A wins!”) and then in the centre of the screen, display the final scores in a box filled with a colour
corresponding to the player’s colour, and slightly lighter and transparent. The scores (and the
corresponding players who achieved them) should be displayed in descending order (highest to lowest
score), with a delay of 0.7s between when each one appears.

The user may press ‘r’ to restart the game.

Application
Your application will need to adhere to the following specifications:

• The window must have dimensions 864x640

• The game must maintain a frame rate of 30 frames per second.

Page 7 of 11
 INFO1113 / COMP9003

• 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 for graphics 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
images 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:

• Additional powerups (eg, if you are doing INFO1113, you can implement the COMP9003
powerups as an extension, and vice versa). Or powerups of your own choosing, such as:
o Shield (key: h, cost: 20) – protect your tank from taking damage the next time it’s hit.
After it is gets hit, the shield is destroyed (absorbed to sustain the blast). This must be
indicated in the GUI (like with a blue transparent bubble around the tank).
o Teleport (key: t, cost: 15) – select a location on the map to immediately move your tank
there.
• Computer-controlled players. A targeting AI which can compute the trajectory of a projectile and
adjust its aim to focus on hitting a player.
• Unlimited levels with randomly generated level terrain and player positions / trees, and
randomised background
• Sound effects

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 (if the
extension required changes to the level or config files), 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 12 May 2024 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.

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.

Page 8 of 11
 INFO1113 / COMP9003

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.

• Terrain display is correct – smooth curve, and matches level layout file
• Player starting positions and tree positions are correct, and correct tree type is rendered
• Configuration file is correctly read in – initial values for game state are used from config (player
colours, level backgrounds and foregrounds)
• Multiple players take turns at controlling their own tank – turns are processed in alphabetical
order according to config file
• Tank turret can be controlled with up/down arrow keys and angle changes (3 rad/s)
• Tank can move across terrain with left/right arrow keys (speed is 60px/s)
• Tank turret power can increase/decrease with ‘w’ and ‘s’ keys
• Tank fires a projectile according to the turret’s trajectory when the user pressed spacebar
• Projectile moves through the air and is affected by gravity and wind
• When a projectile collides with terrain, it explodes with a radius of 30 pixels
• Explosion is animated correctly
• Explosion causes damage to nearby tanks in a linearly decreasing proportion based on distance
• Tanks deploy parachute if available to fall slowly if the terrain underneath is destroyed, otherwise
they fall faster (2x speed) and incur damage.
• Can use powerups
o For INFO1113: Repair kit, and extra fuel
o For COMP9003: Additional parachute, and larger projectile
• When tank reaches 0 health it is destroyed with an explosion, and that player’s turn is skipped for
the current level.
• GUI elements:
o Health bar which displays changes to tank’s health
o Fuel indicator shows how much fuel is remaining
o Parachutes indicator shows parachutes remaining
o Power as a proportion of remaining health bar
o Wind indicator that changes icon depending on direction of wind
o Text for current player’s turn, and arrow that appears at the beginning of the player’s
turn and lasts for 2 seconds, pointing to their tank
• Scoreboard tracks scores correctly
• Scoreboard is rendered with correct player colours
• The current level ends, and the next level is loaded when only 1 tank remains in play (after 1
second, or as soon as the player fires a shot).
• When all levels are complete, the player with the highest score is declared to be the winner and
the final scores are displayed larger in the centre of the screen in a box whose background colour
matches that of the winning player and is slightly transparent
• Final scores are displayed in descending order with a delay of 0.7s between each subsequent
player
• Once the game has ended, a 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

Page 9 of 11
 INFO1113 / COMP9003

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) – average of
branches and instructions. 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, and show it during your demo in week 12.

Suggested Timeline
Here is a suggested timeline for developing the project. Note that it is released on April 8 (start of week 7)
and due May 12 (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.

Page 10 of 11
 INFO1113 / COMP9003

Week 8: Begin writing the actual code for the program. Start small, for example by initially creating the
map layouts and terrain, then gradually add more like player tanks. At the end of the week, you should
have loading in the map and tank 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 projectile movement, wind, collisions with
terrain and tanks, powerups and scoreboard. 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, timers and level progression. 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.

Page 11 of 11