Category: Articles

Today, I created a new model in Blender which will represent a collectible socket.  The model is basically a sphere with objects rotating around it.  The rotating objects were created with a circle, which was extruded out.  Then the edges for every other segment were removed.  Then I added four bones that point outwards from the center.  Next, I set the animation to 20 frames, and I rotated the armature half way at the end of the animation.  Since the model is symmetrical, I didn’t need to do a full 360 degree rotation.  Like the other models, I exported the animation frames and then used Gimp to touch up the images.

 

Similar to the Weapon and Armor collectibles, I created a CollectableSocket class.  Also in the same way, I added a List of sockets that the player has collected in the Player class.  I added all of the Sockets to the EquipmentCatalog, and added methods for returning a socket and generating a random socket.  On the equipment screen, I now display the list of all sockets the player has collected.

I realized that my existing collectibles had 30 frames in the animation.  This value was set as a constant in my collectible class, so I removed the const declaration and changed the variable to protected.  In the constructor of the CollectibleSocket class, I set the number of frames in the animation to 20.  This was a fairly simplistic change, which would had been much more painful if I hadn’t used good object oriented programming style.

 

The Armor and Weapon classes have been updated to include a List of Sockets and an integer which represents the maximum number of sockets for that item.  To equip a socket, for now I have made it so that pressing the action button (X) will set a boolean to go into select socket mode.  This may need to be extracted into another screen later.  This sets the select socket menu to active.  Pressing the confirm button while in select socket mode will add the selected socket to the socket list of the currently selected weapon.  Currently, no checking is done to determine if the socket is of the right type (body location or gun).

When in socket selection mode, pressing the confirm (A) button will add the socket at the index of the socket menu to the player’s weapon at the index of the weapon menu.  Again as with the weapon menu, I am assuming that the socket menu is aligned with the player’s acquired sockets.  I went ahead and added another property to the Socket class, which is a code string.  This code will used when displaying the socket on a weapon or armor, since printing the name for each socket on the weapon would take up too much space.  For now, I am just listing the socket codes to the right of each weapon, or “X” if the socket location is empty.  Pressing the cancel button (B) will switch the sockect selection flag back to false, otherwise the player will always be in socket selection mode.

In the player class, I wrote a method that returns if a socket is active.  It takes a socket ID as a parameter, and returns true if it is equipped on a weapon.  In the near future, I will expand this to armor as well.  I also updated all of the code in the Player class which checks for sockets in the EquppedSocket class to use the socket active method.  Now the EquippedSocket class is obsolete, so I went ahead and removed it from the game.

One additional change is that I changed the initial amount of health the player receives to 60 points, which is the same as three bars.  I found that the original amount was way too much, so lowering it should make the game more of a challenge.

http://www.youtube.com/watch?v=U6Wwk8NJk14

Added a new Weapon instance variable to the Player that is the equipped weapon, which is just a pointer to a weapon in the player’s acquired weapon list.  The equipped weapon is initially set to null, which means the player does not have a weapon equipped.

When the equipment screen is displayed, a new ResistorKit menu is created which takes the Player’s acquired weapon names as parameters.  This is a little wasteful, since memory used for the menu object has to be allocated each time the screen is displayed, so there is some room for optimization later.  I’ve also added the damage values as a part of the menu item, so it’s easy to tell how much damage the weapon does for testing.  One enhancement I could make is to automatically sort the weapons by damage value.

I commented out all of my socket code for now, and now the confirm button just sets the player’s equipped weapon to the object in the acquired weapons list at the index of the index of the currently selected menu item.  I think it’s safe to say that the menu items and the acquired weapons list will always be in sync, because it is not possible to add or remove weapons from the list on the equipment screen.  Ideally, I should make the menu accept a pointer to the acquired weapons list as a parameter, and then have a toString type message display the weapon name and damage.  However, I would then lose some of the portability of the ResistorKit libraries, because not all games will have Weapon objects especially not defined the same way as mine.

At the bottom of the screen I now display the equipped weapon in yellow.  I’ll probably end up making the equipment display and equipment select screens separate, but for simplicity I will leave both on the same screen for now.  I still display the list of armor now with defense value, but defense has not been implemented yet.

Now that the player has a way to equip a weapon, I have to apply that value to the projectile.  Thankfully, I already added a damage instance variable to the projectile class.  Therefore, I just have to assign the weapon’s damage to the projectile when it is fired.  One problem is that the player does not start with any weapons, which means the player is unable to shoot.  However, there is a chicken and egg problem here, because enemies don’t drop weapons until they are shot and defeated.  Therefore, I programmatically added a weapon drop to the first room so that the player can equip it to defeat enemies.  This was easily accomplished by calling the dropItem method when the first room is instantiated, passing the first weapon ID and the x,y coordinates as parameters.  In the future I would like to have static items placed by the level editor, which would require the player to open or shoot a treasure chest.  Additionally, I also had to add a check on the equipment screen to ensure that the selected weapon is in the bounds of the acquired weapon list, because index 0 in a zero sized list out of bounds and causes a crash.

