Case Closed.

This project is closed. Of course I would never finish it. I’ve realized that I should spend my time on a project that has an end goal. Plus, I’ve started 3D programming, so why would I want to work on a text RPG? In the end, it was fun working on this project while learning the basics of C++ and Object-Oriented Programming.

Implementation of Battle System

Well I’ve found some time to try and implement this new Battle System. My previous Battle System worked from Unit member functions, but this new system needs to be done in a global function because I don’t want every Unit carrying around this huge Battle System. Also, by creating a global function that takes two Units as parameters will allow me to simulate combat for non-player Units, which might mean that NPC team-mates may be just around the corner!

Anyway, so far I’ve got a rough draft of this new combat function created, but I’m having some problems with the action comparisons, so it’ll be a few more screw-around’s with it until I get it correct.

New Battle System

So, I came up with an idea for my Battle System for my RPG. Currently, the battle system is just a series of comparisons of the attributes between the two fighting Units. For example, the system works like this:

1. Take the two Units’ Initiative attribute and modify slightly by a random number, then compare. Whichever is higher will attack first.
2. Compare the Agility attribute of the attacker and defender. If the attacker’s Agility is greater than or equal to that of the defenders’, the attack is successful.
3. If the attack is successful, take the attacker’s Attack attribute and subtract the defender’s Defense attribute, then subtract that total from the defender’s Health.
4. If the defender’s Health is less than or equal to zero, announce the attacker as the winner, and exit the battle system. If the defender’s Health is greater than zero, continue.
5. Repeat step 2 with the attacker and defender switched.

During this entire process the user does not interact with the game, they just sit back and watch whether or not their attributes are higher than the opponents.

For the new Battle System, the user will create a battle sequence prior to each round. As the user advances in level, the length of their battle sequence increases. The enemy Units in the game have levels as well, so their battle sequences will be dependent on their level as well. There is no set amount of rounds; however many it takes for either of the Unit’s Health to reach 0. This system allows for Items to be taken into account (once they’re added) as well as different Classes (once they’re added). The idea of the battle sequence is this:

• Say both the user and the enemy are low level, so their battle sequence only has length 4. Prior to each Round, the Units decide their 4 actions (separated by a space) for that Round. The actions are pretty basic–either attack or block–but directions or parts of the body are required. For example, the user might choose their battle sequence to be: blockLeft slashLeft swipeRight blockRight (I will explain these later)

• Once both Units have chosen their battle sequence, each action is compared with the opponents action, and they are executed simultaneously. For example, the first action the user has selected is blockLeft, and the first action the enemy has selected is swipeLeft, then the user would have blocked the opponents attack.

• If an attack is not appropriately blocked, the defenders has a chance to evade the attack, which is their Agility attribute modified by their armor’s weight. If a hit is made, then Unit that was hit will lose an amount of Health equal to the attackers Attack value (which will be their Strength attribute plus their weapon damage) minus the Unit’s Defense value (which will be their armor’s defense value, if any, for that part of the body). Once the Health has been deducted, continue with the comparisons.

• Once all of the battle sequences have been parsed, if both Units are still alive, the user will once again enter in their 4 actions for the next Round, and the enemy will do the same. This process will continue until one Unit is dead.

• The possible actions will be:
  • slashLeft – a slash at Left shoulder/neck
  • slashRight – a slash at Right shoulder/neck
  • swipeLeft – a swipe at Left side of torso
  • swipeRight – a swipe at Right side of torso
  • blockLeft – a block that covers entire Left side
  • blockRight – a block that covers entire Right side
  • (With the inclusion of other Items such as Potions, there will be actions to consume/use those Items)

• Since each attack corresponds with a particular part of the body (left side of shoulder/neck, right side of shoulder/neck, left side of torso, right side of torso), the inclusion of Armor will be able to include various pieces. As of now, with these attacks, the pieces of armor would be:
  • Helmet/Head
  • Pauldrons/Shoulders
  • Torso/Chest

• Different types of weapons (Sword, Axe, Mace, PoleArm, etc.) could allow for different attacks. For example, you could thrust with a Sword or PoleArm but not with a Mace or Axe. This concept will not hold high priority as I plan on it introducing a lot of headaches, so this will be in the distant future.

