RPG Project: Down With The System

Authors: Jeffrey Hata, Cameron Fong, Pedro Gonzalez, Nathan Wong

Project Description

• Why is it important or interesting to you?
  • We find this project interesting because many of us enjoy playing video games and we are interested in the game making process. Some of us have coded text-based games in the past and we want to further our game design and development knowledge.
• What languages/tools/technologies do you plan to use? (This list may change over the course of the project)
  • Language: C++: this is the language that our group is most comfortable with and has the most experience with. Since it is an object oriented programming language, it should help us create objects like enemies, players, items, etc.
  • Replit: an online IDE that allows programmers to collaborate simultaneously on the same project. This will help make collaboration more efficient if multiple users need to work on the same files. The downside to this program is that the stability of its connection to the server it is hosted on can be unreliable.
  • Putty: a program that allows programmers to use git commands on their local machine. It also allows programmers to send and receive code from their local repositories, and from Github.
  • Github: internet cloud used to store, manage, track, and control changes to our project and their respective code. We are using github in order to store our code onto one location, as well as be able to use the kanban feature on github to track the progress of features in our game
  • Google Docs: a text editor that allows live collaboration between multiple users. This program will help us brainstorm ideas, create design documents, and store other resources that might help us in the creation of our game.
• What will be the input/output of your project? What are the features that the project provides?
  • Our game is a turned-based RPG that starts off with the player character being trapped inside a computer due to a powerful computer virus. The goal of the game is to fight your way to the sources of the virus and take it down to free the computer and the player character.
  • The user will input to select and control a premade character that is part of one of three selectable classes: Defender, Firewall, and Cleaner. Each class will have superior stats in one category, but have lower stats in another to make the choice meaningful.
  • The user will be able to visit towns and dungeons. In towns you can buy items and sell items. In dungeons, the player will be able to fight enemies, gather loot, and progress the story.
  • Between battles in dungeons, the player will have the opportunity to do a variety of actions like checking their character’s stats, checking the current items in their inventory, equipping new armors and weapons, buying or selling at the town, or continuing on to the next battle.
  • The user’s character will have an inventory system that can hold different items like potions, weapons, and armor.
  • The main gameplay will take the form of turn-based battles similar to games like Undertale, Final Fantasy, Pokemon, etc. The user will have a menu of options to select during battle like attack, items, and battle skills.
  • The player character will have stats like health, attack points, defense points, and speed points. These stats can be changed through use of different armors and weapons.

Class Diagram

UML Diagram

