Archive

Posts Tagged ‘Text RPG’

Case Closed.

March 3, 2008 1 comment

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.

Advertisements
Categories: Game Development Tags:

Implementation of Battle System

October 22, 2007 Leave a comment

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.

Categories: Game Development Tags:

New Battle System

October 16, 2007 Leave a comment

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!

Categories: Game Development Tags:

MUDd UPDATE

October 15, 2007 Leave a comment

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.

Categories: Miscellaneous Tags: ,

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.

Categories: Game Development Tags: ,

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.

Categories: Game Development Tags: ,

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.
Categories: Game Development Tags: