Category: Uncategorized

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.

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

Crawling implemented with some slight glitches and background parallax fixed.

Background Scrolling

Fixed the parallax problem at the room boundary by making the background image 192 pixels wide instead of 256, because 192 is a multiple of 48 (tile size) and 256 is not.  Later, I still want to go back and add some transparency effects for the background between two rooms, just in case I want to have rooms with different backgrounds.  However, this results in 6.5 background tiles per screen which leaves me with the same problem of the background image not aligning to the room size.  I would rather not reduce the background image to 96 pixels wide, because it would make the background tiling really noticeable.  After doing some calculations, I found that the room size (1248) is divisible by 156, which would make the background image repeat 8 times for an image 156 pixels wide, so I went with that size for the background image width.

Map Drawing

Created a new method specifically for drawing a room.  Previously, I had separate loops for drawing the blocks of each room, but only drew the enemies and doors in the current room.  That is why those would disappear as I crossed the room boundary.  With the enemies and doors (and eventually projectiles) drawn in the room draw method, those no longer disappear, because I always call the map draw method for the room to the left and right of the current room.  This did uncover another issue, which is that the enemies are not updating (moving) when the player is not in the current room.  Therefore, in the game update method I now call update for the enemies and projectiles in the adjacent rooms.  True to NES game fashion, I’m not going to bother updating enemies more than one room away.

Crawling

I added crawling to the game, which allows the player to go into spaces that are only one tile high.  When the player presses down, then a crouching flag gets set to true if the player is not jumping or falling.  When this is set, the player’s bounding box size gets set to 48×48 (previously 96×48).  The first time I tested this, I was surprised that the bounding box was correctly aligned to the floor, instead of floating in the air since I didn’t update the player’s Y position to account for the crouch height.  However, I realized what was happening was that once the player crouched, then they would fall to the ground to account for the 48 pixel vertical gap that is created when the player crouches.  This worked fine, but when the player released down the crouching boolean gets set back to false and the bounding box is set back to 96 pixels high.  Since the player’s Y position was not modified, this resulted in the player being stuck in the ground.  For now, to fix this I just subtracted off 48 from the player’s Y position when they release down (go back to standing).  This seems to work well, unless there is a block above the crouch position, which will cause the player to rise through the block.  I will need to add a check to see if the player will collide with a block when going from crouching to standing, and if they do collide then keep the player in the crouching position.

I fired up Blender and moved my simple model into a crouching position, then I exported the image which I scaled and cropped with Gimp.  One other problem is that the player’s sprite is much wider (94 pixels) than the bounding box’s width (48 pixels).  I centered the sprite horizontally on the bounding box, but I’m going to leave the overhang for now.  I could go back later and make the bounding box when crouching 96×48, but I think that could result in the player getting stuck in some instances if not careful.