• As the levels of the Units increase, their battle sequence increases in length, allowing for more actions per Round. This may seem unnecessary, but when the combating Units have different levels and different battle sequence lengths, the Unit with the longer battle sequence will continue to execute those actions while the weaker Unit is helpless. At this point, there are no comparisons made between actions; if a Unit attacks, they hit, since the defender does not have a corresponding action. For example:
  • User has a battle sequence of length 6, they choose – blockRight swipeRight slashRight swipeLeft blockRight swipeRight
  • Enemy has a battle sequence of length 4, they choose – blockLeft blockRight slashRight blockRight
  • The outcome for Round 1 would be:
    • Action 1: Both Units blocked, nothing happens
    • Action 2: User swipesRight and Enemy blocksRight, no damage done
    • Action 3: Both Units slashRight, calculate if either Unit dodges, and subtract Health accordingly
    • Action 4: User swipesLeft and Enemy blockesRight, the attack is not blocked, calculate if Enemy dodges, subtract Health
    • Action 5: User blocksRight, Enemy has no action, nothing happens
    • Action 6: User swipesRight, Enemy has no action, calculate if Enemy dodges, subtract Health accordingly

• The battle sequences will be a part of the Unit class and stored in a vector to allow for dynamic resizing (a character levels up and their battle sequence increases).

Well that seems to cover everything, once I realize details and specifics I will add them to this post. Now I just have to hope that I can find the time and energy to add these new features, which I think will add a huge level of interactivity and fun to the game. Thanks for reading!

MUDd UPDATE

Well, I would like to continue development with this game and implement the previously mentioned features. But, first, I’m going to have to re-acquaint myself with C++ and my game. Luckily, I heavily commented all of my code (no really, I didn’t realize how much commenting everything really helps you understand later). Unfortunately, I have plenty of other things to focus on, like my most challenging course load yet and learning Java. Hopefully I can find some time to work on this project between other priorities.

Quick To-Do

Here’s a quick list of what I plan to implement in the near future, in tentative order:

• Items (Discussed below)
• More Linked-Lists (Discussed below)
• Shops/NPCs – Need somewhere to spend the Gold
• Quests – With all this world for the player to traverse, they need some sort of goal
• Classes – As of now, there are no classes, only attributes
• Magic/Spells – If there’s Classes, there needs to be Magic

I’ve explained the first two implementations in my previous post below. As for the others, these will most likely occur in this order. The Classes and Magic are expected to require the most work, as I will most likely have to scrap my battle system and write a new one.

To Come…

Well, there’s still a lot to be done, but the next few things I want to implement are:

• Items, particularly Weapons, Armor, and Potions.
• More Double Linked-Lists

Items – The game needs them. I am planning on making a base class, Item, that my Weapon, Armor, and Potion classes will all derive from. My intentions for the use of items will be simple: Weapons will add to the characters attack value, Armor will add to the characters defense value, and Potions, when used, will add to the characters Health value.

By having all the Weapons, Armor, and Potions inherit from the Item class, I can use pointers-to-Items to access them. By doing this, I can create an array of pointers-to-Items, and my array could then hold all the Weapons, Armor, and Potions in the game. This would mean all the Items in the game would have to be explicitly created, but that is what I intend. This way, I could use the D&D weapons, perhaps, with all their attributes. Also, by having all the items in the game be accessible through pointers-to-Items, I could have all the character’s inventories be simply a vector of these pointers-to-Items. Since it is much easier to pass around pointers than the items themselves, this will work out good.

More Double Linked Lists – This will allow for more world to be created and accessible to the user. Currently, the game world is made up of just one Double Linked List, and the user starts at the head of the list and fights their way through to the end. Pretty linear, and pretty boring, so I came up with an idea that I think will be easy to implement. I could add to the Room class a pointer to the head of another double linked-list, which is just another Room. This would allow the player to not only move horizontally, but vertically like so:

Here is the current game, where the player starts in roomA1 and fights through to roomA100:

Now with these added lists, the player could do A LOT more. Each Room in the A list has a linked-list leading off of it, and actually each Room could have a linked-list leading off of it, but that would get pretty messy, so I’ll just stick to what I have. This would allow for many cool things to be added, perhaps the A list would be the wilderness, or outside, and then saw roomA3 was a forest, the D list could be a cave that the player happens upon, where they could go through the many depths of this cave.

As I said, I think this would be easy to implement, seeing as my game loop just needs a linked-list to operate, it wouldn’t matter what linked-list it is. To shoot the player off into another linked-list, I could just set the player to the head of the new linked-list, rather than just the Next or Previous Room.

New Features

Ok, so I recently added quite a bit of new features to my game. Here they are:

• I downloaded the SDK(Studio Development Kit), allowing me to add color to my text and use some nifty functions, particularly the Sleep() function, which basically stops the execution of any more code for a given amount of time. Now that I was able to color my text, I created a welcome/intro page, that just displays some ASCII graphics, the programmer(me), and the IDE used to develop the game. For example, my welcome page will be displayed for 10 seconds, then the screen will be cleared and the menu will be brought up. Here’s my welcome page:

