A few new sprites were added to the game today. They aren't of anything exciting. They are mostly replacement images for debugging text that I had floating around the screen all over the place. I added some nice looking health bar images along with the code that updates them to reflect the current amount of health of the player and one other entity in the game. I also added a sprite of a "combo holder." It's basically just an image that looks like a piece of wood or plastic that has slots in it to show a representation of a current list of the last few items you have killed. I can't really get into any more detail than that without giving too much away.

I did a bit of housekeeping with my files and organized my whole sprite directory structure. Up until this point there were simply folders for each different sprite, but contained within that folder were bitmap/photoshop/pixen/gif/jpg versions of that sprite all over the place. I added appropriate subfolders to house each different type of image. Wonderful! In the process I also gathered some nifty information about my project.

The total number of files that comprise my project (this includes all "working" files (concept art and screenshots, music that isn't used, old datafiles that are now obsolete, backups, etc). The project is a whopping 750 files that takes up about 300mb of space. What I found more interesting was the information regarding my source files. The project is comprised of 75 source/header files which span 11,000+ lines of code. Of course, this code line-count includes blank lines as well as comment lines. Even so, that's a lot of code! I was really surprised to learn that my project has grown so large! I'm not sure whether I should be proud, or worried. I don't want my project to be inflating to a size that's impossible to manage. I may try condensing a few files and weeding out unnecessary code/comments in the next few days.

I did a bit of marking off on the todo list today. There were a few items that were easy to update that I just hadn't got around to doing. A bunch of them are done now. One of them included a redraw of a part of an enemy to fix a visual looking issue with placement of the enemy part in conjunction with another enemy type. I went ahead and tried to draw a new sprite for this piece of the enemy, but no matter how many different ways I tried, the original just came out better. So, instead of drawing a new sprite, I modified the original a bit.

Something I didn't fix yet which is related to redrawing that piece of the enemy is using hardcoded values to make everything appear "in place" when it's on the screen. Currently I am doing this is using privileged information of knowing the size of other sprites in the game before hand. This is something that needs to be fixed very soon. I don't believe it's a very difficult thing to do. I want to prevent making accessor functions for an object's sprite information, so I'm leaning towards having these "other objects" simply be able to give out their width and height information. There may be implications involved in doing so, therefore I'll have to go through my code a bit before I decide to take this action. There are a bunch of other areas in my code that are like this: needing to have hard coded test values removed and replaced with good function calls to offer the ability to be dynamic. I'll be removing them as time goes along and I am able to find solutions to prevent having to use the precalculated-ness that it currently uses.

I also added a nifty new feature that they player can use: dashing! Hitting the left or right key twice, in rapid succession, will allow the player to dash on the screen, doubling his/her speed for a short amount of time. I ran into some big problems when first trying to implement this. Registering a "double tap" of a key is a bit tricky. I could have, instead, just had a single button that would use dashing but I thought it would be much more fun to require a double tap in the direction you want to dash in. This requires using a few flags to determine what state the keys are in. First, you need to know if the key is initially pressed down. Then, it's necessary to know that it was released. After that, you need to know that the key was pressed again, for the second time. All of this has to be timed, too. The key must be pressed, release, and pressed again within a certain threshold! If the time goes up, then the player must start over. It doesn't seem so complicated when you're just thinking about it; but adding it into preexisting code is a bit tough. There needs to be separate cases for dashing both left and right; to prevent something like tapping left and then right very quickly to then start a dashing sequence.

I initially set up the dashing so that the key need only be released and repressed within the time limit, which was a silly way of doing things. With this set up the player could effectively be running in a direction, let go and retap that direction quickly and then be able to dash again. This produced unexpected results when dashing a lot. Sometimes you would be in a state where it would appear that you should double tap the key to dash but in effect only had to tap it once and dashing was enabled. I went about making the change so that the button had to be pressed down, released, and pressed again all within the time period. What I didn't notice, however, is that my code for increasing the amount of time that has passed since the initial keypress would only be executed if the player was not moving left or right. It took me a while to figure out why the timer wasn't increasing. I had this thought in my mind that I was somehow resetting the timer back to 0 each loop, but that wasn't the case. Once I finally realized the errors of my ways and moved the timer incrementing code outside of the "player not moving" section of code, everything worked fine. Dashing goodness!

I'll be playing around with the dashing a bit more to make sure it works effectively and doesn't feel strange. I'll more likely than not be making some tweaks to the amount of time you have to double tap a key.

I did a bit of work regarding the "secret stuff" that plays with my combo manager. In the process I managed to shift around a bit of my data and bumped into a rather nasty bug. As I have already stated, my combo manager shows a nice little display of how large a "combo" is when a streak is broken. Completely unrelated is the combo manager's ability to keep track of some other enemy specific information which I stored in a basic array. What I hadn't noticed is that, while using a for loop to iterate over the array backwards, I initialized my counter variable to the size of the array, and not the actual cell position (which would be the size of the array minus one). Strangely enough, I didn't get any out of bounds errors. What it ended up doing was resetting the variable that kept track of the combo amount to -1! Absolutely frustrating. I spent an extremely long amount of time pulling my hair out over something quite trivial. It's especially frustrating when you know it's something very small and trivial but simply can't find it. It's times like these when it helps to take a break from trying to find the solution for a bit.

After a few minutes away from the issue I was able to come back to it in a different mind set and finally found the mistake I had made. I was a bit set back from a few of the things I wanted to do today because of this error. It's nothing that can't be accomplished any other day, though.

I've been out of touch with my pixeling skills lately. Anything I've created to be used in the game in the past month was all whipped up in a matter of minutes to simply be used as a place holder. I really feel as if I should take a day or two to spend on at least fixing up the current state of the art in my game to make it look more presentable than it is now. Hopefully I will be able to take some time out from programming and get into the pixeling mind set soon.

There's a bunch of news to report today. I added a new font to the game that is used (currently) for displaying a "combo" number to the player after the combo has been broken. Each time the player destroys an enemy of a certain type a counter is increased. Once an enemy of this type "slips by" without being destroyed, the combo is then "broken." There were a few code additions required to my combo manager class to get this to work the way it does now. There are a few more things I added to the combo manager class that I can't divulge at the moment. Doing so would give away some juicy information about the game. Lets just say that this "secret" stuff is in its beginning stages at the moment. I'm still doing some thinking about the code design and whether or not I will split it up between multiple classes or have the combo manager class to take care of it all. I'm leaning towards having multiple, smaller classes that can each handle their own individual aspect of what this secret stuff has to do with the combo manager. Onto more stuff I can actually tell you about.

I fleshed out a more advanced behavior for one of the enemies, complete with sounds and animations. At this point in time it's a rather, literally, random (10% chance each logic loop) that the enemy executes this behavior. The thing that is especially nifty about this behavior is that it affects other enemies on the playfield. The animations are rather terrible looking but suffice for the moment to get the desired effect across. The sounds go hand in hand with the new animation being just as mediocre in quality. All of this will eventually be upgraded in due time. The code that actually uses the animations is pretty dynamic and won't need to be changed much unless the core concepts behind how these advanced enemy behaviors are changed themselves.

As for the minor Windows bugs, I haven't done any work with them so far. I've been having too much fun adding in these new things that give me visible results and change how the gameplay actually works. Even in its rather incomplete stage, it's fun to be able to add in some new things and play my game to see how everything works.

Most of the score tracking class is now complete. I added integration into the main game systems including all enemy types, save one. To do this I needed to add score value information in each of the enemy classes, which was quite simple since they all derive from the same base class. I also implemented a score multiplier dependent on combo amounts. All of the actual numbers involved will be changed in the future once I make a few decisions about the "level" layouts in the game. Currently the score is displayed on the screen and increased each time you destroy an enemy. I haven't linked the score manager class with my high score class. I'll save this for when I have the time to make a proper high score viewing screen of some sort.

In addition to that I spent a good chunk of time today doing a test port in the Windows world. There are two bugs which need a bit of fixing. One deals with setting the executable's working path. This shouldn't be too difficult to fix. Another error is something that GDB spits out at me when I run my program. Apparently it thinks I'm doing something to a piece of memory that I shouldn't be. This is strange, however, as when I run the game through GDB on my Mac it doesn't catch anything. This seems a little weird but is something I can look into with a bit of ease. I already know which specific chunk of code (down to a specific line) that can cause this error to happen or not.

I added the foundation of score tracking to the game. So far I've build a class with a few generic functions that will add to, reset, and return the current score value that the player has accumulated up to some point. I haven't had the chance to actually use it in my code yet. Once I've added in the basics for score keeping I have a few things I'd like to get done. First off, all of the enemy types need animations very badly. Whether or not I'll do a "good job" on them (read that as: draw enemies that don't look like animated stick figures) is still up in the air. After that, I need to code in a lot of their behavior. Currently only one enemy type actually moves around on the screen in relation to the player. Every other enemy type just sits around doing nothing. I want to change this very soon.

I also did a little more concept art and came up with a new title screen to replace the old (and now obsolete) version. I don't plan on spending an inordinate amount of time on the title screen as it's something that may have to be changed very quickly, but I'd at least like to have a nice background slash screen, if anything.

Through playing around with my text bubble stuff recently it came to my attention that I really needed some custom fonts. Naturally, I went ahead and scoured various resources for some freeware fonts that I could use in my project. Since I always end up having to go searching for fonts at one point or another I simply grabbed as many as I could get my hands on. After downloading, literally, hundreds of fonts I decided it was time to nail things down once and for all and create Allegro FONT compatible pcx files using the ttf2pcx tool. Of course, you may be wondering why I'm crazy enough to waste my time on such a thing when font libraries already exist for Allegro? Well, maybe I am a little crazy, but I like to use Allegro's built in text routines. One of these days I may eventually upgrade to a system that uses native TrueType formats (and also upgrade my text bubble class to utilize it), but for now it's the built in text routines for me. I spent an inordinate amount of time dumping pcx files for each font in various sizes. Obviously I didn't bother to check whether they were being output correctly. After dumping about 300 of these files I finally went ahead and checked out one of the pcx files. It was empty!

They were all empty! I had just wasted a huge chunk of time using the wrong version of ttf2pcx (sidenote: if you don't already know this, there is a special version of ttf2pcx required for Windows XP. The original version of ttf2pcx dumps out blank entries when used under WinXP). So much for that! To make things a little less stressful, after grabbing the correct version of ttf2pcx, I simply picked out a few choice fonts I can work with for now in my project. I'll be saving creating a master set of pcx files for another day. The few fonts I picked actually look very nice when used with my text bubble system!

To add a little more to the list of things accomplished (or not) today: I created three new conceptual pieces of artwork. I'm quite pleased with the results for the amount of time I had to put into them. These images are going to be used in the game for now as placeholders, until I can either take some very serious time to make a better looking version of them or when I find an artist (or when an artist finds me); whichever comes first. :)

I had to make use of my PackTools today and I noticed something terrible: they're broken! The new, fixed, version 0.2 is now available for download. I made the mistake of assuming that a variable passed to a function would be update for use outside of that function. This is a big no-no, because that definitely does not happen. I fixed up this issue as well as changed around how it creates the default configuration file. It's nice to find a bug and fix it in the same day.

In the "current project" world I started making serious use of the text bubble class I created a while back. There were a few issues with using it, however. One easily fixed bug was that the bubble wouldn't allow the user to specify a height that might be greater than the auto-generated one. For instance, if the text within the bubble created a height of 300, the user wouldn't be able to specify a height of 350 and have it actually do anything. I fixed this up with a quick check between the auto-generated and user supplied height, and using whichever is greater. I added a nice addition of being able to choose a tiled background or a stretched background for the bubble image, as well. In its first stages there was only a "stretch" option available. This, of course, wasn't the best solution for all background image styles. Being able to tile the background is a wonderful thing, indeed!

I ran into all of these "issues" while trying to accomplish one simple task: display a message on the screen from a compressed allegro packfile that existed on the hard disk. I had to take the long road around to get there, but in the process I fixed up a lot of broken stuff. Now I can get back on track with displaying these messages in a fancy manner.

I recieved a bit of feedback on my tutorials and have updated them to add a few fixes. While doing so I noticed that the downloadable versions of the source code didn't match half of the online tutorials! That said, everything is now updated. The source code now matches the tutorials and all sorts of minor fixes were added to both versions of the tutorial. The downloadable version has been updated as well.

Anyone who has emailed me in the past week will have noticed that their email bounced back with a "Quota limit reached" error. I just realized yesterday that something was up with my email. Apparently my hosting did an update of the control panel for its customers. Supposedly there is some bug in the update that resets mailbox quotas to 0 instead of leaving them at the setting they were at before the upgrade. That said, the issue is fixed: my quotas are now back to their original limit and I can receive emails fine now. Please resend your message if you received an autoresponse from my mail server.

After a little bit more code retooling in respect to the "bunches of objects that assumed way too much about eachother" I was able to get the game working in just about the same exact fashion it was before I started fixing things up, minus a few minor details like object positioning at creation time. I also have a core framework for my combo manager class now. There is still a bunch of stuff to be added to the class in regards to specific combo information, but the general combo "tracking" is implemented. An interconnect has been made between this new class and the already existent class which handles drawing of the in-game user interface. The display given is still in its rudimentary stages. When it updates visually, the results look a little jerky and disorienting. I will be adding some kind of smooth animation to it that will make it less distracting to the game play.

Being able to create new object types on the fly and have them interact with preexisting objects with little or no modification to source code is very neat, indeed. I've been doing a lot of this lately. Much of the designing that went into the creation of object types really paid off. Of course, there is always functionality that I won't be able to think of beforehand, but giving some good serious thought to what certain objects currently, should, and might be able to do is very beneficial. The dramatic differences between the code structure of this current project and Zep's Dreamland are very evident. I have been learning and trying out a lot of new techniques I did not use in Zep's Dreamland. One thing that hasn't changed, though, is that my comments, when I actually do comment, contain an excess of information. What do I mean, "When I actually do comment?" Well, many times when working on code that is completely new I will write a few chunks of code that are commentless, simply because I want to compile the project and see if my additions work at their basic level. What happens sometimes at this stage is that I will end up either adding on to the code I just wrote, or move onto something else without adding juicy comments as to and what my code is actually doing. Uncommented code always gets addressed when I have my refactoring days, though, so almost every questionable piece of code will have a comment to accompany it.

As for my comments sometimes being absolutely huge; I don't think it's a bad thing and I'm sure many people would agree with me. If a piece of code isn't inherently understandable, then the more comments there are that describe what it does and the thought behind it, the better. I prefer to go all-out with my comments because many a time I will come back to code not being able to remember why I have written something I did. With heavy commenting I can be reminded about just exactly what was going on in my head at the time for almost any piece of code.

Things are going well recently with development on my project. It's nice to see that I'm spending more time each day working on it. It makes me feel great, too! Here's to one of my great pals: Motivation.