Category: Articles

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

Each collectible adds 50 to the player’s money.

Collectibles are very similar to enemies.  An array of collectibles are assigned to each room.  Each collectible has an x,y position and a height and width.  Also, each collectible has an animation frame, which I have set to loop from 0 to 30.  I created a simple collectible model in Blender, which rotates in 30 frames.  Actually, it rotates half way every 30 frames, but it should not be noticeable since the collectible is symmetric on the Y-axis (at least I tried to make it that way).  What makes a collectible different is that projectiles don’t collide with collectibles, and collectibles have a value that gets assigned to the player when the player collides with the collectible.  Unlike an enemy, the collectible “dies” when the player collides with it.  For now, my simple collectible will add money to the player when acquired, but my collectible can be extended later to produce various types of effects.

Handling collision detection for collectibles was also very similar to handling collision for enemies.  I created a method in the Player class which takes the room collectibles as a parameter.  It loops through all the collectibles, and if the player collides with one then it adds 50 money (I’m calling FLOPS) and sets the collectibles “alive” flag to false.  I made one change in the structure for a collectible, where the location and size are contained in a Rectangle object.  For enemies I used two Vector2 objects for position and size.  The major difference is that the Rectangle uses all int values and the Vector2 uses floats.  The int values makes coding a little easier, since the floats have to be casted to int values for storing those values in a Rectangle object for calculating a collision.  I could write my own collision method using floats, but the Rectangle “Intersects” method seems to do the job well.  Finally, I had the World call update on all collectibles in the current room and two adjacent rooms, so that the animation frame value increments for each frame.

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

The level editor now allows a map to be saved and loaded.

Began pulling the code out of Resistor for saving game files for my ResistorKit library.  Saving files is much more trickier than just opening up a file handle and writing out a string.  This was probably the most time consuming task in Resistor that produced the smallest results.

The three file IO methods I’ve included in the ResistorKit are beginLoadGame, saveGame, loadGame, and getLoadData.  The beginLoadGame method should probably be renamed, since it just does the processing necessary to get a storage device.  This method must be called and complete before the other two methods are used.  The saveGame method takes three parameters, which are the container name, file name, and data string.  The container name is basically just a folder created in C:Users<username>DocumentsSavedGames on Windows.  On the XBox, this is the name of the save on your storage device.  The file name is the name of the file to write out in that folder on Windows.  On the XBox, the user should never actually be able to see the file name.  The loadGame method takes two parameters, which are the container and filename.  After the loadGame method is finished, the character string data from the file can be obtained by calling getLoadData.

In my Level Editor screen, I have assigned beginLoad game to the X button, saveGame to the left bumper, and loadGame/getLoadData to the right bumper.  When the data is saved, it writes out the array of 1’s and 0’s to the text file.  I wrote a method to serialize the data from the array to make this task simpler.  When the data is loaded, the text data is stored in a variable which is displayed to the screen.  Conversely, I wrote a deserialize method which takes the loaded text data and populates the map array.

I’ve also decided to keep one save file for all players.  Saving for a specific profile caused problems with Resistor, so I’ve learned that making one global save file is the much easier approach.

http://youtu.be/r13UWoifors

The player can now slide to get through narrow areas.  Enemy graphics have been updated and collision detection improved.

Sliding

Modified the controls a little, so that pessing down now causes the player the crouch instead of crawl.  When crouching, the player cannot move.  I also went ahead and added 48 to the player’s Y position when crouching, so it doesn’t rely on the automatic fall to hit the ground, which previously made it look like the player was hopping.  Pressing the jump button while crouching will now cause the player to slide, which accomplishes the same thing as crawling to get into one tile high holes.  The difference is that the player doesn’t need to press the directional stick to move in a slide.

Keeping track of all the states when sliding can get confusing.  If the player is crouching and presses the jump button, then the slide flag gets set to true, but is the player still crouching?  If the player is not still crouching, then the crouching flag gets sets to false, but that means the player will have to press down again to crouch and slide, which doesn’t feel right.  Therefore, the crouching flag has to be kept set to true while sliding.  Normally, when the player is crouching, they are not allowed to move, so I had to write a special case for not crouching and sliding.  This way the player can hold down, and then repeatedly press A to keep sliding without having to press down again.  After some testing, the slide is now working correctly when the slide ends under a block that would cause a collision when standing again.  The player simply keeps sliding until they are not under a block.  The player can also press left or right to keep the slide going indefinitely as long as they are under a block.

One other slight annoyance is that the player cannot go to the crouching state while falling.  I will have to figure out how I want to handle that later.

Came across another problem, when pressing down again while sliding.  This would count as a second crouch, which would push the player into the ground.  I just had to add a check for not sliding in the set crouching method.

Also noticed an issue where the player could get themselves stuck in a block by continually crouching and then walking towards the block.  This only happened when next to a block one tile high.  I found that I was setting the player’s size in the update method, instead of in the set crouching method.  Setting it in the crouching (and sliding) method next to the line which updates the player’s position resolved the problem.

Enemy Update

Created a simple enemy model in Blender, which is a sphere with a cylinder through it.  I created a armature just like I did for the player, so that I was able to generate an animation of the model spinning.  After that was done, I generated all of the PNG file for the animation.  This time I used 30 frames, so it should rotate once for every half second.

I went through the same scaling and cropping process in Gimp.  This time I set the height to 48 pixels, which makes the sprite wider than the bounding box.  I think this is okay, and I just offset the sprite by the cylinder arm size when drawing it, so that the cylinders are not considered part of the hit box.

Modified the Gimp python script a little more to give the exported PNGs more meaningful names (than 0001.png).  Unfortunately, this means I have to update the script each time I want to perpend a name to the file which is a real hassle.  If I had the time, I would figure out how to make an options dialog box for the script to allow the user to enter the file name.

I created a new folder in the content folder area of the project specifically for holding the enemy animation images.  Again, I’m not using a sprite sheet because I don’t think it really improves performance that much.  However, it is something I can look into doing in the future.

To keep the enemies from floating in the air, I wrote some code in the enemy update method to make the enemy fall if they are not colliding with the ground if moved down by one pixel.  Unfortunately, this means I now have to crouch to shoot the enemies now.  I can balance that out later, or make enemies taller than one tile.  Also, I made it so that if an enemy collides with a block in the X direction, then it’s X velocity is flipped (multiplied by -1).  I also increased the range that the enemy can move in the room.  However, one issue I noticed is that if an enemy does move to the next room, then it will fall through the floor (since no block collision is performed outside the enemy’s own room), resulting in the stage becoming uncompletable, since all enemies have to be defeated to move to the next level.