CS-230 Software Engineering, Functional Specification
CS-230 Software Engineering
Functional Specification
Liam O’Reilly
You have been task with creating an awesome retro
computer game. This game should take players
back to the 90’s with its retro gameplay and its
overall look and feel.
This game is very roughly based around similar
games at the time such as Chip’s Challenge.
You can read a bit about Chips’ challenge (op-
tional) at https://en.wikipedia.org/wiki/
Chip%27s_Challenge or watch a YouTube
video at https://www.youtube.com/watch?v=
pcdMh1M7QLI.
The game’s rules are detailed in this document.
They are not too complex (but not too simple ei-
ther). Various design decisions have been taken to
keep the complexity at a reasonable level (e.g., to
avoid multi-threading).
It is up to you to design the classes, algorithms and
GUI involved in the development of this game.
1 Title and Theme
You are free to come up with the title and theme
of the game.
This document describes the type of cells used in
the game. You may substitute them to align them
to your theme. For example, you could create a
game around robots: the doors might be substi-
tuted for laser beams where you disable them using
key-cards (instead of unlocking doors with keys).
As long as you are consistent, and the game makes
enough sense to be easily followed, then let your
imagination roam free(ish).
The graphics used in this document are intention-
ally simple and plain. You can and should pro-
duce nicer graphics. Even simple images files, when
tiled, can look very nice.
2 Overall Idea
The game is composed of multiple levels (i.e., a
collection of maps). A player plays one level at a
time and, upon completion of a level, progresses
onto the next level.
Each level is played on a 2 dimensional map (i.e.,
grid). Each cell of the grid can be of a certain type,
for example, a wall, a door, ground (i.e., empty),
etc. There is also the player who occupies a cell
and various enemies that if touched will kill the
player.
The player can move by using the arrow keys (up,
down, left and right). After the player moves, the
screen will be redrawn with the new game state.
As an example of this, consider the following.
The game might be in the following state:
Here, we see the player in the centre. We see a path
of empty/ground cells forming a maze of walls to
the sides. There is also a (badly drawn) red door.
Only part of the map is shown at any one time – in
this case a 7 by 7 square. You may decide on how
much of the map is shown, however it cannot be
the whole map; maps can be very large after all.
If the right arrow key is pressed, the the screen is
redrawn to become:
Page 1 of 6
CS-230 Software Engineering, Functional Specification
Here, you can see that the whole grid has moved
one cell to the left. The player is still in the centre
of the grid. We now see one more column of cells
on the right-hand side.
The game does not need to have smooth animation.
Thus, a jumpy form of animation is fine – it is a
retro game after all. Of course, if you really want
to you can implement a smooth style – but this will
be much much more difficult.
The overall aim of each level is to reach the end
point of the level. During the journey the player
will need to avoid contact with various deadly ene-
mies and pickup keys and token which unlock doors
which block their adventure.
3 Cell Types
There are a range of cell types. Here we describe
each and their associated behaviour.
3.1 Standard Cells
The following are the standard cells types.
Wall The player and enemies cannot pass through
walls.
Ground/Blank Ground/Blank tiles are just
that. There is nothing there. The player and
enemies may move freely upon these cells.
Goal The aim is to reach this cell. As soon as a
player moves onto this cell, they win the game.
Enemies treat goal cells as if they were wall
cells. There are allowed to be multiple goal
cells.
Water The player can move onto a water cell. The
effect of this is determined by if the player cur-
rently has in their inventory a pair of flippers.
If the player possess flippers then they may
move freely upon water cells as if the water
cells were Ground/Blank cells. If they do not
posses flippers they die. Enemies treat water
cells as if they were wall cells.
Fire This cell works just like the water cell except
that the player needs a pair of fire boots in
place of a pair of flippers to be able to move
freely over the fire cells.
Door Doors come in two types:
Coloured Door These types of door have a
fixed colour (e.g., red, green, blue, yel-
low). In order to open the door the
player must have a key of the same colour
in their inventory. Upon the player at-
tempting to open a door (i.e., attempt-
ing to move onto the cell) two things may
happen:
• If the player has a key of the match-
ing colour then the door tile is re-
placed by a ground/blank tile and
the player moves onto the cell. The
key is consumed (and cannot be used
for further doors). Note: A player
may possess multiple keys of the
same colour.
• If the player does not have a key of
the matching colour then the move
is aborted and the player remains
where they are.
Token Door These types of door require a
certain number of tokens to be held be-
fore the player can open them. They
mostly work like coloured doors but in-
stead of the player possessing the correct
colour key, they require the player to hold
at least the number of tokens specified
by the door. Upon opening the door the
player’s token count remains unchanged.
Enemies treat all doors cells as if they were
wall cells.
Teleporter Teleporter cells work in pairs. Each
Teleporter is always connected to exactly one
other teleporter cell somewhere else on the
map.
Upon moving onto a teleporter cell the player
is transported and appears on the cell located
Page 2 of 6
CS-230 Software Engineering, Functional Specification
adjacent to the corresponding teleporter, but
on the opposite side.
For example: If the game state is
and the player moves right then the game state
changes to
Note: The map designer is responsible for en-
suring that there are blank/empty cells around
a teleporter for the player to exit on to.
3.2 Collectable Item Cells
These cells represent items that may be collected
by the player.
Token This is a simple token the player can col-
lect. Upon collecting a token the players count
of tokens is incremented by one. Tokens have
no identity – players simply have a count of the
number of tokens they currently hold. Some
types of doors require a certain number of to-
kens to be able to pass through.
Flipper The player can collect the flippers which
allows them to walk across water cells as if
they were Ground/Blank cells. Once collected
the player keeps these for the remainder of the
level.
Fire Boots The player can collect the fire boots
which allows them to walk across fire cells as if
they were Ground/Blank cells. Once collected
the player keeps these for the remainder of the
level.
Key The player can collect a key. Each key has
a colour. A player may hold multiple keys of
the same colour at the same time. They are
used to open coloured doors. Once used on a
door, the key is consumed and removed from
the players inventory.
The player may move on to any of the above col-
lectable item cells. Upon doing so the item is col-
lected and added to the players inventory. Once
collected the cells turns into a ground/blank cells.
Enemies treat all collectable items cells as if they
were wall cells.
4 Enemies
No game would be complete without the bad guys.
There are several types of enemy that each behave
in their own unique way. However, they share some
common traits.
Each time the player moves, all enemies move
once. This is an important point. Enemies do
not move based on timers/multi-threading. Thus,
if the player remains still, and no arrow keys are
pressed, then the enemies do not move at all.
For example, consider the following game state:
Here we have the player and one enemy drawn in
red.
If the up arrow key is pressed then the player
moves up and, immediately following this, the en-
emy moves:
If a enemy moves onto the same cell as the player
then the player dies.
The types of enemies are:
Straight Line Enemy This enemy simply moves
in a straight line, hits an obstacle and re-
verses direction. Each straight line enemy ei-
ther moves vertically or horizontally over the
map.
Wall Following Enemy This enemy follows a
wall (including obstacles). This would be like
you following a maze keeping your hand on the
wall to the left/right of you at all times.
Page 3 of 6
CS-230 Software Engineering, Functional Specification
Dumb Targeting Enemy This enemy always
moves directly towards the player in the di-
rection that would make it get closer to the
player. This is a very dumb enemy and easily
gets stuck.
For example: If the game state is:
and the player moves right then the game state
becomes:
If the player moves right again then the enemy
doesn’t move.
Smart Targeting Enemy This enemy always
moves towards the player but does so by find-
ing the shortest path through the maze. If no
path is possible for the enemy to move then
the enemy moves in a random (but valid) di-
rection. Note: This is one of the more difficult
parts to implement.
5 Player Death
When the player dies, the level restarts.
6 Level Files
The levels are stored in files. It is up to you how
you design and structure the level files. However,
they must be simple ASCII based files.
One suggestion is to draw out the map using char-
acters and then place extra data below. For exam-
ple, a starting point for a level structure could be
something along the lines of:
1 10,7
2 ##########
3 # D G#
4 # ########
5 # ###T####
6 # #
7 # ###T##T#
8 ##########
9 2,6,START
10 7,2,DOOR ,TOKEN ,3
11 2,3,ENEMY ,STRAIGHT ,UP
The above specifies,
• The width and height of the map are specified
on Line 1.
• Next comes the basic map information. Here,
we assume coordinate (1, 1) is the top-left (al-
though you might choose to use zero-based co-
ordinates instead). Lines 2 to 8 specify the
basic cells in the level: # for a wall, space for
a blank/ground cell, T for a cell with a col-
lectable token, G for the goal cell, and D for a
door.
• Many cells need extra information, this comes
next in the file.
• Line 9 specifies that the start location is in
coordinate (2, 6).
• Line 10 States that the door at location (7, 2)
is a Token Door and the number of required
tokens is 3.
• Line 11 states that a enemy starts on coordi-
nate (2, 3) and that it is a Straight Line Enemy
that will first travel in the up direction.
After loading the game state might look something
like:
3
G
oa
l
Here, the tokens are represented by yellow circles,
the Goal by the cell with the word “Goal”, and the
Token Door by the grey door with the number 3.
Note: The above idea needs to be expanded, as-
suming you wish to use it, in order to capture all
the game elements.
Page 4 of 6
CS-230 Software Engineering, Functional Specification
7 User Profiles
The game should support user profiles. User pro-
files are used to keep game progress separated for
different users. User profiles can be created and
deleted.
Each user profile:
• has a player name.
• keeps track of the highest level that has been
completed.
When opening the game the user should be pre-
sented with a choice of existing profiles and also be
offered the choice of creating a new user profile.
After selecting the profile, the user should be al-
lowed to replay any lower level they have completed
and also be allowed to play the next level they have
not completed.
8 Leaderboards
When a level is completed the game computes the
time it took to complete the level. The game stores
the top 3 (i.e., quickest) times that each level has
been completed in along with the user profile that
was used.
The user should be able to view these top 3 com-
pletion times for each level.
9 Data Persistence
The user profile data, leaderboard data, and level
completion data (per user profile) is persisted
across runs of the game. That is, if the user quits
the game, then upon reopening of the game, the
data is not lost.
10 Save/Load Game
The user shall have the ability to save a game. This
will save the current game state to a file. The user
can later load the save game and resume where they
were. All enemies, the player, the player’s inven-
tory shall be in the same state as it was previously.
You also need to consider how you will calculate
the completion time of the level (see Section 8).
11 Message of the Day
A special Message of the Day (which might change
much more frequently than once a day) should be
displayed in the app. This message must be dis-
played in full without modifying any of the charac-
ters.
You will need to use a special API (developed for
CS-230) to retrieve the message and display it. You
should retrieve this message each time the game is
launched.
The URL for this service is: http://cswebcat.
swan.ac.uk
Note: This will involve own research on how to
issue HTTP requests, handle HTTP responses, and
read the documentation of the Message of the Day
API (found by visiting the above URL).
12 Level Editor
This section is not part of A1 nor A2, but it
will be part of Assignments for CS-235.
Do not design nor implement this for CS-
230.
A level editor should be included which allows users
to design their own levels via a nice editor. A user
can start a new map, edit existing maps and also
delete custom made maps.
These maps should be playable as custom maps
and separate from the levels.
13 Extra Features
This section is not part of A1, but it will be
part of A2. It will be helpful for you to plan
for extensibility and hence know about this
section.
To achieve top marks in A2, you will need to be cre-
ative. At a minimum, all the functionality of the
Functional Specification should be completed to a
high standard. All features should adhere strictly
to the specification. You need to get all this work-
ing well in order to get a low first class mark (in
A2). In order to get higher marks, you would be
required extend the implementation in novel ways.
All extensions that do not violate the specification
will be considered. Substantial extensions to the
Page 5 of 6
CS-230 Software Engineering, Functional Specification
software, extra reading and learning, will be re-
quired to achieve a high first class mark (in A2).
14 Libraries and Frameworks
You must programme this game in Java us-
ing JavaFX. It is strongly recommended to use
JavaFX’s Canvas class to draw the map.
You may use any classes and packages that are part
of the standard Java SDK.
You may not use any other libraries or frameworks
without first seeking approval. Please use the fo-
rums to ask such questions.
Game frameworks will not be allowed.
Page 6 of 6