3 Game description
The game is called Simon’s Obstacle Course, it is a made up game, so there is no point Googling for
implementations of it. Simon’s Obstacle Course is a board-based game which has a start line and a finish
line, and a course of obstacles between the two. The goal is easy: the player to get from the start to the
end first is the winner. However, there are a few rules that make this a little more complicated! The
rules which determine if a move is valid are:
1. A 9-sided dice is rolled to determine how many squares a player can move: 1, 2, ..., 9 squares.
1
2. Players always move forwards, but might have to interact with obstacles on the way. You should
have controls to allow players to decide if they want to move, or stop.
3. If a player cannot make a valid move, they stop at the last valid square they can.
4. Obstructions include: other players, the edges / walls of the board, and obstacles in the game (fires,
fences, pits, teleporting portals etc.).
To provide some context, consider the setup displayed in Figure 1. Here, 2 or more players, race to
the finish. The board is arranged as a spiral, the start line is on the outside, the first player to get to the
centre square wins. The brown lines indicate the walls that define the path from start to finish. While
in Figure 1 there is only one path, you could consider extending the game to facilitate multiple paths.
There are, in this example, four types of obstruction:
• a bottomless pit (black background): causing the player to return to the start if they fall in (land
on it)
• a fire pit (blue background): causing the player to miss a turn after they pass it
• a spike pit: must be jumped over, i.e. if it consumes 3 tiles, at least 4 is needed on the dice to pass
the obstacle by the time the player reaches it
• a teleporter (white background): moves either the current player, or a player of their choice to a
random location as soon as the player enters the tile (regardless of how much further they could
move).
Note this board set up is only indicative, your board:
• could have more obstacles,
• could have perhaps more obstacle types,
• will likely be larger (have more squares), and
• perhaps have more than one route to the centre
Figure 1: Example Simon’s Obstacle Course Board.
Note the following:
1. you need 2 or more players, but 2 players cannot be on the same square
2
2. players must be able to make decisions when needed (you can decide how they do this)
3. you can have as large a board (i.e. the distance between start and end) as you like
4. the board should fit on the screen in at least one direction, i.e. either the full width or full height
of the board should be visible, the other direction can scroll if needed.
5. you can have as many obstacles as you like, however, as discussed in section 4 there are some
minimum requirements
There is a lot of free design space for you, your game can look very different to the mockup shown in
Figure 1: it is only a quick illustration. There is no legitimate reason for two projects to look the same,
and as such two projects that are “too similar” may be scrutinised more closely for issues of plagiarism.
4 Requirements
In this assignment you are making a multi-player game according the game brief presented in section 3,
however, the following MINIMUM requirements should be observed:
1. All conditions noted in section 3 must be observed
2. The game MUST have a 2D JavaFX user interface (which can be quite simple: fancy animations
are NOT NEEDED!)
3. When a player wins Simon’s Obstacle Course the game should end immediately and “announce”
the winner
4. The players should be able to specify their name, this should be displayed in the interface
5. The interface should illustrate current value of the game dice
6. The game must be well unit tested
7. this IS NOT a maze game, and should not be constructed as a maze, the spiral shape should
ALWAYS be retained and clearly visible.
8. You need to derive a scoring mechanism for the game, and have a persistent top 10 score board
(e.g. in a flat file, serialised object, etc.);
9. all code should be placed within a well-structured Java package with accompanying JavaDoc that
provides detailed information for all classes, methods, fields etc. Simply making a JavaDoc with
no informative content will receive a score of zero.
10. you must have at least 3 different types of obstacle, one of these should have “special rules” i.e.
modify the game play in some manner, e.g. a button that when pressed (stepped on) rearranges
the board, a fire pit that makes the player miss their next turn, a teleportation portal that swaps
the position of both players, etc.
All these requirements must be fulfilled to achieve a B grade or higher. To increase your mark, you
can add adaptions to the game that increase its complexity and allow you to go beyond the minimum requirements (above). However, this should only be undertaken once all minimum requirements
are met. Example adaptions:
1. user-specified board sizes and layout (e.g. of obstacles)
2. a difficulty setting (more or less obstacles)
3. randomly generated boards (with clear rules and parameters for the construction of the board)
4. player defined board layouts
5. < add your own ideas here >
3
5 Deliverables
Demo Video a (max of) 7.5 min video (with audio commentary) demonstrating your game, and key unit tests,
you should also illustrate how the unit tests thoroughly test game in the video. You should use
OBS to record your demo (see OBS tutorial on brightspace). Both team members much have a
meaningful role in the demo.
Screenshot of your application showing an on-going game in anything but the start or end state
Documentation a Java Doc for all classes as a .zip
Code all .java files as a .zip archive
README.txt a file explaining how to run the game, and tests for each class
Challenge a (max of) 3 min video (with audio commentary) where you will perform a set a unique (to you)
tasks. These will be provided after submission. You need to record yourself making changes to
the code and running the result. These may include, but are not limited to: 1) change some part
of the UI, reload the game to show these change, 2) initialise the board with a specified state, 3)
modify the code in various ways to create specified situations then demo these situations, etc. You
will have 24 hours to answer these questions. None of these questions will be difficult if you have a
good understanding of the code. Team members will receive INDIVIDUALISED challenges.
Contributions a short document that breaks down individual contributions on the project, this should align with
GitHub commits, comments, author tags in the code etc.
Peer Eval a short peer evaluation assessment for your team
6 Tips and Grading Rubric
Problem Definition start the project by defining a problem definition, this is essentially a list of things
your game needs to do. Work on paper to identify potential areas of functionality when considering classes
to implement; your main classes are probably the nouns in your problem description e.g. board, piece,
scoreboard, UI, etc.
Interface start with a command line interface: so that you can get the move logic correct. A functioning
game is more important than a pretty interface!
Start with the “board” or environment data structure and implement code that makes a move / takes
a turn (this, initially, should not include the UI!). Then add code to check a move / turn is valid. A
simple game, well implemented is better than a complex game that doesn’t work. Once you can check
for valid moves, add functionality to check for the win / lose condition. Then build up to multiple turns,
then start planning the GUI, etc. You should be using the model view controller design pattern for this
project, and as such you can build most of the core functionality without a UI!
Testing should be undertaken as you implement key aspects of functionality. Don’t leave it to the last
minute. Key testing in this project should look at valid moves, changes in board / environment state,
identifying the win / lose condition, etc. A poor project has less than 20 or so distinct test cases.
Workload it is expected that this project require 40-80 hours of work to complete per student.
Grading the game itself is “only” worth 50% make sure you allocate sufficient time for the other aspects
of the project: video, testing, JavaDoc, etc.
Model-View-Controller this is the best design pattern to use for project.
Scene Builder makes the design of the UI much easier and enforces an MVC approach to the project.
4
7 Grade individualisation
Even though the COMP20300 project is a group project, students still receive individual grades. Projects
will initially be graded without consideration of individual contributions. This acts only as a starting
point when considering individual grades, which can be higher or lower than the group grade. Grades
are individualised using three sources of information:
1. A peer evaluation: team members evaluate each others’ contribution to the team as well as their
own.
2. Github: checks to see that github contributions are both meaningful and span the entire duration
of the project, i.e. if you have a relatively large number of commits only near the start or end of
the project, this will reflect negatively on you.
3. Distribution of work document submitted with the other deliverables. Here, you outline the contributions to the project of both team members. Both members of the team must submit this
to illustrate their agreement with the contents. If you do not agree, mark changes in red text.
Note, however, that significant disagreements will likely result in an invitation to discuss team
contributions.