One more slight glitch to fix.  If the player is running and then the Start button is pressed to go to the equipment screen, then they will continue to run after returning to the game even if the directional controls are not pressed.

Added new Weapon and Armor classes.  The Weapon class contains an attack value, recoil rate, shot distance, and a List of Sockets.  The Armor class contains a defense value and a List of Sockets.  I have subclassed Armor has for each body location, which are head, hands, body, and feet.  These subclasses currently don’t have any unique properties which may be bad coding style, but I think it is better than having a “type” value in the Armor class.  Plus, it opens the possibility for adding unique characteristics for each armor type.  I also made sure that the instance variables in the Armor class are set to protected so that those are accessible to the subclasses.  The EquippedSockets class has constants for the body parts, but I’m planning to remove the EquippedSockets class once the new Armor system is implemented.  Both the Weapon and Armor classes have an ID variable, which will make it easier for reading and writing save game files.  A cost variable is also included in both Weapon and Armor, which determines how much it costs to buy or sell the item.  The Player class now has a List of Weapons and a List of Armor that the player has acquired.

I also created an EquipmentCatalog class which contains instances of every Weapon and Armor in the game.  When a new weapon or armor is acquired, I’ll probably just clone one of the objects in the Catalog and assign it to the player.  I could have the player’s acquired Weapon and Armor Lists point to references in the Catalog, but that won’t allow the equipment to have unique properties like a Socket list.  I may also want to add a durability value that would be unique to an item instance, which decreases the cost value of the weapon.  Also included in the EquipmentCatalog class is a method to return random Weapons and Armor.  In the future, I’ll probably add parameters so that a random item can be generated within a specified level range for enemy drops.

Currently, I’m using the SI metric prefixes for the names of the weapons and armor.  I’m not that creative, and these names may actually teach the player something educational.  To keep things simple, I’m going to display item properties graphically as bars (or something similar) instead of raw integers.  Therefore, the first weapon will have one bar for attack, recoil rate, and distance.  The next weapon will have two bars for attack.  I may mix up some of the weapon statistics so that each excels in one of the three statistics.  There may also be a bonus for equipping all weapons and armor in the same level series.

While the weapon’s first name will determine the level and attack value, the weapon’s second name will describe the other attributes.  For instance, “Blaster” will be a balanced weapon, “Zapper” will have a higher recoil rate but lower distance, and “Ray” will have low recoil rate and high shot distance.

I also extracted out the socket information into its own class.  Previously, all of the socket information was contained in the EquippedSockets class, but that only allowed one socket to be equipped to each body part.  For the Weapon and Armor classes, I added a variable that tracks the maximum number of sockets that can be equipped on that equipment, and the actual Socket instances are kept in a List for each piece of equipment.  The new Socket class only contains the socket ID, name, and type (body location).

The Collectible class has also be subclassed with CollectibleWeapon and CollectibleArmor classes.  These classes serve the same purpose as Collectible, which is a collectible item on the game screen.  However, the subclass contains one additional instance variable which is a Weapon or Armor object.  When the player collides with the collectible, that item will be added to the player’s weapon or armor List.

Modified the enemy death code, so that a new Collectible is instantiated at the location of the enemy.  The enemy calls the dropItem method on the room object, which takes the drop location as parameters.  The dropItem method uses the random methods in the catalog to get a reference to a random item, which is assigned to the collectible.  Then it adds that collectible to the room’s collectible list.  In the future, I would like to have the defeated enemy determine which item is dropped.  One decision I had to make is the location of the EquipmentCatalog.  The room does not have any references to anything outside of itself, however it needs a reference to the EquipmentCatalog to assign to the Collectible that the enemy drops.  I am now creating a new instance of EquipmentCatalog in the dropItem method, but that will very wasteful of memory since it will need to be cleaned up every time an item is dropped.  I will have to think about this some more.  The EquipmentCatalog may need to be a static class, but I currently have all of the Weapons and Armor defined in dynamic Lists in the Catalog constructor, which may not be allowed in a static class.  I haven’t created graphics for weapon and armor drops yet, so I’m using the standard money drop shaded green for weapons and blue for armor.  The name of the item appears above the collectible on the game screen.  On the equipment screen, the list of all acquired weapons and armor are displayed.  However, I have not implemented the ability to equip those items yet.

Aside from the equipment changes, I added a boolean in the room class that determines if the lights are on in the room.  Only rooms with this value are drawn dark with the radiant value.  There is a slight glitch here, because once the player crosses the screen boundary the whole screen turns dark (including the portion of the previous room that was lit).  I will need to resolve this later to give it a gradual transition from light to dark.