App Guidelines

Your task is to create a single-player game where the player defends against an army of killer robots. You will also need to prepare a report that explains your design, and explores related architectural considerations.

1           Game Logic

The game is played on a 2D grid (of size X Y ), which is initially empty except for the centre square1, which is the “fortress” that the player must defend. You may hard-code X and Y , or allow the player to specify them. Small values are recommended.

The following events take place in the game:

• Every n milliseconds, a new robot appears randomly in one of the four corners of the grid (unless all four corners are already occupied by other robots). You may hard-code n, or allow the player to specify it as a difficulty setting at the start. A default value of 2000 is

Each robot has the following characteristics:

• A unique The first robot is number 1, the second number 2, etc. This number should be displayed on the screen underneath the robot icon itself.
• A delay value d, randomly chosen from between 500–2000 See below.

• Each robot attempts to move to a new grid square every d Robots randomly move up, down, left or right, but they cannot move outside the grid, nor move into a grid square already occupied by another robot. If a robot is completely boxed-in, then they don’t move, and wait another d milliseconds instead.

Since the value of d is different for each robot, we expect all robots to be moving at dif- ferent times.

When a robot does move, it doesn’t happen instantaneously. Each robot takes 500 mil- liseconds to perform the move, from start to end, and this must be animated in 50 mil- lisecond intervals or smaller (or, equivalently, at 20 frames per second or larger). For instance, 250 milliseconds after the robot has started moving, it should be shown half- way between one grid square and another.

1It doesn’t have to be the exact centre; obviously if X and Y are even, there’s no single square at the exact centre.

While the robot is in the process of moving, it is considered to occupy both its original and new grid square. No other robot can move into either of those grid squares.

• If any robot moves into the fortress square, the game ends, and the player receives their final
• The player can shoot robots by clicking on any single grid If a robot is occupying that square (whether it is stationary or moving to/from it), that robot disappears from the screen and is removed from the game.

The player cannot actually fire more than once per second. However, the player may queue up firing commands by clicking on several squares in quick succession. Queued-up firing commands will then be executed at one-second intervals, until there are no commands left.

• Each time a robot is created or destroyed, or the player fires and misses, this should be logged in an on-screen text area. (Don’t include other events in this )

The word “randomly” appears several times above. If you prefer, you can instead implement some sort of pre-determined pattern or logic, as long as the full range of values is still in play.

2           Scoring

The player receives an increasing score as follows:

• The score begins at
• For each second that passes (until the game ends), the score increases by 10

• For each robot that the player successfully shoots, the score increases by 10+100 ^t . Here, d is the robot’s delay value (in milliseconds), as above, and t is the player’s time That is, t is the time (in milliseconds) elapsed between the player issuing the fire com- mand (clicking on a square) and the fire command actually being executed.

(The 100 ^t part is a bonus, since it’s naturally more difficult to hit a robot with a queued- up fire command, and more difficult still if the robot moves faster.)

The current score should be shown on the screen at all times.

3           Pre-Existing Code

There are pre-existing demo apps written in Java using Swing and JavaFX. It is recommended that you choose one of them as the starting point for your application, although this is not strictly required. JavaFX is slightly more modern than Swing, but the two demo apps are func- tionally identical.

Each demo app sets up a basic GUI layout, but also includes an …Arena class that displays a grid on the screen, with hard-coded dimensions. It is not finished. The intention is for you to

modify this class according to your needs, but the basic logic regarding where things are drawn on the screen is given to you.

Both demo apps use the Gradle build tool, which isn’t being assessed in this assignment, but is still very useful for making things work (especially for JavaFX). To compile and run the code

from the command line, simply type:

[user@pc]$ ./gradlew run         (On Linux/MacOS)

C:\…> gradlew run                    (On Windows)

Keep the directory structure intact. That is, all the source code should go inside the directory src/main/java (although you may optionally create subdirectories within that to represent Java packages, if you wish). If you change the name of App.java, you must change the reference to it in the build.gradle file too.

The image file(s) for the robots (and a couple for the “fortress”) are in src/main/resources. There are some included images, but you may substitute your own. You could replace robots

with zombies, pirates, etc. if you prefer. You can stick with a single image for all the “baddies”, or select a random image each time.

If you prefer to use an IDE, you can. However, any difficulties that you run into as a result of your IDE are your problem!

4           Threading Requirements

Technically speaking, this application could be made to work without multiple threads.

However, it is a requirement of this assessment that you do use multiple threads, and do so in  a sensible fashion, to prevent race conditions and deadlocks, and to preserve maintainability. You are also required to make use of the following, for their intended purposes:

• A blocking
• A thread
• InterruptedException.

These are likely not the only threading constructs you will need to use, but the rest is up to you to determine.

To help implement the timing requirements, it is recommended that you make use of:

• currentTimeMillis(), which returns a long integer: the number of milliseconds elapsed since 1970. (Call this twice, and take the difference of results, to determine how

many milliseconds have elapsed between the two calls.)

• sleep(), which suspends the current thread for a specified number of millisec- onds.

Alternatively, there are more advanced timing mechanisms available too if you prefer to inves- tigate and use those.

5           Report

Prepare a report (3 pages or more) that addresses the following issues:

• Explain your design in regards to threading. In particular:
  • Which classes are responsible for starting threads, and what are these threads used for?

• How do they communicate?
• How do they share resources (if they do at all) without incurring race conditions or deadlocks?
• How do your threads end?

Your discussion must reflect your own specific design. There are no marks here for sim- ply describing how threads and threading mechanisms work in general.

• What would be the best way (architecturally speaking) to transform this app into a co- operative multi-player game, where each player has their own separate fortress, and they must work together to stop the

Consider some plausible non-functional requirements for such a system, and say what architectural decisions could help satisfy them.

6           Submission

• Zip up your entire project directory as-is (as a .zip or .tar.gz file). Leave nothing
• Prepare a report in Word doc.

• Do not copy other people’s code, use third-party libraries.
• Note 1: A third-party library usually refers to any library that is not part of the standard API of the language/platform being used.
• Use in-code comments to give precise references to all sources.

End of Assignment