Zach and Dan’s RPG – User Manual

How to Play
Note: To run the game, run project GUI123 in the solution. Compilation requires boost 1.44 and GLUT.

1. Upon running the game, a window will pop up with instructions. Click “Start Game”.
2. Upon starting the game, you will see two windows: one shows you your party (the top row),
creatures (the second row; if any), and which directions you can move (yellow arrows in the
North/South/East/West of the room).

Known bug: The party will not display in the first room

To test out combat, head east! The second room has plenty of monsters. Pressing Fight will engage in
one round of combat against the monsters. (Note: Currently, there is no feedback on-screen of current
hit points/magic points/exp of heroes, but it is processed in the background). Upon pressing fight, each
hero and each monster will randomly choose to attack or defend. They have the following effects,
depending on class:

 Fighter (Red)
o Attack – attacks two creatures for 10 damage per hit
o Defend – enters a defensive stance, halving the damage of the next blow he receives
 Cleric (White)
o Attack – Attacks one random creature for 6 damage
o Defend – Casts a healing spell, healing each party member for 5hp each
 Wizard (Blue)
o Attack – Casts a spell attacking every enemy in the room for 4 damage
o Defend – Casts a reflective spell. The next time the Wizard is hit, the enemy that
attacked him will take the attack’s damage instead.

Known Issues
 Party does not display in the first room
 Boss is not in final room (had issues getting the code working right); consider yourself a winner if
you get there :P
 Items are picked up by players, but not displayed properly next to them. D’oh
 Memory leaks in the GUI – though, it’s all the dungeon stuff, which should be there the whole
game anyway, soooo…. (Note: these are Dan’s fault)
 HP/MP/Exp are not displayed next to PCs (Didn’t get a chance to implement)
 Only combat feedback is something dying (it’s no longer drawn on-screen)
Objectives Addressed
Objectives

 Practice with single inheritance by creating a robust class hierarchy that demonstrates
abstraction, encapsulation, and polymorphism via dynamic binding.
 Demonstrate multiple inheritance with a minimum of three classes (e.g., one child inheriting
from two parents).
o Boss class (for enemy) implements every character class
 Organize code with headers and includes.
 Manage memory destructors and freeing dynamically allocated memory.
 Implement exception handling and user-I/O.
o Exception-handling seen with threads in Dungeon::fight() in Dungeon.cpp (RPGLibrary)
 Apply C++ and OOP to an interactive application.

High Concept

Write a text-based RPG in which a player leads a party of characters in a dungeon to victory.

o Done! 

Character Specifications
The player controls a Party of Characters. Each Character will have the following: hit points,
magic points, experience points, an inventory, a unique alignment, a class

o HP is modified in combat
o They *have* magic points, but they aren’t used. But, they have them for the purpose of future
implementation
o EXP is earned in combat, but not utilized (yet!)
o Characters have items
o Alignment is implemented in the code, but not utilized in gameplay
o Classes are implemented as children of Character; i.e. Fighter implements Character, but
overrides attack() and defend()

Each Character can: attack, defend

o Each character class has its own attack/defend methods to customize how it attacks or defends
o Attack/defend are not explicitly picked by the player; they are picked “behind the scenes”
randomly for each party member when one clicks Fight

The player's Party has the following: at least one member who can cast spells, at least one member who
can use physical means

o Fighters use 100% melee

 o Cleric attack() is melee, defend() heals the party
o Wizard attack() is a spell that damages all opponents, defend() casts a reflection spell that
defends the wizard

The Dungeon
There are 6 rooms; the player may move freely between them

Map:

❸—❹—EXIT
| |
❶—❷—❺
|    
❻
Enemies
Populate your Dungeon with other creatures, like an Enemy or NPC.

o Each room has a party of enemies

These other creatures will interact with the player's Party via combat or some other mechanism that
you devise.

o The primary interaction is via combat (the Fight button)

Loot
A Room may have items, and an (sic) creature with whom (sic) you interact may drop items.

o Items are dropped when a creature dies

Each player can acquire these items, stored in a Character's inventory.

o When item is dropped, player party picks it up automatically; item is assigned to a random
character

Mechanics

The player may

 move the Party around the dungeon.

o Covered by the North/South/East/West navigation buttons
 interact (e.g., fight) other creatures.
o Fight button covers this one
 defend against attack.
o Also covered by fighting (characters in the party will defend 25% of the time)
  store and retrieve items.
o Pick-up happens automatically when enemies are defeated
o Items are used automatically when triggered appropriately

Victory Conditions

You may freely decide how the player wins the game. Do they need to escape the dungeon with
at least one remaining Character? Defeat all the enemies? Find secret treasure? Be
interesting.

o Exit the dungeon to finish the game (Note: exit is east from room 4)

o Goal: escape with as much treasure as possible!

Interface
Provide a clear, concise, and helpful menu to the player.

o MFC GUI w/fight/north/south/east/west buttons accomplishes that job

Ensure that you include a choice for help and that you handle all incorrect input.

o Instructions are displayed at all times on the screen

Input must generate clear output: ensure that player knows what happened.

o Feedback appears in the OpenGL window

Balance and Fun

Given the flexibility of design, make reasonable choices that will provides a balanced, interesting
game that still demonstrates mastery of OOP principles (especially in inheritance and
polymorphism) in C++.

o Our game is indeed balanced and interesting!

For the sake of my sanity, please make combat short enough that I can quickly move through the
game.

o Done, my good man!

You may wish to include an option via your interface for short/long versions.

o Nah, combat is simple enough as-is w/threaded auto-fights

Documentation

Inside a user's manual, explain how to play your game and how (and where) you addressed each
of the objectives.

o You’re reading it

Bonuses
Use threading via Boost to support real-time interactions instead of turn-based actions: 100 points. For
example, if I have five characters fighting against a room full of Orcs, I'd rather let the game handle a
"simultaneous mashup" and report back the results.

o We went with the “simultaneous mashup”: The Fight button runs a threaded round of combat,
where both the player’s party and the enemy’s party gets to attack at the same time.
o See Dungeon::fight() in Dungeon.cpp in RPGLibrary

Create a GUI using .Net and CLR C++ to improve the interface. You must use Native C++ for the game
engine and employ MVC for your overall design: 100 points.

o Input is done through an MFC GUI window, which acts as the controller and as a view.
o The OpenGL window is a view that is updated by the controller
o The GameEngine class is the model, which processes the input and updates the view
appropriately

Make a 2-D game via OpenGL or DirectX: 100 points.

o Room contents, enemies, party info and directions you can move are displayed in an OpenGL
window 