Overview
Unlike previous requests where we revealed the required functionality lab-by-lab in “portfolio tasks” as you were taught the required concepts, for this request we are giving you the full specification up front. This is because we have now covered all the language features you need.
Recap (the story so far!):
In request 1 you created a very simple turn based adventure game where the player created a character, choosing a name and a vocation for the character in order to set some default statistics. The main game loop simply applied events from a file that affected the player’s health. The game ended when the player died. You could also save the current state of the character at any time.
In request 2 you used what you had learned about OO and classes to better structure the code. You modelled Events and Vocations with simple classes. You added a Character class, and Player and Enemy subclasses of Character. Possibly you added further subclasses of Enemy. Then you added the notion of turn-based Fights involving a collection of Character subclasses.
For request 3 (the final instalment of the TextQuest trilogy) you will start to add some visual elements to the game. It will still be text-based but we will introduce the notion of a 2D map.
Specification
You can start with your code from request 2 – or if you are unhappy with it (or it is non-existant) you are welcome to start with our sample solution for request 2 (available on Moodle).
If you haven’t already, then introduce a Game class to hold all the data, state and functions not already associated with other classes. Introduce a Room class.
Introduce a Room class. A room contains a collection of 0 or more Events that occur in that room and also a collection of 0 or more Enemies that attack the player. Also, a room will have four nullable pointers to other Rooms (e.g. north, east, south and west).
Create a 10x10 grid (e.g. a 2D array) of Rooms. Then you will need to create “doors” between adjacent rooms. You can do this randomly to create a maze. Remember to connect the rooms in both directions. For example: if the east pointer of the Room at array position 1,5 points to the Room at array position 1,6 then room 1,6 should have a west pointer back to 1,5.
So the player can see where they are, you will need to display the map. You can be as fancy with this as you like, but here’s an example of a basic ASCII representation that you might use (this one is 4x4, yours will be bigger):
Now, the player starts the game in a particular room (could be random) and at the beginning of each turn in the game they can choose an open door (N,S,E or W) to pass through. If there are enemies in the room then there will be a fight (as in request 2). If there are events (e.g. a health potion, a trap, a magic sword) then these can happen after the fight.
The game will be more fun if the player has to explore. Implement a “fog of war” feature. That is, the map starts off obscured (e.g. covered in *) with only the exits to the current room visible, and is gradually revealed as the player moves around.
REQUIREMENT: Please allow the player to choose a “cheat” mode on startup where the full map is shown all the time. This will make your life easier in debugging but will also make it easier for us to mark!
Save and load should be extended to store the full state of the map and rooms
Further Functionality
The above is a bare minimum we will expect to see. Implementing it perfectly will get you CR (~60%). To get D or above, you will need to add some more interesting elements. Here are some suggestions – but feel free to go further:
Add navigation within a room: when you enter a room, pop up a small (e.g. 5x5) map showing the location of enemies and events within the room. The player can move around inside the room to see what the events are and attack enemies in adjacent squares.
Have the enemies move around! From room to room or just within a room. They could move randomly or you could give them some simple AI (e.g. always move towards the player).
We have already suggested events can involve items. Make this a more formal notion (e.g. with an Item class) and give the character an inventory.
We will reward creativity but ultimately you will be marked based on clean, functional, working code that demonstrates a good understanding of the C++ language features and OO design as covered in the course.
This is reflected in the sample marking guide that is provided.
Class Diagram
For this request, you are also required to submit a diagram showing your overall Object-Oriented approach to solving this request. Your diagram does not have to be completed with any formal tools (it can be hand drawn as long as it is legible) but you must submit a PNG/JPG or PDF file that shows what classes you have and how they are related (inheritance for example). NO OTHER FILE FORMAT MAY BE SUBMITTED. This is important for us to look at as we grade your request so we can have a basic understanding of how your program has been designed.