• I added a new attribute to every character in the game – the player and the enemies – Evasiveness. Along with this, I added a new step in the combat function: hit-chance. Now, before executing an attack, there is a hit check, which is simply a random number modified by the characters Evasiveness. This allows for misses to happen, which is a necessity in any game with combat.
• I added a new attribute to the characters in the game – Gold. Upon creation, each character was given a random amout of gold. At the end of combat, if the player wins, then the gold that was on the monster they just killed is then taken from the monster and given to the player. To handle this action of gold transfer, I added a member function to the Player class that would take a Monster in its parameter, and then exchange the gold. Although this is set up, I currently don’t have a use for Gold in the game. Soon to come!
• I also added round information to be displayed, so rather than entering combat and instantly have the winner’s name displayed, you enter combat and each rounds information is displayed…instantly. This was pretty annoying, since in order to track the fight you had to scroll up to the top of the DOS window and read down all the lines. Not only that, but there was no suspense since the winner was instantly announced. This is what I needed the Sleep() function for; to display the rounds information, then Sleep() for 2 seconds, clear the screen and display the next rounds information.So, after getting that to work, I colored the output, giving it a little flare, and making it easier to see who hit who for how much. Now with the combination of Sleep(), which adds suspense and provides some entertainment, and colored output, combat has been given a major upgrade!

Here it is in action(due to PrintScreen, I wasn’t able to get multiple shots of the same battle, so these are from several battles):

• I’ve also done minor work, like wrapping the user prompts while in the menus within loops to only accept an appropriate input. For instance, when the user is asked whether or not they want to keep their randomly generated stats, which is a yes or no question, they could enter in anything other than “yes” or “y” and new stats would be generated. For some, this wouldn’t be a problem, but I had put a limit on the amount of times the user could re-roll their stats, but this limit would only count for the amount of times they entered in “yes” or “y.” So they could only re-roll for stats 5 times via the “yes” or “y,” but they could re-roll for stats infinitely by entering any other input. So to solve this I wrapped the prompt in an infinite loop, with the only exit to be an appropriate response to the question. This forced to the player to only re-roll for stats 5 times by entering “yes,” and any other input was ignored. I also added this same feature to several other prompts throughout the game.

From Day 1 to Now…

Well, I suppose I will start by explaining how I started my current game, what I wanted to do with it, and then work my way up to it’s current state.

After spending a lot of time reading my C++ and game programming books, browsing online tutorials and forums, and checking out source code for various games, I had plenty of ideas of what I wanted in my game. That wasn’t the problem, I’ve played my fair share of adventure games and RPG’s, I knew what I liked and what I didn’t like. The problem was finding the C++ code to do it, and making it all work together. So my first attempt, before I knew any OOP (Object Oriented Programming), was to just have a bunch of global variables for all the characters in the game, and have the player run through a bunch of if-else statements.

There was no combat, no numbers, just one-swing combat. The computer would calculate some random values for the two characters attack, compare them, and whichever was higher, there would be an output along the lines of “The troll slashed you across the face! You die!,” then the program would exit. So, that was stupid, and I knew it, but it suppressed my cravings for a real game for the time being, so I abandoned that “game” and went back to the books.

Once I got into OOP, I tried again. Starting from scratch, I made up some quick menu’s to allow the user to enter how many randomly generated enemies they would like to create. This ended up taking a while, and several visits to instructor and teaching-assistant for my C++ course. So once I worked out all the bugs, I effectively used a vector to dynamically store all the enemies. Now I wanted to fight them. So I added a character creation process, which was composed of generating a random enemy, showing the stats to the user, and asking if they liked them or not. If they did, they would get to name their new character, and then it would be stored in the same vector with the enemies. If they didn’t like it, it would be deleted, and a new random enemy would be generated and displayed to the user. This process would repeat until the user had found something they liked.

Now, I was able to use what I had previously worked on in my first game, but instead of using random numbers for the if-else statements to decide who would win, I used the 2 characters stats. Keep in mind, there was no “multiple rounds,” where one character would strike the other, and their health would decrease, then it was the other character’s turn. No, it was still just comparing the 2 characters’ Attack, and whichever was higher, they would win. That was it. The cool thing though, was that I was able to run through the vector of enemies and have the player fight each one. Well, that was enough to suppress my cravings for a real, playable game, so I abandoned it and went back to the books.

Since I had combat and character creation covered, I wanted a way for the user to be able to move about. All the user could do in my previous game was generate their character and some enemies to fight, and then select the menu option to “FIGHT!” The first idea that came to my head, was to create a class called Room, and each Room would have a description, then I would make a whole bunch of these Rooms, store them in a vector (I was into vector’s at the moment), and start the user off in the first Room of the vector. They wouldn’t really be in any Room, rather, the first Room’s description was read, and then the user would have to enter in something, and their input would go through an if-else sequence to determine whether or not they’re allowed to go to the next Room. If they entered in the password, then the iterator, that was initially set to point to the first Room in the vector, would be incremented, then pointing to the second Room. Then, as with the first Room, the description would be read (through the iterator), and the process would start over.

