Category: Articles

Added four new body sockets tonight, which increases the player’s health.  Actually, I just had to write the health socket code once and just change the variable that controls the health bonus magnitude.  The player can choose from Health +1, Health + 2, Health + 3, and Health + 4.  I modified the method in the player class that returns the player’s maximum health to account for these sockets if they are active.  Currently, the player can only socket one ability to the body.  I think it’s more important to get it working for one, and then later I can modify the sockets for each body part to a dynamically sized list.  I still haven’t decided if socket slots will be statically bound to each piece of equipment, or if additional slots  can be purchased from an in-game store.

The player’s base health is currently set to 200.  Each +1 health socket adds 40 additional health.  I will need to decide if the Health sockets will stack when multiple body sockets are available.  For instance, equipping a Health +1 and Health +2 socket would result in 120 additional health.  I will also need to handle the case where the player unequips a health socket, which would result in the player possibly having more health than the maximum.

I also modified the health meter display while I was working with the health code.  Now there are segmented bars for each 20 health.  Green bars are health remaining and gray bars are health lost.  I added a variable to the enemy class that indicates how much damage the enemy inflicts, which I now have set to 5.  Previously, I just subtracted a static 20 value from the player’s health when they collide with an enemy.  This way, when an enemy is subclassed, specific damage values can be assigned for the enemy subclass.  The reason I chose 5 for default was because it lets me see the fraction of a health bar left over when the player is hit.  This will need to be rebalanced later, because  40 hits (200/5) seems to be too generous.  Filling the full health bars is easily completed in a loop, but determining how much to fill the last bar which may only be a portion of a bar requires some additional calculations.  Basically, the value of  modulo current health of health unit size (20) is used to determine how much of the last bar should be displayed.

Added the first gun socket tonight, which is the freeze gun.  First of all, a freeze variable was added to the enemy.  I represented this as an integer, which is zero if the enemy is not frozen.  When the enemy is frozen, then that variable is set to the number of frames that the freeze will last.  On each enemy update, the freeze value is decremented if it is greater than zero.

I added a method that returns true if the frozen value is positive.  This is used in the GameScreen class to determine if the enemy should be drawn frozen.  For now, if an enemy is frozen then it is drawn with a blue shade.  In the EquippedSockets class, I created a method to flip the zero gun socket between None and Ice when the confirm button is pressed when the gun is selected.  I’m starting to think about removing the two gun (zero and one) concept from the game, because it may make the game too complex with the socket system.

The projectile class was also updated to include a boolean to indicate if the pellet has the ice attribute.  If the ice gun socket is equipped and the gun is shot, then the ice boolean for the projectile gets set to true.  I created a simple diamond shape in Gimp to represent the ice projectile.  I’ll work on the graphics later, but this will at least let me know if the ice projectile is correctly shooting.

I’m going to leave it at that tonight.  Sorry, no videos this time.  I think I’ll hold off on those until I have something a little more impressive to show.  The ice gun functions correctly and properly freezes enemies, but one change I may make is the ability to land on enemies that are frozen, so they can be used as stepping stones.  Currently, frozen enemies will still hurt the player.

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

Added eight way shooting to the game, so that the player can aim vertically as well as horizontally.  Pressing up will set a flag that keeps track if the player can shoot upward.  When looking upward, then the Y velocity is set to the projectile speed.  If the player is not walking, then the player should shoot directly up, so the projectile’s X velocity is set to zero.  If the player is walking, then the projectile will move diagonally up/left or up/right depending on which way the player is walking.  I don’t have graphics for the player lookup up or down yet, so for now it just displays “looking up” or “looking down” over the player’s head.  One feature I plan to add is making the player aim diagonally up or down when the left or right trigger is pressed.  However, that will require an update to ResistorKit to handle those inputs, as well as adding methods in the ResistorKit screen class.

I went back and modified the velocity for the up/right and up/left shots, since it will actually go slightly faster than the projectile moving directly vertically or directly horizontally.  Currently the projectile speed is set to 10, so that it moves 10 pixels each second.  When shooting diagonally, the projectile will actually move 14.142 pixels according to the Pythagorean theorem ( square root of (10 squared plus 10 squared) ).  To make the diagonal speed match, the values of the X and Y components can be found by dividing the projectile speed by 1.414 (or multiplying by 0.707) which is the square root of two.  This is because Sqrt(1^2 + 1^2) = Sqrt(1 + 1) = Sqrt(2).  Fortunately, finding the length of the two sides (projectile’s X and Y velocity) of the triangle from the hypotenuse just requires multiplying by a constant.  I believe this is because the two sides of the right (90 degree) angle are equal, but I don’t have any formal proof of this.  If I allowed precision aiming where the X velocity was not equal to the Y velocity, then more complex calculations would probably be needed.

The projectile collection class has been modified to handle more than one projectile using a List.  A projectile is removed from the projectile from the List whenever it is inactive.  The alive flag now indicates that the projectile is ready for removal from the collection.  This may be slightly inefficient, since it is allocating memory for a projectile each time one is shot.  I may revisit this later if there are performance issues.  One problem is that I couldn’t just simply increase a counter variable to loop through each element and delete it if it is inactive, since that will modify the structure of the List which could result skipping elements if not careful.  Therefore, I looped through the List in reverse starting at the List size minus one and going down to zero.  That way if I delete an element then it will not effect the iterator.

Similar to enemies, I added code to handle passing a projectile from one room to the next.  I removed the condition that if a projectile hits the room boundary, then it disappears.  One interesting side effect is that now the projectile will live forever if it does not collide with an enemy, so it will loop forever as long as it is in the player’s room or an adjacent room.  Therefore, I added a variable to track the lifetime of a projectile, which I currently have set to  60 frames.  This may be upgradeable in the future with a socket.

Finally, on each projectile update I now check to see if the projectile has collided with a block.  This uses the same collision method that I created in the map class to do the enemy collision.  If the projectile has collided, then I set the alive flag to false, which will mark it for removal from the projectile list.  I also added the player’s width to the starting position of a projectile when shooting right, that way it doesn’t look like the projectile is going through the player’s body.