> | | | | | | | > Moving Beyond the First Milestone

Moving Beyond the First Milestone

Posted on Friday, July 20, 2012 | 2 Comments

Okay, well, maybe it wasn't quite a milestone, but the demo I linked at the end of last post (here) was my first significant achievement in this project.  The game at this point has already surpassed my built-from-scratch capstone version (Flixel is just amazing) and this is the first time in the development process that it actually sorta resembles the kind of tile-based game that I am trying to make, at least visually.  Even though the demo is largely uninteresting, I was extremely excited at what I had accomplished.  Unfortunately, victories like this are always short-lived because there's always more programming to be done.

I wasn't sure what to start working on next, but I eventually settled on bug-fixing.  I figured that it would probably be a much better idea to fix whatever bugs are in the code as it is now before I start adding more code that has potentially more bugs to fix, otherwise things might start getting out of control.  Thankfully, this early on there are hardly any bugs and they aren't really even worthy of being called bugs.

Actually, there was only one bug I fixed in this version.  If you hold the spacebar down, you will continuously jump again each time you hit the ground.  This is undesirable behavior for a video game, so I had to fix it.  My solution was to create a boolean variable, which I named "holdingSpace", and use it to control access to the jump code.  Basically, the jump code checks to see if "holdingSpace" is false before running.  If the jump code runs, "holdingSpace" becomes true and stays that way until the spacebar is no longer being pressed.  The end result is that you can no longer hold the spacebar down and continuously jump!

That was an easy bug to fix, but usually bugs are much more tedious to deal with.  FlashDevelop, which is the software I use for programming Flash games, comes with debugging tools to help you fix your bugs.  One of my favorite features is the ability to add breakpoints into your code.  As long as you are testing your project in debug mode, a breakpoint will pause the program at the exact spot the breakpoint is located.  Once you learn how to use breakpoints to your advantage, bug tracking becomes a lot easier!

Let's say you have a bug where, if your player sprite overlaps a sloped tile, you ignore normal collision code and run special code for colliding with sloped surfaces.  Instead of landing where you want, though, the player sprite just glitches around through other tiles until either the program crashes or the player sprite is in a non-bugged location.  Pay attention, because sloped tiles are common in tile-based games and if you plan on making your own tile-based game in Flixel, you're gonna have to figure out how to implement slopes.

By using breakpoints and trace statements you will have a much easier time trying to figure out just the heck why your player sprite doesn't land on sloped surfaces properly.  You can slip a breakpoint into your code at the exact line that runs or is supposed to run when the player overlaps that sloped tile.  When you're testing your game, if you go try to jump and land on a sloped tile the game will pause at that breakpoint so long as the line of code it's attached to is run.  You can also string breakpoints together and the program will pause at each breakpoint, allowing you to check different parts of a bugged behavior.

Make sure you put your breakpoints in the right place.  A breakpoint needs to be on the exact same line that you want to check for, so don't put a breakpoint above a function on a comment line thinking it will pause for the whole function.  Here is what you want to avoid:

A poorly-placed breakpoint in FlashDevelop.

As you can see, the breakpoint is on the same line as a comment.  Comments are ignored by the interpreter and no code is run on this line, therefore the breakpoint is also ignored.  Here is an example of a properly-used breakpoint:

The correct usage for a breakpoint in FlashDevelop.

This breakpoint is on a line with actual code, so the program will pause once this line of code is about to run.  Also, you can see part of a trace statement I used; I precede and follow the statement with several equal signs so that it sticks out in the debug window.  I don't do this with all trace statements, just the ones I really need to be able to see in the debug window.

If you have your trace statements set up properly, you should be able to figure out what's going on just by observing the behavior of the bug.  Keep testing small things so that you can rule them out as a possible cause of the bug and add in extra trace statements to track variable values whenever you need to.  You can also use trace statements to indicate whether or not a function/method was run.  In the example above, you might want to isolate certain variables and make sure that they're getting updated properly or you might want to double-check that a certain function or method is being called when it's supposed to.

You may have guessed by now, but slopes are what I have been working on most recently and let's just say breakpoints and trace statements are my close friends!  I actually have working slope code for 45° and 22.5° slopes, but the only problem is I haven't yet written working code that determines what happens when the player lands on a slope.  I actually considered switching from Flixel to Flash Punk once I learned that there was no official support for sloped tiles (and the unofficial modifications aren't quite right), but I really didn't want to have to port my code over and tinker with it for a long time just to get back to where I was.  Besides, I really like Flixel, so I decided to stick with it!

Aside from the spacebar bug fix, I didn't do much else for this release.  I believe I mentioned the GUI last post or maybe the one before, but I actually implemented it in this release.  This is when I had to futz around with the FlxTilemap and FlxCamera settings because I moved the map down to make room for the GUI.  I also made a new level for this release, which I used to sort of test how big of a jump can the player make and other kinds of preliminary game mechanics like that.  You can check out the second release here.

Well, I am out of time for now, but I will probably get another post up by Sunday evening.  The third release has a lot of modifications compared to this one and we're starting to get into more complex (and more interesting) stuff, so there will be quite a bit of discussion next post.

See you next time!


Powered by Blogger.