CHC5028 Software Development with C/C++ - Coursework: Text adventures
CHC5028 Software Development with C/C++
Coursework
Background
“Text adventures”, now called “interactive fiction”, were among the first type of computer game ever produced. These games have no graphics; the player reads the story of the game in text, and decides what their character will do by typing commands at a prompt. Although less popular now, text adventures are still played and created, and developed into the original online RPGs (MUDs). You can play some sample modern text adventures here:
A Change in the Weather, Spider and Web, Slouching Towards Bedlam, 北大侠客行 These are playable online via a web browser. It is advisable to try out the games to get an understanding of how the games behave.
For this coursework, you will be creating a simple game engine for a text adventure. You are not required to write an actual adventure, only the back-end program code that would support one. You will need to add some material to the program in order to test it, but this may just be simple test material. You may add interesting descriptions or stories to your program if you want to, but there are no marks for doing so.
You are provided with a CLion project containing a very simple game harness which supports only two commands: going north (north or n), and quitting (quit). Extend it by doing the exercises below. Note that the later exercises are less explicitly described than the earlier ones, meaning that you must solve more problems yourself. This is intentional.
The coursework is written to be built using gcc through CMake and CLion. It is not recommended that you attempt to build it using Visual Studio or XCode.
Important: If you are building the sample coursework on a platform other than
Windows, or on a machine which does not have the Windows API installed, you may
get an error in the file wordwrap.c. This file calls a Windows specific function to find the
width of the console. If you get this error, remove the #include
Exercise 1 (20% of the mark)
In the current system you can only move North. Extend the engine to allow movement in all four compass directions.
- Add properties to the Room class for storing east, south, and west exits. These properties will need accessor methods. (5%)
- Add code to the gameLoop method to understand the commands east, south, and west (and the abbreviations e, s and w) and to handle them in a similar way to north. (5%)
- Modify initRooms to create more rooms using the new exits in order to test your code. (5%)
- Find a more elegant way of implementing these exits which does not repeat code. [Hint: Traversing through map structures/strings, etc can be considered.] (5%)
Exercise 2 (40% of the mark)
A key part of most text adventure games is the ability to move objects around. Objects can be found in rooms and can be picked up and put down by the player. Add this capability to the game engine.
- Create an GameObject class. It should contain at least a short name, a long description, and a keyword (for the player to use when typing commands). (5%)
- Modify the Room class so that each Room includes a list of GameObjects in the room. (2%)
- Modify the State class to include a representation of a list of GameObjects the player is carrying, called inventory. (3%)
- Modify the Room::describe() method to also print out the short names of all the objects in the room, formatted as nicely as possible. (5%)
- Modify the gameLoop method to pay attention to the second word of the command the player enters, if there is one. (5%)
- Modify the gameLoop command to search through a) objects in the current room, and b) objects in the inventory, for an object with a keyword matching the second word of the command the player typed. (5%)
- Implement the player command get which, when typed with an object keyword, will move that object from the current room list into the inventory. It should display appropriate errors if the object is not in the room or the object is already in the inventory or the object does not exist. (5%)
- Implement the player command drop which, when typed with an object keyword, will move that object from the inventory into the current room list. It should display appropriate errors if the object is not in the inventory or already in the room, or does not exist, etc. (5%)
- Implement the player command inventory which will print out the short names of all the objects in the inventory. (2%)
- Implement the player command examine which, when typed with an object keyword, will print out the long description of that object. (3%)
- Modify initRooms to create some GameObjects and put them in the rooms. Use this to test your program. (No marks are assigned specifically for this task, but without it the ones above cannot be demonstrated.)
Exercise 3 (40% of the mark)
Since most players will not want to play an entire game at one sitting, most games include save and load (or restore) commands. Implement these commands. They should ask the user for a filename and then write or read the current game state, to or from that file.
Note that the layout and descriptions of rooms, and the list and descriptions of objects, are not part of the game state because they do not change during the game. These should not be included in the save file and saving them will lose marks.
A simple file open, load, and save does not guarantee full marks and may not guarantee “a good mark”.
To this end, some important points to consider:
- The “game state” may also include the locations of objects the player has dropped in rooms. Would it be a good idea to restructure how object locations are stored?
- The State object stores the current room, and objects, using pointers. Pointers cannot safely be written to disk since addresses may be different when the program is reloaded. How can you enable this data to be safely saved and reloaded?
- It is worth ensuring to some degree that the user cannot readily cheat, or spoil the game, by reading or changing a save file. While it is not necessary to implement actual authentication or encryption but at the same time, the file does not have to be just a text dump. This actually makes it harder to parse when loaded. So, for example, saving the required indexes into a static array of strings maybe be a better way than saving the strings themselves.