This was only an idea though, I had never put it in code. I didn’t really like the idea…well, I knew I could do better. So, I continued to read my books and browse the internet, and I happened to find several fairly well written articles on Linked-Lists. I remembered that I had previously seen these articles, but at the time I wasn’t ready to try and understand what was going on. Well, I was ready now, so I carefully read through them, understood them for the most part, enough to start using them. I know had my method for walking through Rooms, I liked it, and it was going to be a challenge.

Starting from scratch once again, I came up with some Linked-List implementations, particularly Double Linked-Lists, to represented the Rooms that the player could walk through. Although this method was going to work, I knew that I wasn’t going to be utilizing the real features of Linked-Lists that they are intended for, which is random insertion and deletion. I wasn’t going to be having Rooms randomly created and inserted and deleted in my chain of Rooms, I was just going to explicitly create each and every room, and chain them together as a double linked-list.

So I came up with my Room class that I would comprise my double linked-list of. All these Rooms had a description(a string), an exit(a string), and a pointer named Next to another Room, and a pointer named Previous to another Room. This is how a double linked-list works: each object, in my case Rooms, had a pointer to another object of the same type, in my case Rooms. This way, each Room knew what the next and previous Rooms were, since it had a pointer to them. For my game, this would allow the user to start in the first Room, the head, and then when they entered in the exit for the room, the Room that their current Room’s Next pointer pointed to would be set to the user’s position. Once this happened, the description of their new Room would be read, and the user could now enter in something to allow them to go to the Next Room, or go to the Previous Room (hence the need for double linked-list. A single linked-list only allows to move forward, or next). This process would be repeated until the user got to the end of the chain of Rooms, or the tail, where the loop that was processing all the Rooms would end and the user would go back to the menus.

Now that I had my movement covered, I wanted to incorporate combat. I knew how to do it, and it was fairly simple to add, with no problems. I would create a Monster class, and add to my Room class another pointer, this time pointing to a Monster. Now, when the user was in a Room, they could fight a Monster, since they had access to it via the pointer-to-a-Monster that every Room had. So, when the Rooms were created and chained together in the double linked-list, I just added the creation of a Monster, and set the appropriate pointer to point to this new Monster. Now, each Room had a description, an exit, a pointer to the Next Room, a pointer to the Previous Room, and a pointer to a Monster.

Now that I had correctly set up the necessary ends to meet that would allow for combat to take place, I needed to come up with a much better combat process then what I had used previously. Although I came up with something new, it was still nothing amazing. Each character in the game had the basic attributes, Health, Speed, Attack, and Defense. The process of combat was actually a member function within the character class that made up all the character’s in the game, and it went like this:

1. Generate a random number and modify it by each of the characters Speed attribute, then compare the two numbers.
2. Whichever character had a higher random number(modified by their Speed) was marked as the Attacker, and the other was the Defender.
3. Then, the Attacker would strike the Defender, and the Defender’s Health would be decremented by an amount equal to the Attacker’s Attack attribute.
4. Check to see if the Defender is still alive, if they are, then the Defender will strike the Attacker, and the Attacker’s Health would be decremented by an amount equal to the Defender’s Attack attribute.
5. If the check failed, and the Defender was not alive, then the Attacker would be returned from the function.
6. Check to see if the Attacker is still alive, if they are, go back to step 1.
7. If the check failed, and the Attacker was not alive, then the Defender would be returned from the function.

So whoever won the fight would be returned from the function, where their name would then be announced as the winner.

To sum everything up, at it’s current state, the user would be allowed to create their character, then they would start their journey. The first rooms description would be read (there were no monsters at the head of the linked-list), and the Rooms exit would be read, they would be prompted for input, if their input matched the Rooms exit(just a string), then they would be moved to the Next Room. Once they entered the next Room, since there would be a monster in it(the Monster pointer in that Room was pointing to a Monster), they would enter combat with that Monster. Entering combat doesn’t really mean anything cool, just that the loop that I described above would be run until one of the characters had no Health left, and the winner’s name would be announced. Because the combat loop is so simple, it executed in milliseconds, so as soon as the player entered combat, it was over, and the winner was announced on the screen… not very exciting, but it was a start. Regardless of whether the player won or not, they were still able to continue playing.

Once combat was over, the Room’s description would be read, as well as the Room’s exit, and since they came from a Room, the previous Room’s exit was read as well. This meant that the user was given 2 exits, one that led to the Next Room, and one that led to the Previous Room, so they were able to go back if they wanted. This process would continue until the user got to the end of the linked-lists, where they would go back to the menu, or if they entered in “quit” when they were prompted for input.

Well, that’s it, everything up to now. From now on, my posts will describe the features that I’ve added.