Revision 1
COMP 3023 Software Development with C++ - Assignment SP5 2018 Page 1 of 22
School of Information Technology and Mathematical Sciences
COMP 3023 Software Development with C++
Assignment
Dungeon Crawler
Introduction
This document specifies the requirements for the first assignment of the Software Development with C++ course,
SP5 2018. This assignment will develop your skills by allowing you to put into practice what has been taught in
class during the first 5 weeks of the course.
The assignment will require you to design, implement, test, and debug a text-based Roguelike dungeon crawler
game using object-oriented methods and the application of appropriate design patterns. In addition, it will
require you to use version control to keep track of your implementation as you progress through the assignment
and to document your classes appropriately using Doxygen comments. The work in this assignment is to be
performed individually and will be submitted via LearnOnline at the end of week 8: due by 14 September 2018
11:59 PM. Refer to section Submission Details for specific instructions.
If any parts of this specification appear unclear, please ensure you seek clarification.
Learning Outcomes
After completing this assignment, you will have learnt to:
? Design a class hierarchy using UML
? Apply Object-Oriented principles (encapsulation, reuse, etc.) and Design Patterns to the software design
? Implement the software design in C++ using class inheritance and polymorphism features
? Write well-behaved constructors and destructors for C++ classes
? Use C++ pointers (including smart pointers) and dynamic memory allocation and management
? Use stream I/O and manipulators for formatted input and output
? Write code adhering to coding standards, guidelines and good programming practices
Design Patterns
In developing the class design for the Dungeon Crawler game, the following the Design Patterns must be
incorporated:
? Singleton
? Builder
? Decorator
? Strategy
This section provides brief descriptions of each relevant design pattern in turn. For more information refer to the
book from which these summaries are derived:
Gamma, E, Helm, R, Johnson, R and Vlissides, J 1995, Design patterns: elements of reusable object-oriented
Revision 1
COMP 3023 Software Development with C++ - Assignment SP5 2018 Page 2 of 22
software, Addison-Wesley, ISBN: 978-0-201-63361-0.
1 Be aware that the C++ examples from the book are for an
older version of C++. If using them for guidance, they must be updated to C++ 14.
Adequate descriptions of the above patterns along with some code examples can also be found on Wikipedia:
? Singleton: https://en.wikipedia.org/wiki/Singleton_pattern
? Builder: https://en.wikipedia.org/wiki/Builder_pattern
? Decorator: https://en.wikipedia.org/wiki/Decorator_pattern
? Strategy: https://en.wikipedia.org/wiki/Strategy_pattern
Singleton
The Singleton pattern addresses the problem of ensuring that a class has only one instance. Moreover, the one
instance is easily accessible but in a controlled fashion. Such a pattern arises in situations where a single, globally
accessible interface to a system or subsystem is required and, hence, is often used with other patterns such as
Fa?ade and Abstract Factory. An example of singleton a singleton is an application wide configuration. Rather
than parsing the configuration file multiple times and storing multiple copies in memory, the configuration file
should be read once and stored once. Moreover, since various parts of the application may need to access
different settings, the configuration should be globally accessible to ensure the configuration is accessible when
needed. Other examples include: a single print spooler governing access to the printer resources, a single
thread/connection pool handing out connections or threads to clients that request them, etc.
When to Use
The Singleton pattern should be applied to a class when:
1. Exactly one instance of the class must exist
2. A well-known access point to the instance is required
In general, the extensibility of a Singleton through subclassing should also be considered. It will not be required
for this assignment; however, it is important to note as a common criticism of the Singleton pattern is that it
becomes tied to implementation and makes testing difficult due to the inability to replace the singleton instance
with a mock (i.e., a test specific class that is not a complete implementation).
General Structure
A simple representation of the Singleton pattern includes only a Singleton class, i.e., the class that should be a
Singleton, containing: a static member function instance() that returns the unique instance of the class, a
hidden constructor, and a static data member to hold the unique instance of the class.
Note the ‘+’ indicates public accessibility and ‘-‘ indicates private accessibility. If considering extensibility of the
Singleton through subclassing, the constructor should be protected rather than private.
1
Scanned PDFs of the relevant sections are available from the course website as the library has limited copies of the book.
Singleton
+ static instance()
- Singleton()
- static theInstance
return theInstance;
Revision 1
COMP 3023 Software Development with C++ - Assignment SP5 2018 Page 3 of 22
Implementation Hints
In C++, the compiler may generate some constructors and operators for you. Ensure you prevent the Singleton
from accidentally being copied or assigned in ways you do not intend by deleting any automatically generated
members that you do not need.
In C++, the static data member can be implemented in two different ways: within the scope of the class or within
the scope of the function. Consider the consequences of each approach and justify your implementation choice in
your comments.
Builder
The purpose of the Builder pattern is to separate the representation of a complex object from the process used to
construct it. Further, such separation allows different representations to be constructed from the same process.
For example, a Parser using a Builder to construct a parse tree in different systems: the recognition of the syntax
is handled by the parser, which calls the builder to create the appropriate parse nodes and retrieves the final
parse tree from the Builder once the parsing is complete. The different representations may or may not be
related, for example, an executable parse tree of the parsed syntax, a parse tree for another language (such as in
code transformation), or a composition of widgets for visualising the text processed by the Parser.
An important aspect of the Builder pattern that differentiates it from other creational patterns is that it supports
the creation of complex objects in a step-by-step process, rather than all-at-once.
When to Use
The Builder pattern should be applied when:
? the construction process is, or should be, independent of the object, its parts, and the way that it is
assembled
? the construction process should allow for different representations to be created.
Note that there does not always have to be multiple representations, only that multiple representations are
possible. One of the motivations for good design is to support future change more easily.
General Structure
The Builder pattern contains several interacting classes, including:
? the Director, which represents the entity that requires the object to be constructed and ‘directs’ the
Builder to construct it;
? the Builder, which specifies an abstract interface for constructing any Product object, this may include
many different member functions for constructing different types of parts;
? one or more ConcreteBuilders, which create specific Products from its parts by implementing the
abstract Builder interface and allows the Product to be retrieved once complete as it maintains the
representation internally during construction;
Revision 1
COMP 3023 Software Development with C++ - Assignment SP5 2018 Page 4 of 22
? the Product class, which represents the complex object being created by a ConcreteBuilder as well as
its parts. Note: this does not mean the classes for the parts are encapsulated by the Product class, only
that the diagram is simplified to not explicitly illustrate any of the Product’s parts.
Implementation Hints
If the representations being constructed by the different ConcreteBuilders are related, the abstract Builder
may declare an appropriate getResult() member function as part of its interface.
The ConcreteBuilder object is not required to be supplied to the Director via a constructor, it could also be a
parameter to a member function.
Decorator
The Decorator pattern is used to dynamically associate additional functionality or responsibilities to an object,
rather than a class. The common exemplar is the addition of a border to GUI widgets: the widgets themselves
may or may not have a border, scroll bar, etc., but can be wrapped in an object that understands how to draw a
border around the widget, i.e., a decorator. This pattern is an example of favouring composition over inheritance,
which results in greater flexibility. Consider using inheritance to add a border to a widget, displaying the widget
would require a check for whether a border should be drawn then display the border followed by displaying the
widget itself. Now consider that widgets can have a scroll-bar and a border, displaying the widget would have to
check and display the border then check and display the scroll-bar. Most, if not all, widget classes would inherit
this capability even though many instances of those widgets would not require it. By separating out these
responsibilities into distinct classes that can be composed, the widget can worry about displaying itself, while the
border decorator can focus on drawing a border and the scroll-bar decorator can focus on the scroll-bar. This has
no impact on the calling code as the decorators conform to the same interface as widgets but delegate most
function calls straight to their component, which may be another decorator. Apart from reuse, this pattern
supports extensibility as new decorators can be added without affecting those already implemented.
When to Use
The decorator pattern should be used when:
? responsibilities or functionality should be added to specific objects dynamically,
? such responsibilities can be removed dynamically, and
? the use of inheritance is impractical, e.g., supporting all combinations of responsibilities would become
cumbersome.
Note: The decorator pattern is best applied when the shared base class is (or can be made) lightweight, with few
data members, otherwise the overhead for having many objects may become a problem. This is in contrast to the
strategy pattern (see next section), which can otherwise be used in similar situations.
Revision 1
COMP 3023 Software Development with C++ - Assignment SP5 2018 Page 5 of 22
General Structure
The Decorator pattern includes several classes with responsibilities as follows:
? an abstract Component that defines the common interface for objects that support dynamically added
responsibilities;
? the ConcreteComponent, which represents the specific types of object that can have responsibilities
attached;
? the abstract Decorator that maintains compatibility to the Component interface by referring to a
Component object and delegating the function calls to the underlying object;
? the ConcereteDecorator classes, which add responsibilities to the Component object and may provide
additional behaviour and/or state.
Implementation Hints
When implementing the decorator pattern, more than one operation of the component type can have their
output modified by a decorator. For example, a border decorator might decorate the draw operation (to display
the border) as well as the size operation (to add the border thickness to the reported size of the widget).
Strategy
To encapsulate a group of similar algorithms and allow them to be used interchangeably, the Strategy pattern
should be used. Such an approach simplifies client code by separating the different algorithm variants into their
own classes, rather than implementing them all in the one place, and allows an appropriate algorithm to be
chosen dynamically based on the context. It can also allow behaviour to reused between objects of different
types. A simple example of Strategy would be the formatting of dates as a string based on locale: the different
formatting algorithms are implemented independently, and the locale object is configured with the desired
algorithm. The strategy pattern can also be seen in libraries for Data Science where, for example, different
clustering algorithms are implemented as classes with the same interface, so they can be used (for the most part)
interchangeably. Another feature of the strategy pattern is that it allows the algorithm implementations to
encapsulate internal state required to perform the operation without exposing it.
When to Use
There are several situations in which a Strategy pattern is applicable. The situations most relevant to this
assignment are when:
? many related classes differ primarily in their behaviour, and
? multiple variants of an algorithm are necessary.
Revision 1
COMP 3023 Software Development with C++ - Assignment SP5 2018 Page 6 of 22
Note: the strategy pattern can be applied more efficiently to fat objects, i.e., objects with many data members, by
being an extra data member themselves. As such, the strategy pattern changes behaviour from the inside-out
whereas the decorator pattern changes behaviour from the outside-in.
General Structure
The classes and responsibilities in the Strategy pattern include:
? the abstract Strategy class, which defines the interface that all the algorithm variants support;
? the ConcreteStrategy classes that each define a variant of the algorithm conforming the interface
defined by the abstract Strategy class;
? a Context class that references a Strategy object, which may be configured at creation or dynamically
through an interface (e.g., setAlgorithm(…)), and executes the Strategy object when desired.
Implementation Hints
In C++, the function call operator ‘()’ can be overloaded like other operators, which makes it easy to execute the
strategy object as if it were a function. Overloading the function call operator will not be explicitly covered until
closer to the submission deadline of this assignment and, therefore, is not required in your implementation.
The interface of the Strategy class may specify parameters such that all the information it expects to require is
passed in. Alternatively, the Strategy interface may accept a reference to the Context class, so that the Context
can pass itself to the Strategy object, allowing it to retrieve data from the Context object as required. Consider
the consequences of each approach and justify your implementation choice in your comments.
Usually the ConcreteStrategy will be chosen by the client and passed to the Context; however, in this
assignment the ConcreteStrategy may be predetermined in most instances.
Task Description
Roguelike Dungeon Crawler games are a genre of game that exhibit features typically attributed to the 1980s
computer game Rogue2
. In general, the goal of a Roguelike game is to clear a dungeon, level-by-level, until the
final level is completed. Common features of a Roguelike game include:
? procedurally generated dungeons,
? randomised items and weapons,
? permanent death, and
? a variety of creatures to fight that get progressively more difficult deeper into the dungeon.
Within each level of a dungeon there typically exists distinct rooms where creatures are encountered and items
are waiting to be looted.
In this assignment, you will design and implement a simple text-based Roguelike Dungeon Crawler game that
fulfils the following specification. Unlike the original Rogue, text-based does not mean ASCII art but instead will be
2 https://en.wikipedia.org/wiki/Rogue_(video_game)
Revision 1
COMP 3023 Software Development with C++ - Assignment SP5 2018 Page 7 of 22
driven by a text-based menu interface inspired by another genre of text-based adventure game originating from
Multi-User Dungeon (MUD)3
. Moreover, combat will be turn-based with only one opposing creature at a time.
The aim of the assignment is to allow you to practise creating an object-oriented design and implementing it in
C++ using the features learnt so far, namely: class inheritance and polymorphism, dynamic memory allocation,
and smart pointers. The focus of the assignment is on identifying and applying appropriate Design Patterns to
help develop the game in such a way that components are easily reusable and extensible—remember the DRY
(Do Not Repeat Yourself) principle.
To that end you will, first, need to develop a class design using UML class diagrams based on the requirements in
the remainder of this specification. A simple and free UML editor that can be used for this assignment is UMLet
(http://umlet.com/). The UML class diagram must include all classes, public data members, public member
functions, protected data members and member functions (if any), and associations between classes. The
diagram may optionally display private member functions, but private member variables should not be included.
For this assignment the game has been simplified to a certain extent, e.g., dungeon creation is not completely
procedural. Moreover, some of the underlying elements (such as the basic menu interface code) will be provided
to get you started. The provided code will be incomplete and may need to be modified to fit your class design.
Parts of the provided code that must not be modified will be marked as such. You will then need to implement
the rest of the game according to the specifications and your design.
A brief example of how the game will be played is provided below. The remainder of the section describes the
requirements of the game in more detail.
> dungeon_crawler.exe
Welcome to Ashes of Software Development: Rite of Passage!
Developed by Matt Selway
COMP 3023 Software Development with C++
*Press any key to continue*
> [Enter]
What would you like to do?
(p)lay the game
(q)uit
> p
You need to create a character... what is your name?
> Dungeon Crusher
Welcome Dungeon Crusher, you have *6* stat points to allocate.
A high Strength stat will boost your damage in combat.
How many points do you want to add to your Strength?
> 3
You have *3* stat points remaining.
A high Dexterity stat will increase your ability to dodge creature attacks.
How many points do you want to add to you Dexterity?
> 2
You have *1* stat point remaining.
A high Wisdom stat will boost the effectiveness of magical items.
How many points do you want to add to your Wisdom?
> 1
*** Character Summary ***
Dungeon Crusher
Strength: 4
Dexterity: 3
3 https://en.wikipedia.org/wiki/MUD1
Revision 1
COMP 3023 Software Development with C++ - Assignment SP5 2018 Page 8 of 22
Wisdom: 2
Health: 50 / 50
Damage: 10 – 10
Dodge: 20%
Weapon: you look down at your fists and shrug, "these will do"
Item: you look into your backpack, emptiness looks back.
if only you had something to put in it.
While roaming the country side you encounter a strange fork in the road.
To the left lies a dark cave, the foul stench of rotting flesh emanates from it.
To the right is a mysterious tower, a strange magical energy lights the path.
What would you like to do?
Go left: create a (b)asic dungeon
Go right: create a (m)agical dungeon
Go (b)ack the way you came (return to main menu)
> l
You enter the dark cave and see...
A dark and empty chamber.
To the NORTH you see an opening to another chamber.
To the SOUTH you see the entrance by which you came in.
What would you like to do?
Go (n)orth
Go (b)ack the way you came
View your (c)haracter stats
Return to the main (m)enu
> m
After exploring *0* levels, you run out of the cave as quick as your legs can carry you.
As you emerge from the cave you are startled by the bright light and pause while your eyes
adjust.
What would like to do?
(p)lay the game
(q)uit
> q
*Are you sure you want to quit? (y/n) *
> y
Goodbye!
Note: the following conventions will be used when illustrating example output:
? a ‘>’ at the beginning of a line indicates the command line prompt
? bold orange text indicates input entered by the user
? user input surrounded in square brackets ‘[…]’ indicates a specific key press
? hitting [Enter] after other input is implied
Workplan
In order to complete this assignment, it is important that you take a planned, methodical approach to the
assignment. You will need to think about how to break down the assignment into smaller chunks of functionality
that can be implemented and tested one at a time. Working in an incremental manner, and testing as you
progress, helps to limit the scope of errors that are introduced as you perform the implementation. Moreover, it
allows you to focus on a single problem at a time as well as refactor and redesign the application in a controlled
manner as you (re)discover requirements or issues that were not obvious at first.
This assignment should be completed in the following stages:
1. Read the assignment specification (more than once)
Revision 1
COMP 3023 Software Development with C++ - Assignment SP5 2018 Page 9 of 22
2. Ensure you understand the 4 design patterns
3. Design a class hierarchy using UML class diagrams that addresses the requirements and applies the 4
design patterns to the game appropriately. Note: the design does not have to be perfectly complete from
the outset, you can revise it as you progress through the assignment. However, it is good to start by
conceptualising your approach before diving into the implementation.
4. Implement character generation—refer to section Player Character
5. Implement the basic dungeon: walls and doors, no creatures nor items (standardised layout)—refer to
section Dungeon (Rooms, Walls, Doors)
6. Implement dungeon navigation: at this point you should be able to play the game and transition between
rooms and dungeon levels without combat—refer to sections Dungeon (Rooms, Walls, Doors) and
General Gameplay
7. Add items and item pickups—refer to sections Weapons, Items & Enchantments and General Gameplay
8. Add one creature type and combat interactions: you should now be able to play the game with all general
gameplay requirements/features complete (except second dungeon type)—refer to sections Creatures
and Combat
9. Add remaining creature types—see section Creatures
10. Add second dungeon type—see section Dungeon (Rooms, Walls, Doors)
As you implement the functionality, you should tick, highlight, or otherwise mark the requirements that you have
completed. This will help you keep track of your progress and ensure you have addressed all the requirements in
your submission.
General Gameplay
The gameplay state will be controlled by a Game object. There can only ever be one game in play at one time.
The game allows a player character to explore a dungeon of your choice, room-by-room. Along the way they may
encounter creatures that they will have to defeat before they can continue exploring (unless they can find a way
around them). They will also come across items to loot, some of which may be weapons that will help them
defeat the creatures they encounter. The last room in the dungeon typically has a more powerful monster that
needs to be beaten for the exit to reveal itself but is not required.
When the game is first started, a welcome message will be displayed and the user will be given the option to play
the game or quit from the main menu.
If the user chooses to quit, the game will prompt the user to confirm that they want to quit the game:
? If the user selects ‘yes’, the game will end.
? If the user selects ‘no’, the game will return to the main menu.
If the user chooses to play the game (from the main menu), the game will prompt the user to create a character.
Refer to section Player Character for details on character creation.
After the user has created their character, the game will prompt the user for the type of dungeon they would like
to explore. There must be two types of dungeon: a “basic” dungeon, and a “magical” dungeon. Refer to section
Dungeon (Rooms, Walls, Doors) for details on the types of dungeon and their construction.
Once the user selects a dungeon type, the game must create the first dungeon level according to the selected
type, place the character in the first room, display the room’s description, and prompt the user for the next
action. The user can take various actions depending on the configuration of the current room, whether a creature
is present, and the item(s) the character currently possesses. The following actions must be supported, as
appropriate:
Revision 1
COMP 3023 Software Development with C++ - Assignment SP5 2018 Page 10 of 22
? Move the character to the next room: North, South, East, or West
? Move the character to the previous room (whether this is North, South, East, or West depends on the
door the user “came through”)
? Pick up an item/weapon
? Compare the weapon/item in the room with that currently held by the character
? Attack the creature
? Use an item
? Use the weapon’s special ability
? Return to the main menu
In most cases, after a choice is made, the action menu is displayed again.
If the user chooses to move to another room, the current room will be updated to the room that was selected,
the new room’s description will be displayed, and the user prompted for the next action.
If a creature is present in a room, the user cannot move to another room (other than the one the user came from)
until after the creature is defeated (refer to section Combat).
If a weapon or item is present in a room, the user can choose to pick it up. If they do so, the character’s current
weapon/item is replaced, and the previous weapon/item disappears. To avoid accidental replacement of a
weapon/item by the user, the game must warn the user that their weapon/item will be replaced and prompt for
confirmation.
If the user chooses to compare the character’s weapon/item with that of the room, the description and stats of
both items will be displayed. Whether the weapon/item is the currently held weapon/item or that of the room
must be clearly indicated.
If a creature and an item both exist in a room, the item cannot be picked up until after the creature is defeated
(refer to section Combat).
If the user chooses to use an item, the item’s effect will be applied and the item will be removed from the
character.
If the user chooses to use the weapon’s special ability, the ability’s effect will be applied (the weapon will not be
removed).
If the user chooses to return the main menu, the current dungeon and character will no longer be playable, i.e.,
a new character will have to be created. Therefore, the user must be warned that progress will be lost and
prompted for confirmation. If the user confirms their intent to return to the main menu, the number of dungeon
levels successfully completed must be displayed followed by the main menu.
Once the user reaches the final room of the dungeon level (and defeated any obstructions) the door to the next
level will be revealed. If the user chooses to go through that door (via the appropriate direction, North, South,
East, or West), the game will return the user to the main menu. If the user chooses to play the game (again), a
new dungeon level must be built (of the currently selected dungeon type) but the existing character will be used.
If the character’s health stat drops to zero or below, the game ends: the game will display a game over message,
the number of dungeon levels that were successfully completed, and return to the main menu. If the user wishes
to play again, they will need to create a new character.
Revision 1
COMP 3023 Software Development with C++ - Assignment SP5 2018 Page 11 of 22
General Requirements
At any time a valid character exists, the user must be able to view their character details (stats, items, etc.). After
viewing the character details, the user will be able to view the weapon specific details, the item specific details, or
return to the main menu.
All user inputs must be validated. If an invalid input is given, a warning must be displayed to the user and the
menu options redisplayed.
All classes must have appropriate constructors and destructors.
All objects that can be described must be able to be output to a stream using the stream output operator ‘<<’.