University of Westminster

Department of Computer Science

5CCGD012W Game Programming Patterns – Coursework (2023/24)

Module leader Klaus Draeger

Unit Coursework

Weighting: 50%

Qualifying mark 30%

Description Object Oriented Programming and Design.

This assignment contributes towards the following Learning Outcomes (LOs):

Learning Outcomes
- LO1 Identify and justify good practices in the development of object
Covered in this
Assignment: oriented software;
- LO2 Apply acquired knowledge of concepts, characteristics, tools and
environments to adapt to new computational environments and
programming languages which are based on object oriented principles;
- LO3 Design, implement efficiently applications based on a OOP language,
given a set of functional requirements.

Handed Out: October 2023

Due Date 9th January 2024, 1pm

Expected deliverables A zip file containing the developed project

Electronic submission on Blackboard via a provided link close to the submission

Method of Submission: time.

Type of Feedback and Due Written feedback within 15 working days.

Date:
2.1.1 Knowledge and understanding of facts, concepts, principles
BCS CRITERIA MEETING IN & theories
THIS ASSIGNMENT 2.1.2 Use of such knowledge in modelling and design
2.1.3 Problem solving strategies
2.2.1 Specify, design or construct computer-based systems
2.2.4 Deploy tools effectively
2.3.2 Development of general transferable skills
3.1.1 Deploy systems to meet business goals
4.1.1 Knowledge and understanding of scientific and engineering
principles
4.1.3 Knowledge and understanding of computational modelling
Assessment regulations

Refer to section 4 of the “How you study” guide for undergraduate students for a clarification of how you are
assessed, penalties and late submissions, what constitutes plagiarism etc.

Penalty for Late Submission

If you submit your coursework late but within 24 hours or one working day of the specified deadline, 10 marks
will be deducted from the final mark, as a penalty for late submission, except for work which obtains a mark in
the range 40 – 49%, in which case the mark will be capped at the pass mark (40%). If you submit your coursework
more than 24 hours or more than one working day after the specified deadline you will be given a mark of zero
for the work in question unless a claim of Mitigating Circumstances has been submitted and accepted as valid.

It is recognised that on occasion, illness or a personal crisis can mean that you fail to submit a piece of work on
time. In such cases you must inform the Campus Office in writing on a mitigating circumstances form, giving the
reason for your late or non-submission. You must provide relevant documentary evidence with the form. This
information will be reported to the relevant Assessment Board that will decide whether the mark of zero shall
stand. For more detailed information regarding University Assessment Regulations, please refer to the following
website: http://www.westminster.ac.uk/study/current-students/resources/academic-regulations
Objective:
Your mission in this assignment is to write a simple 1980s style text adventure game. In
games of this sort, the player wanders around from one location to another, picking up
objects, and solving simple puzzles. You can find many examples of text adventure games
in http://textadventures.co.uk

Overview of the game:

The adventure game you will implement for this assignment takes place in a virtual world
in which the player moves around between locations. Each location has a textual
description that gives you a sense of the geography.

The game contains items which can be either in the player’s inventory, in one of the
locations, or inside another item (a container). Containers can be opened to get their
contents. This may require you to have some other items first (keys, a screwdriver, ...)

You interact with the game by giving commands, some of which are simply directions in
which to move. For example, you might move writing command as follows (where the ‘>’
is the prompt the game uses to ask for input):
> NORTH
> SOUTH
> EAST
> WEST
and possibly other directions such as UP, DOWN, IN, OUT. Some movements may require
items (a key, a ladder, ...)

The program itself doesn’t know the details of the game’s geography or items. It reads
this information from a separate data file. If you run the program with different data files,
the same program will guide its players through different adventure games. Details about
data files can be found below.

Class Structure

You should implement the following principal classes (you might need more!):

1. Player
2. Item, with Container as a subclass
3. Location

The specifications for each class are in the following sections.

Player class (worth 10 marks)

The Player class should have at least the following attributes:

1. location to keep track where the player is

2. inventory to keep track of the items the player currently has
3. steps to keep track of how many actions the player has performed
It should have at least the following methods:

1. bool hasItem(Item *i) to check if an item is in the inventory

2. bool takeItem(Item *i) to add an item to the inventory; returns true/false to
indicate success/failure (because the item may not be here)
3. bool dropItem(Item *i) to drop an item at the current location; returns
true/false to indicate success/failure (because you may not have the item)
4. bool openItem(Item *i) to open an item; returns true/false to indicate
success/failure (e.g. because the item is not a container, its open method fails
(see below))
5. void printStatus() to display the current location, inventory, and number of
steps

Note that there is only one player, so it is a good idea to make its members static.

Item Class (worth 5 marks)

The Item class should have at least the following attributes:

1. name (e.g. “Red Key”) for printing the inventory, “take” commands etc
2. description (e.g. “A small key. Someone has painted it red for some reason.”)

It should also have getter methods for each attribute.

Container Subclass (worth 10 marks)

Containers are a special kind of item. This subclass should have at least the following
additional attributes:

1. contents: what items are contained inside

2. key_item: what other item is needed to open it
3. opened: whether the container has been opened

It should also have a method bool open() which

- returns false if you don’t have the necessary key item, or it is already open
- adds the contents to your inventory and returns true if you do

Location Class (worth 10 marks)

The Location class represents different rooms or places in the game. It should have at
least the following attributes:

1. number (an integer) which the program uses to refer to the location internally
2. name (e.g. “Small Alcove”) used to tell the player where they are
3. description (e.g. “A small alcove. The ground is covered with sawdust.”)
4. contents: What items are currently here
5. key_items: maps each possible direction to an item needed to go that way (if
any)
6. connections: maps each possible direction to the location it leads to
It should have at least the following methods:

1. void print() which displays the location’s description and the current list of
items
2. bool take_item(Item *i) to remove an item from the location; returns true/false
for success/failure (because the item may not be here)
3. void drop_item(Item *i) to add an item to the location
4. Item* getKey(string &direction) to get the key item required to go in some
direction; returns nullptr if no item required
5. Location* getConnection(string &direction) to get the location the direction
leads to; returns null if you cannot got in that direction from this location

Executing commands
The user interacts with the game by entering commands on the console. The process of
reading a command consists of the following steps:

1. Read in a line from the user.

2. Split the line into a verb representing the action, and a target item (if specified)
3. Decide what kind of operation the verb represents. If the word is one of the
known commands (see below), it should be executed using the appropriate
methods. If it is one of the known directions, try to move that way. Otherwise tell
the user that you don’t understand the input.
4. Increase the steps counter if they moved successfully.

The commands that the game must understand are:

1. LOOK: to get the current location’s description and list of items

2. TAKE: to pick up an item
3. DROP: to drop an item
4. OPEN: to open an item
5. QUIT: to quit the game

Each of these is worth 5 marks; the main game loop itself is worth 15 marks.

The data file

The information for the individual locations and items is not part of the program but is
instead stored in a data file. One of your responsibilities is to write a function called
readData, which reads this file and creates new objects based on its contents. This
functionality is worth 15 marks.

Your data file should describe the locations and items that make up your game. There
should be at least 5 different locations and 5 different items, at least one of which
should be a container. The file should contain entries which list the various attributes
organised by keywords like “Location:” or “Contents:”, and look like these examples:
 Item: Strongbox
Description: A sturdy box. It has seen better times.
Contents: Red Key, Letter
Keys: Screwdriver

Location: 1
Name: Outside building
Description: You are standing in front of a small building.
Contents: Screwdriver, Strongbox
WEST 3
NORTH 2, Red Key
IN 2, Red Key

Location: 2
Name: Inside building
Description: You are inside a building, a well house for a large
spring.
Contents: Rubber Duck
SOUTH 1
OUT 1

These entries mean that:

- The Strongbox item is a container (because it has “Contents:” and “Keys:” lines). It
contains the red key and a letter (which are other items whose descriptions would be
elsewhere in the file but are not included in this excerpt).
- Location 1 is “Outside building”, and initially contains the strongbox and screwdriver.
From here you can type “west” to get to location 3 (which is not in this excerpt) or
either “north” or “in” to get to location 2 (but this requires the red key).
- Location 2 is “Inside building”, and initially contains the rubber duck. from here you
can go either south or out to get back to location 1.

The first location listed in the data file is the player’s starting location, and the last one is
their goal; when the player reaches this room, they have won the game. You may want to
make the game more difficult by, for example, enforcing a time limit (if the player has not
reached the goal after some number of steps, they lose).

You can assume that

- the file first contains all item descriptions and then all location descriptions (so that
when you parse a location description, all the items have already been parsed and are
known),
- neither the contents nor the keys of a container include another container (i.e., when
parsing the “Contents:” and “Keys:” lines it is safe to assume that these are all objects
of the base Item class),
- All room numbers and item names are unique,
- Each item or room description is followed by an empty line.
Marking criteria
Upload in BB your zipped source code and data file. The assignment will be graded based on
the following criteria:

• Implementation of the classes and methods defined in the coursework specification.

• Separation of data from the representation. Implementations of functions for reading
and parsing locations and items from input files.
• Your game should contain at least 5 locations and 5 items, at least one of which
should be a container.
• Your game should include at least the verbs mentioned in the coursework
specification (LOOK, TAKE, DROP, OPEN, QUIT).
• Robustness of the code (error management)
• Readability of the code and presence of comments.

Coursework marking scheme:

Criterion and range Indicative Comments

mark
Player class 8-10 Class has all the required members, and is well
written and commented

4-7 Class is lacking some members OR is not well

written and commented

0-3 Not done, or class is lacking members AND is not

well written and commented

Item class 4-5 Class has all the required members, and is well
written and commented

2-3 Class is lacking some members OR is not well

written and commented

0-1 Not done, or class is lacking members AND is not

well written and commented

Container subclass 8-10 Class has all the required members, and is well
written and commented

4-7 Class is lacking some members OR is not well

written and commented

0-3 Not done, or class is lacking members AND is not

well written and commented

Location class 8-10 Class has all the required members, and is well
written and commented

4-7 Class is lacking some members OR is not well

written and commented
 0-3 Not done, or class is lacking members AND is not
well written and commented

LOOK command 4-5 Works as specified

1-3 Implemented, but has bugs

0 Not done

TAKE command 4-5 Works as specified

1-3 Implemented, but has bugs

0 Not done

DROP command 4-5 Works as specified

1-3 Implemented, but has bugs

0 Not done

OPEN command 4-5 Works as specified

1-3 Implemented, but has bugs

0 Not done

QUIT command 4-5 Works as specified

1-3 Implemented, but has bugs

0 Not done

Input file parser 11-15 Able to read any data file in the format given in the
coursework spec

1-10 Limited (can only read some input files) or buggy

0 Not done, or does not work at all

Main game loop 11-15 Sets up the data, and executes the
output/input/execute loop.

1-10 Implemented, but has bugs or is missing features

0 Not done, or does not work at all

Input file 8-10 Has all required features, using the specified format

1-7 Is missing features, or deviates substantially from the

specified format

0 Not done