LD Smith Games

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.

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

Attract screens included and parallax background added.

Story

Created a simple story about having to save the world from cyber terrorists who have hacked the global network.  Created an attract screen which cycles through the four story screens that I have created.  Created some really simple graphics in Gimp, which I hope to improve later.

Updated the title screen with a simple title logo that I created with Gimp.  Added logic to the title screen to use the user created world if it exists, or generate the default world if no user created world exists.

Parallax

Added a simple scrolling background to the level.  For now, I just used one of the images that I created for Resistor.  Added a parallax effect by offsetting the background image by the room offset divided by two.  That means the background is scrolling at half speed of the room.  When creating the background image, the grid option in Gimp really helped with placing the background images, which were placed over a blue to black gradient.  I could have set my background image as a pattern and used bucket fill, but that would have been more effort than needed.  My Gimp toolbox kept disappearing for some reason, and getting it to show again with the tool options was really a hassle.  Once I got the background image added to the game, there was a noticeable jump that occurs when the player crosses rooms, which will need to be fixed later.  I’m thinking about copying all of the room data to one huge array, which would solve a lot of problems like that.

Gameplay Changes

Added a check in the draw method of the game screen to determine if the player is facing right.  If so, then the player sprite is flipped horizontally.  This throws off the baked-in lighting, but it is good enough for now.

Modified the player’s jump speed to 10 (pixels per frame) instead of 5, which makes the jumps feel less floaty.  Still need to add some calculations to make jumps more parabolic and less linear.

Realized that the player’s health wasn’t getting re-initialized after dying and starting a new game.  I went ahead and created a newGame method in the game screen class which handles things like that.