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