• Game class: The game client runs the main function of our program runGame(). It also contains functions like battle(), intermission(), and create_character() that will act as the core features of the game. The game class also includes private members for the 5 dungeons, player character, the town, and a bool variable gameOver to signify when the game is ended.
• Player class: The player class includes several private members including a vector of vector of items to represent the inventory with a composition connection to the items class, a composition connection to skillset to represent a unique skill each type of character will have, int money to represent money the player has, and currentWeapon and currentArmor pointers to represent which weapon/armor respectively the player current has. The player class also has several public member functions which include attack() which is calculates how much damage the opponent takes based on the player’s power + current weapon - enemy defense, set_current_armor() and set_current_weapon() which selects what weapon currentWeapon and what armor currentArmor will store, and check_stats() to see the player’s health, power, defense, and speed. Some other functions include display_inventory() which shows the user the current inventory, add_item() which is used when the player buys an item, remove_item() when the player sells an item, and other getter functions to get access to protected members. The Player class acts as the parent class of the different player character classes that the user will choose to play as. These classes include Defender, Cleaner, and Firewall which all come with their own unique stats and skills.
• SkillSet class: This class is a composition of the player class and serves to set the skill the player has after choosing their respective class and becomes the parent function for child classes: Shieldbash is set to the player’s skill if they choose the Defender class, CleanSweep if they choose Cleaner class, and rebuild if they choose FireWall class. Comboskill also inherits from SkillSet to combine two skills together.
• Character class: The class all entities (enemies and the player) inherit from. These derived classes will all include protected members as integer values for health, power, defense, and speed so that all public functions of the player and enemy class can have access to them. The character class also includes a virtual void for attack in which enemies take damage depending on the combination of attack on the player and the player’s weapon while players take damage depending on the enemy’s attack subtracted by the player’s defense. The character class also includes a protected member for the name of the character as well as getters for all of these protected members.
• Enemy class: This inherits from the character class and all enemies will have varying health points, power/attack stat, speed, and defense. In addition, it also includes a virtual attack function as the amount of damage they inflict on the player is calculated differently from the the player’s damage on enemies (see character class for more information), and also include void set_health in order to set the health of enemies after being attacked by the player and is dependent on the player’s main stats as well as their current weapon.
• Dungeon class: This is a composition of the enemy class that will store a vector of the enemy class (each dungeon containing 3 enemies) to represent the encounters for each dungeon for the game. The dungeon class also includes int get_reward() to reward the player with a certain amount of money after a particular dungeon and all its respective enemies are defeated.
• Town class: This like the dungeon class are two destinations the player can travel to and includes connections to the player class as it will modify the vector of vector items that the player has to add or take away items from the player (buy and sell functions respectively), as well as modify the integer money the player has through increasing money if selling an item or subtracting money if buying an item. The town class also includes buy and sell confirmation to make sure the player really wants to be selling or buying a particular item.
• Item class: this is also a composition of the player class which is used in the vector of vector item private members of the player class representing their inventory. This class also serves as the parent class of the potion, armor, and weapon class, allowing the protected member sell_price to indicate the amount of money given to the player when a particular item is sold at the town, string itemType to indicate what type of item (armor, weapon, or potion) something is, string name for the item’s name, and string description for information about a particular item. The item class also includes the public virtual void function check_stats() for the player to see the particular stats (Ex: attack power of a weapon) between dungeons.
• Potion class: This class inherits from the item class which will become the parent class for all subsequent potion types (as of now only healing potion exists) and includes all protected members of the item class as well as int alter to determine how much of a particular stat string type to modify. Check_stats is also apparent in the potion class which allows the player to see what a particular potion can do.
• Weapon class: The weapon class will inherit from the item class and be the parent function for each weapon in the game. In addition, the class includes its own private member attack to specify how much attack each weapon can inflict, as well as a check_stats public function to see said stats.
• Armor class: The armor class inherits from the item class with each armor having its respective sell value, name, itemType, and description from the item class, as well as its respective int protected member to keep track of the amount of defense each armor has which is shown to the player through the check_stats public function. This class is the parent function for all the armors in the game with their own classes that inherit from the general armor class.

Design Patterns

• Strategy Pattern for the SkillSet Classes
  • We chose to use the strategy pattern to help implement the SkillSet classes because we wanted the player to be able to select their battle skills depending on the character they chose. The SkillSet class acts as the abstract strategy and gives the interface to its derived classes which each act as concrete strategies. This design pattern helped us write better code by allowing us to better organize the skills we want to implement and expand the number of skills if we want to in the future. It also made it easier for certain character classes to have their own unique battle options.
• Composite Pattern for the ComboSkill Class
  • We chose to use the composite pattern along with the strategy pattern to implement the ComboSkill Class so that the player has the ability to use an alternative battle option than just the one skill associated with their character. The ComboSkill class acts as the composite as it is a composition of the SkillSet Class. This allows the ComboSkill class to hold two different SkillSet objects within itself so that the ComboSkill object can have the effect of two different skills at once. The use of the composite pattern made it much easier to implement this mechanic into our game by allowing us to treat the ComboSkill class the same as the other SkillSet classes in other functions like battle(), while also cutting down on repetitive code when trying to put two skills together.

Screenshots

• Creation of the main character

• Main battle screen

• Selecting a skill during battle

• Main buying screen

• Main selling screen

• Inventory screen

• Checking player stats screen

• The game over screen along with a valgrind report showing memcheck clean

Installation/Usage

Note: do not put "" into command-line input

1. To install the game, copy the repository on to a linux console by using "git clone --recursive https://github.com/cs100/final-project-jhata004-cfong027-pgonz028-nwong063.git"
2. Once the directory is downloaded, run the commands "cmake3 ." and "make" to create the main executable.
3. Once the executable is made, put in "./main" into the command-line and enjoy!

Testing

• We created unit tests using googletest to check our functions after we finished portions of the game like the battle features and shopping features, or when we finsihed creating classes. The functions we decided to include in our testing were mostly getter functions as well as setter functions because they provided the backbone of most of our features.
• Functions that mainly served to output text to the console or took in user input were not tested through googletest but instead tested manually through playing the game several times to make sure the inputs were read correctly and the ouput was what we expected.
• Through our playtesting, we also looked for memory leaks within our program by testing every possible action that the user could put into our program. We were able to find many errors in our code this way and were able to come up with more efficient methods of coding some algorithms.

• 57 unit tests total