Invent and Implement a Text-based Adventure Game

Task

Your task is to invent and implement a text-based adventure game. You have been given a simple framework that lets you walk through a couple of rooms. You can use this as a starting point. You are encouraged to work in small teams of up to four people.

1. Read the Code
Reading code is an important skill that you need to practise. You first task is to read some of the existing code and try to understand what it does. By the end of the assignment, all members of your team will need to understand most of it.

2. Make Small Extensions
Start off slow – take small steps at a time.
Test each change works before moving on. It is much easier to look for a bug when you have changed one thing than when you have changed many things at once.
As a little exercise to get warmed up, make some changes to the code. For example:
• Change the name of a location to something different.
• Change the exits – pick a room that currently is to the west of another room and put it to the north
• Add a room (or two, or three, ...)
These and similar exercises should get you familiar with the game.

 

3. Map your Game
First, you should decide what the goal of your game is. It should be something along the lines of: You have to find some items and take them to a certain room (or a certain person?). Then you can get another item. If you take that to another room, you win.

For example:  You have to find out where your mentoring session is.
To find this, you have to find the Engineering Reception and ask. At the end, you need to find the exam room. If you get there on time, and you have found your textbook somewhere along the way, and you have also been to the mentoring session, then you win. And if you’ve been to JC’s to drink a beer more than five times during the game, your exam mark halves.

Or: You are lost in a dungeon. You meet a dwarf. If you find something to eat that you can give to the dwarf, then the dwarf tells you where to find a magic wand. If you use the magic wand in the big cave, the exit opens, you get out and win.

It can be anything, really. Think about the scenery you want to use (a dungeon, a city, a building, etc) and decide what your locations (rooms) are. Make it interesting, but don’t make it too complicated. (I would suggest no more than 15 rooms.)

1. Read the Code

Put objects in the scenery, maybe people, monsters, etc. Decide what task the player has to master.

 

4. Model the Game
Decide what classes you need to implement the game. Reverse engineer the world-of-zuul as provided as a starting point. Think about what extra classes you may need and how they may interact.
In an ideal world you should have all your classes and their methods mapped out before you start coding. However, this is very difficult to do, particularly when you are learning, so it is acceptable to move between the design and the implementation

 

5. Implement the Game
The game needs to be coded and tested in Visual Studio Code. You will be marked on features implemented, good coding style and use of comments. It is a good idea to divide the work up so that each team member is responsible for modelling and implementing a group of related classes. Ensure that you use comments to add your name to all classes that you have created or modified – a short history (with dates) can be useful to see the changes that have been made over time. Make sure that you know how all the parts that you have implemented work and how they interact with the parts your colleagues have built. Make sure that your game works and that any member of your team can demonstrate it!

 

6. Levels
The base functionality that you have to implement is:
• The game has several locations/rooms.
• The player can walk through the locations. (This was already implemented in the code you have been given.)
• There are items in some rooms. Every room can hold any number of items. Some items can be picked up by the player, others can’t.
• The player can carry some items with him. Every item has a weight. The player can carry items only up to a certain total weight.
• The player can win. There has to be some situation that is recognised as the end of the game where the player is informed that he/she has won.
• Implement a command “back” that takes you back to the last room you’ve been in.
• Add at least four new commands (in addition to those that were present in the code you got from me)

 

6.1. Challenge Tasks
• Add characters to your game. Characters are people or animals or monsters – anything that moves, really. Characters are also in rooms (like the player and the items). Unlike items, characters can move around by themselves.
• Extend the parser to recognise three-word commands. You could, for example, have a command: give bread dwarf to give some bread (which you are carrying) to the dwarf.
• Add a magic transporter room – every time you enter it you are transported to a random room in your game.
• Others. You can invent additional challenge tasks yourself. Feel free to discuss any ideas with me either face to face or via email. I am happy to advise you if you have picked something that is too difficult or too much work.

 

7. Assessment
You have to submit your project to Canvas before the due date. All code must be professionally written (comments and indentation!). Your project will be marked for:
• Correctness
• Appropriate use of language
• Style (commenting, indentation, layout etc.)
• Difficulty (extra marks for difficult extensions)

 

You also have to submit a brief report that includes:
• The name and a short description of your game
• The description should include at least a user level description (what does the game do?) and a brief implementation description:

What are important implementation features? 

What are the classes that make your game?
What does each class do (at a high level – not going through each line of code)?

• Special features of your game
• Known bugs or problems (Note: for a bug in your code that you document yourself, you may not lose many marks – maybe none, if it is in a challenge task. For bugs that I find that you did not document you will lose marks.)

• A set of instructions on how I should play your game to completion. This should include any nice features of your game that you want to highlight to me.
(If there is any random element in your game, e.g. the transporter room, then it is ok to just say navigate back to Room XXX.)