Apologies

Unfortunately, I won't have regular access to Internet soon. Fortunately, I will still have my laptop with me, ensuring my continued work on blog posts. I do apologize for the lack of posting. We have finally reached the point where the blog and my personal work on the project are almost the same. Coupled with me having to rewrite a lot of code due to some mistakes and it has taken longer than I thought to update. Thank you for your patience, and your time.

9: Bug Busting

I'm sure the one or two of you fans are excited to get to the inevitable next part, attacks. Unfortunately, at this point, my chief bug tester and I found a few bugs, one of which stuck poor Tanner in the floor. Bugs are inevitable in anything you code, and plenty will exist in your final product. Being an indie game maker, people will typically look over your mistakes, but taking the time to fix bugs adds a excellent polished feel to a game.

I understand that we've just started the game, and it is only natural wanting to get farther, but bugs are always easier to remove the earlier you find them because there is less code to slog through. So what are these bugs I'm talking about? Aside from one particular bug I purposely left in, most of them are not in the code I've been providing, but I would still like to go over them to show what kinds of mistakes can happen.

The worst bug we found was Tanner getting stuck in the floor. When falling at just the right speed and height, Tanner would end up buried into the ground, and wouldn't be able to jump out of it. I'm still not entirely sure how exactly this glitch happened, but after I noticed and fixed up a few smaller mistakes in my code it went away. The biggest mistake was this embarrassing piece:

// Gravity check
if place_meeting(x,y+vspeed,obj_floor)
{
     vspeed = 0
     move_contact_solid(270,vspeed)
etc


It's always a good idea to use a variable for something right after you reset it (note: sarcasm). Again, I'm not the proudest of this blunder, but I would rather a bug come about because I mistyped something than my code just not working overall.

The next bug is something a lot less obvious to find, but a lot easier to fix. In this case, when just mashing the jump button to see if I could find a bug, I noticed that Tanner would do a sort of triple-jump. Basically, when I tapped jump just before touching the ground, he would jump in air, but jump as high as a normal jump. What was happening? Well, first thing to note is that the original code was arranged so:

gravity code
jumping code


If you think logically, you might be able to piece it together. Tanner isn't actually triple-jumping. He is moved to the ground with move_contact_solid(), then immediately jumping within the same frame. In other words, he moves downward, then upward in the code, but only moves upward onscreen. The fix is simple:

jumping code
gravity code


Changing the order removes the possibility of this happening. Now the player can only jump when he can visually see Tanner touching the ground.

The last bug is is mainly asthetic, but it looks terrible. This bug is actually present in the code I've provided. It only became noticeable when we added the animations. Whenever Tanner touches the ground, his graphic glitches slightly. Now it is time to put debug mode to the test. Try testing the game in Game Maker (this doesn't work with just the exe), but this time in debug mode. One of my favorite features of debug mode is the "Set Speed" command.

I typically set it to 5 or 10 when I want to see what is happening frame by frame. Do this, and then jump. When Tanner lands, he goes into the standing animation like you would expect, but for a single frame, he switches to the falling graphic. It has nothing to do with our animation code. If you use the debug functions to watch the variable inair, you'll notice it turns to 1 for a single frame after Tanner lands. The fix for this is small, but how do we figure it out? Just try and think through everything logically.

We know that when Tanner lands, move_contact_solid() places him onto the floor. It also sets the inair variable to 0. Apparently at this point, the code sets inair back to 1, and then to 0 again. It only changes in the gravity event, so it has something to do with that.


if place_meeting(x,y+vspeed,obj_floor)
{
     move_contact_solid(270,vspeed)
     vspeed = 0
     doublejump = 1
     inair = 0
}
     else
     {
          vspeed += 2
          inair = 1
     }


The only way inair returns to 1 is if the place_meeting() check fails. This is where I figured it out, so I'll lay it out completely.

Tanner touches the ground, and the gravity check does it's work. Afterwards, vspeed is set to 0, and Tanner is placed just above the floor. When the check is made again, it tests if Tanner would collide with the ground by checking his current position, and adding vspeed, which is zero. Since he isn't actually touching the floor, this means for that single frame, the game assumes Tanner is in the air and moves him 2 pixels downward. After that, the code works fine because Tanner is actually inside the floor at this point.

How do we fix it? It seems really minor, but it works.

if place_meeting(x,y+vspeed+1,obj_floor)


If we simply add 1, the game will check just underneath Tanner's feet even if vspeed is 0. Now the glitchy effect no longer happens.

Next time, we finally let our hero swing his sword around. The horrors await!

Also, I'm not posting the gm81 or exe file this time. I added two characters to the code.