Text Based RPG Game

Your assignment requires that you create a text-driven RPG computer game that conforms to the specification given herein.

Much of the specific guidance needed to complete this programming assignment is contained in a series of tutorial exercises. The basic classes required are:

• characterClass (with derivatives playingCharacterClass and nonPlayingCharacterClass).
• inventoryClass which is composited within characterClass and locationClass (below).
• itemClass which is composited within inventoryClass.
• locationClass which is composited within mapClass.
• exitClass which will be composited within locationClass.

You will be expected to glue the classes together with appropriate relationships, create the game scenarios, and implement any other functions that may be necessary to create a working game.

• inv (show items player is holding).
• quit (leave the application).
• look (show a description of the current location).
• move {directon} (move from one location to another).
• talk to {non-playing character} (speak to a non-playing character present at the player's current location).
• attack {non-playing character} (engage a non-playing character present at the player's current location in combat).
• get {item} (retrieve an item from the current location and add it to the player's inventory)
• drop {item} (remove an item from the player's, or a non-playing character's, inventory and leave it at the current location)
• examine {item | non-playing character} (present a description of an item in the player's inventory, or a non-playing character present at the current location).
• use {item} (action depends upon nature of item)

In some cases, locations (and possibly other class types) may have more than one description string – perhaps corresponding to before and after some manipulation has taken place. In this case, a data member will be held pertaining to specify which description to use (e.g. an integer).

The description of the location, items present, characters present and available exits will be displayed to the user every time they move to a new location, for example: See image.

The map will be implemented by means of a graph data structure to facilitate a complex topologies. Ideally this will be implemented by means of fully dynamic memory allocation. The inventories of the player, non-playing characters, and locations should be implemented by means of a linked list. The non-playing characters present at each location should be implemented by means of a linked list.

In some cases, a manipulation may open a new exit, in which case the ability to change the map is required.

When bootstrapped, the application will populate the game world by loading either a single or a collection of text files of a specific format.

You are to populate the game world with suitable characters, locations, objects and challenges to demonstrate the efficacy of the classes developed. Examples include: negotiating complex mazes, gaining tips from characters, dispatching characters to obtain treasure and experience, finding potions/food etc. to facilitate healing between battles.

The attack engine will be implemented by means of a formula that takes into consideration the playing characater's health points, attack points, weapons/armour they may be holding, and a random element. These will be compared with the opponent to determine the outcome, via a series of exchanged blows. Each 'turn' (i.e., a pairing of attack by player, and attack on player by opponent, completed in random order) will be interceded by the question - attack again or run? (a/r). If the player chooses to run (because they are losing the battle), there is a non-playing-character dependent chance that they will not be able to do so.

If you have a limited exposure to computer game scenarios, you may wish to derive ideas from a short story, novel or novella. Past examples that have been used include 'Alice in Wonderland', 'The Time Machine', 'Chronicles of Narnia', and 'Lord of the Rings'. You will not be penalised for basing the game scenarios on an extant story.

Practical Tips

Note that, since we are using a graph in our mapClass, the map can possess a topology enabling the player to move larger distances than their immediate neighbourhood. Movement directions “up” and “down” could be made available in addition to compass directions (requiring that you plan your map carefully beforehand). Indeed, some aspects of the game may include a simple maze-like puzzle (i.e., finding your way from one side of a maze to another, perhaps in the dark if you don’t have a torch in your inventory). In manipulating items in the game, it is necessary that they exist in only one location – after taking an item from a location, it is removed from the location’s link list of items and added to the players linked list of items (i.e., their inventory). For a player to use an item, it must be in their inventory.

You are to consider how best to use the features of the C++ language to achieve the greatest economy of code (e.g., playingCharacterClass, nonPlayingCharacterClass and characterClass are related by inheritance – are there any other opportunities for inheritance relationships? Are there any opportunities to use polymorphism to good effect?), and to use appropriate means of information hiding and encapsulation. Your class, data member and member function names should reflect their purpose in the application we are writing (i.e., a game), rather than being named after the technical task that they accomplish (e.g., linkedListClass would not be appropriate, but inventoryClass would).

The game will be played using a text interface. Various commands are permissible (as listed above), but stick to the rule of using two words maximum (i.e., action – target).

Apparatus

You will use the C++ programming language. It is suggested that you use the CodeBlocks C/C++ Integrated Development Environment (version 8.02), along with the MINGW GNU/GCC Compiler.

Assignment Presentation

Your written report must be divided into 5 sections: 1. Introduction, 2. Method, 3. Results, 4. Discussion and 5. Conclusions. Text will be set in Times New Roman, Arial or Calibri 12pt, with 2cm margins all sides. All major sections (1..5), and figures should be numbered consecutively and individually titled, as should all tables. Provide a table of contents, as well as lists of figures and tables at the beginning of the submission. You are to provide references/bibliography in Harvard format at the end. See the University library website for guidance on correct referencing style. All code should be provided in the appendices of your report.