Levi D. Smith

http://www.youtube.com/watch?v=sH-Juho6Kqs

Now with doors and level changes.

The latest build now contains many more improvements.  I created a Door object, which represents a door which will take the player another level.  An array of Doors is contained in the Map object, but I doubt I’ll ever have more than one door on a map.  However, I may have multiple doors in a level, and each door will take the player to a different level.  A World class has also been created to keep track of all the levels and the current level.

 

A method to determine if all of the enemies in a level have been defeated has also been added.  When the level is cleared of enemies, the message “DEFRAGMENTATION COMPLETE” is displayed.  At this time, all doors in the level will be unlocked.  For now, this is visually represented by the door changing from red to black.  At that time, if the player collides with the door then they will be taken to the next level as determined by the World object.

On the player class, I added a method which translates the player’s screen coordinates to the room coordinates, since calculating that value each time when needed became confusing.

In the enemy class, the binary code for each enemy is now randomly generated.  At first, I was getting the same binary code for each enemy, since the Random object was declared as an instance variable for each enemy.  To get random codes for each enemy, I had to make the Random object static so it is shared between all of the instances.

One problem that I need to fix is when the player shoots and moves across the room boundary.  In that case, the projectile isn’t associated to a room, so warps over to the next room.  Additionally, I need to work out the issue with the bock collision when moving across a room boundary, which usually pushes the player back a noticeable amount.

I did some web searches, and found there is already an academic game called Binary Blaster.  I’m not sure if that is an official trademark or registered copyright, but I don’t want a legal fight so I am going to change the name since it is still early.  Now the working title is Blasting Bits, which was the heading from my previous post.  Binary Blaster is catchy, but people could also confuse it with a game called Blaster already on XBLIG.  Also, it may be a little too similar to Blaster Master for the NES.  I also like the word Blasting in the title, because it is more of an active verb which makes it seem more exciting.

http://www.youtube.com/watch?v=93qzG6ulogQ

Updated map flipping, fixed offset collision issue, added title safe overlay image.

More Bounds Checking

Noticed that the right bounds wasn’t symmetric with the left bounds.  I had 200 pixels for each bounds, but forgot that I needed to subtract off 48 for the right bounds to account for the player’s width.  This set the right bounds at a location that was not a multiple of 5 (1032 = 1280 – 200 – 48), which caused problems since the player’s walk speed is 5 pixels.  Thefore, when the player’s location and velocity passes the right bounds, then I have to calculate the difference between the bounds and the new location.  I set the player’s location to the right bounds, and add the difference to the level scroll offset.

The flipping between maps was working really well, but I forgot one case which is really noticeable when it happens.  I am only checking for map flips when the player is at either the left or right bounds.  However, it is possible for the player to backtrack and cross the boundary between rooms, when the boundary in the middle of the screen between the two bounds.  However, this is fairly simple to calculate.  If is between the two bounds, and the player’s X position is less than room offset, then flip back to the map on the left.  If the player’s position and the negative offset are greater than the room size, then flip back to the map on the right.

Title Safe Overlay

Found a nice PNG layover on the XBox Creators Club forums which shows the title safe area for a 1280×720 screen, which can just be drawn over the game screen, since the center of the image is transparent.

Collision Offset

Since the player falls at a rate of 5 pixels per update, there is a small problem when the user falls to the ground which may not be noticeable.  Since the tiles are not multiples of 5, then the calculation of the next fall frame may indicate a collision and the player should stop falling.  However, this will cause the player to stop at the multiple of 5, which may be a few pixels above the actual ground.  This is not really noticeable until the hit box is drawn around the player graphic.

This is also a problem when running into blocks, since the player runs at 5 pixels per update.  Turning up the run and jump speed to a higher value (like 20) makes this issue more noticeable.

 

   

To fix this, I went ahead and updated the player’s location to the block boundary in the collision method.  Originally, I just had the collision method return true or false, based on if they have collided with a block.  Updating the player’s location in the collision method probably isn’t the best programming style, but I really didn’t feel like calculating the number of offset pixels, making new variables, and passing out the number of offset pixels to the calling method which is bad style in itself.  Probably the most elegant solution would be to return a Vector (x, y pair) containing the number of offset pixels, or null if the player has not collided with any blocks.