Not much to report today. I converted the 7 sketches into proper data that can be used within the game (read that as: converted into a bitmap). After that, I began writing the entry that goes along with the first sketch. Since the game dynamically loads this data, I was making constant changes over and over. During this process, I noticed that I was doing the same task over and over again: deleting filename extensions!

PackTools are an awesome set of tools that facilitate converting the plaintext data I write into a format useable by the game (Allegro's Packfile format). One attribute of the tools, however, is that it will suffix the original file's name with a new extension. Currently, I'm naming the files without any extension for loading by the game. It turned out to be a pain to constantly be packing each file, and then having to physically rename it once it was done packing. There's no option to chop off the file extension within the packtools.

Being fed up (with the limitations of my own tools!), I decided to write a nifty little app that would strip off filenames after the first dot encountered, including that dot. It's a simple Python script, turned drag/droppable application. I call it "S.trip". Now converting dictionary data for use in the game is as simple as dropping a file onto Pack, and then dropping that generated file on top of the S.trip. "Filename.txt" -> "Filename.txt.packed" -> "Filename" Ahh. Perfect! All with two mouse clicks and a bit of dragging.

Sure, it doesn't take a lot of time to manually remove some text from a file name--but having a drag-'n'-drop solution just makes things a lot quicker, and a lot less tedious. Hey, who knows? Some day I might even chain the two apps together so that S.trip can be automatically called from Pack and Unpack if desired.

Due to some changes with how I needed sound to be processed for a specific enemy I was sent on a little adventure. The special attack for one of the enemies now reduces all other sound in the game by a given amount. This is a fairly simple process. With the way my code is set up, however, it wasn't so straight forward. Music is played via a "music player" that is not global. So, in order to modify the music volume, that enemy needed to have a reference to whatever given music player is in use at the time of doing a special move.

It seems simple enough, but here's the catch: all the enemies derive from the same base class. Because of this, I'm able to throw all the types into a vector and just iterate over them, calling the virtual functions that they are required to implement. Sure, I could just pass a pointer for the music player to the logical function, no big deal. It would only require changing the construct for the logic function of every enemy. This is pretty basic with a global find/replace. The main problem lied herein: when the enemy dies, the sound should be set back to normal. Well, enemy death is not handled in their logic function. When the enemy takes enough damage that renders them "dead," flags are switched within the "take damage" function. Passing a pointer to a music player to a damage dealing function just seemed wrong.

It was at this point that a much simpler solution dawned on me. In any case, every enemy type would have to have some information pertaining to a music player. For most enemies this information will never be used, but it doesn't hurt to have it; and there's definitely not any speed issues to be concerned with. Instead of going the route of changing each and every enemy type, I could just add a pointer to a music player in the base enemy class! This was one of those moments where I felt silly for not having thought of that in the first place. The very thing which I thought was giving me troubles was actually the easiest way to implement the volume changing: the base class and using a vector of enemies derived from that class.

Throwing a music player pointer into the base class allows me to have it available for every enemy type, and initialized to a safe without having to touch any of the specific enemy code. Those enemies that don't need to use it needn't worry about it at all. For those enemies that might, I added a simple function to the base enemy class that will set the pointer to a given value. The volume reduction during that enemy's special attack works fine now. Unfortunately, it's kind of abrupt. I'll be looking into how I might make the reduction gradually fade in and out.

After that little fiasco I started organizing what order I would like specific items to appear within the dictionary. There's still a lot of work to do; but something basic to work off of to encompass all of the current game content is nice to have. I began doing quick digital sketches to accompany each dictionary item. While nothing spectacular and (as I have been saying all to often) they will eventually be replaced, I believe that having them as a visual bonus is better than having a text only dictionary item entry.

So far I've finished 7 of them. The bare and very incomplete dictionary item list is at least 50+ items. Looks like I've got a lot of sketchwork ahead of me!

The code for the last combo has been in effect since last Friday. It works fine, but in testing out the combo I realized I had made the sprite for it a bit too small. No worries, though. I'll be leaving the sprite as it is, since it will eventually be replaced anyway.

I spent a large portion of the weekend and today upgrading my Linux machine from slackware to gentoo. In doing so, I wanted to create a backup machine that I could store all of my previous Linux work onto, instead of wasting CDs. This also gave me the opportunity to totally screw up the installation of gentoo without having to worry about being stuck with my main Linux machine inoperable. Lots of compiling later, I now have a new Linux tower and my old Linux machine running gentoo.

Having completed the installation I went straight into getting the game built for Linux. I encountered a few road bumps along the way, the main problem being ALSA support. A quick kernel recompile fixed that issue, however. After all of that work, the game compiled fine, but...

A double-free error? I was a bit beside myself, mostly because both Windows nor MacOS X complained about a double free issue. I really wish they had. I'm guessing either they don't care, or, they're smart enough to remember that specific areas of memory have been freed and just "do the right thing." I think it's safe to say that they just didn't care. Some debugging later, I found the problem to be in fclose()'ing a pointer twice!

The problem existed in one of the very few places where I happened to miss setting a pointer to NULL after freeing/deinitializing it. I take a lot of care in ensuring that I set pointers to NULL where appropriate. The problem was contained within my logging class. The function that closes up the log obviously fcloses the file pointer. I was also calling the log closing function in the destructor, as an overly cautious measure! I'm glad I was able to determine the cause of the problem so quickly.

With that fixed, the linux build proceeded without any problems. I was even able to get the binary tested. Good news! It worked fine! I think that with the next limited test demo release I'll be offering a Linux version, as well.

Ultra short update today, since I didn't have much time to get a lot of work done! I've crafted a sprite for the remaining combo in the todo list. It was actually a much larger sprite (more frames) than the ones I've been making for the previous combos, so it took a bit more time to complete than usual.

The corresponding code is currently still in progress.

I feel like I'm repeating myself, but three more combos have been added to the game! So, this leaves one combo left that is in the combo todo list. Technically, there is another combo that I know for sure will be featured, but I haven't worked out the details completely yet. I suppose it's safe to leave that one off the list for now. Maybe tomorrow I can spend some time thinking about what I want that specific combo to do, and then I can consider the first round of combo creation wrapped up for the time being. Once that's done, like I've said before, I'll have some people test things out to see how it all works.

On a completely unrelated note (unrelated to combos, at least) I gathered some interesting information about my project. It's completely unnecessary and useless, I suppose, but I figured I'd share it anyway!

• Lines of code: 30,287 (includes white space/comments)
• Source/Header files: 158
• "Work" files: 772
• Complete Project size: 1.56GB (this includes all backups and work files)

Work files are all files that have any connection to the game whatsoever. This includes, but isn't limited to: saved screenshots, sprites, sounds, concept art, assorted documents, old binaries, etc.

There isn't much to report other than that two more combo effects have been added. The number of combos remaining until the todo list is all checked off (for now) is four.

With the completion of each of the combo effects I keep on reminding myself that content needs to be added to the game dictionary (for each combo, among other things). Currently the status of the dictionary is a bit hazy. If anything, it's incredibly far from complete, content wise. Programming wise, it's essentially complete minus code for checking the conditions for each specific dictionary item (which is minimal).

The main piece missing is a master list and order that each dictionary item will appear in. I definitely need some direction when it comes to the dictionary. Without some sort of predefined list with an order of items I will keep pushing content creation further and further back. This task is currently on the todo list; but the completion of combo creation has a higher precedence at the moment.

Three attack style combos have been added to the game. In the current combo to-do list remains six combos. There are, of course, a few ideas I have that I haven't written down or accepted as combos that will, for certain, be implemented. I think the approach I want to take now is to complete the last six I have slated for implementation and then throw a new demo at a few people to see what they think.

While playing with my code I ran into one of those situations where you second guess your own code. I have a combo manager which handles each of the individual combos and all the things they need to do. It works pretty simple: the main game logic asks the combo manager to perform its logic and drawing, which in turn asks each of the specific combos to do their own part. The problem with using this approach is that if left in that state, I would be throwing vectors around all over the place--and iterating over every element in those vectors many more times than is necessary. Because of that, I have extrapolated a bit of the combo logic into the main logic loop. This allows me to iterate over the contents of the vectors of game entities only once and do any alterations to those objects on the fly without having to pass the vectors to the manager, and then to each combo.

Consider only the three combos I have implemented tonight. Without having some of their logic housed outside their class, I would be iterating over two vectors, four times instead of one time. Overhead like this just simply isn't necessary.

For some reason when looking at the code I thought about it and said "Why am I doing logic that belongs to this combo way outside here (here being in the main logic loop as opposed to within the combo's own logical method). I quickly decided that what made most sense was to throw the vectors around to all the logic functions of the combos that needed them. Soon after, though, I realized just why my code was originally "ugly" -- there's no reason to be iterating over the same vector an excessive amount of times. After reverting my code to how it was, however, I left a nice lengthy note to myself explaining why the code was organized in the way it was.

Hopefully next time I do a double-take on my own code I'll notice it!