Since finishing up joystick support is now a "to be done in the future" task (essentially either waiting for or coming up with a fix for the find_first OSX error), I've decided that the next natural step to take is beefing up the very simplistic (and mostly idiotic) enemy AI. In order to do so, however, I really need some animations to act as placeholders for specific animations. Without any kind of visual clues to the players as to what the enemy is actually doing, any playtesting would simply be thrown out the window. For instance, consider the scenario of enemies that throw punches. Without some kind of visual indication that they're throwing a punch, the player may simply take damage from an invisible bounding box that would be the enemy's fist pummeling them.

So, my efforts will be thrown up to pixeling stickmen figures to take place of the current enemy graphics. Hopefully I'll be able to make things look sort of believable, at least for the short term. It's a matter of making it look like ultra programmer's art, or not having updated AI at all. I'm going for the updated AI! So far I've whipped up a very crude idle/breathing animation. It needs touching up, but it gets the point across--and that's mostly what matters at this point.

Additionally, I'll probably be working on a few other things during these pixeling efforts and before I start inserting the new graphics into the game and start doing the coding part. This "other stuff" includes things like creating new level backgrounds for level progression as well as possibly throwing together some simple music tracks so I can begin implementing multiple song features.

The dictionary item todo list is now complete for the time being. I finished up the last six sketches and trimmed down the listing of items that don't have any content. The entire complete dictionary at this point lists a total of 83 items. Pretty cool!

With that finished, I grabbed the latest version of Allegro. I wanted to get to completing the implementation of the joystick code now that the OS X version is fixed. Unfortunately, there were other problems with the latest revision of Allegro. find_file is apparently broken. Hopefully that's the only problem. Incidentally, having installed a broken version of Allegro meant that my game no longer worked. Allegro installs itself as a framework on top of old frameworks, so I had to make a decision to wait for a fix to find_file, or downgrade back to the old version of Allegro I was previously working with.

I decided that there's no point in waiting as that could take a long time. I could spend that time working on other things that don't depend on the fixed joystick features. After I reinstalled the older version of Allegro, nothing would compile--not my project nor example test programs. I struggled with this strange oddity for a while, and then finally came to the conclusion that I simply must remove all old allegro stuff and rebuild/reinstall from scratch. It took a few tries to pinpoint all the places Allegro installs stuff during an OS X build, but I finally got it back to where I was before I tried using the latest SVN version.

With so much time spent playing the Allegro version dance, I wasn't able to get much else done. With this minor setback in not being able to implement the joystick code properly I'll have to reconsider what items will now be getting top priority.

I accomplished a large amount of work in regards to dictionary item sketches. Currently there are only six items left in the list that still need some sketches to be created. All of the sketches I put in are very basic and rudimentary looking. For now, all I need is for them to get the message across. There are more important things I want to tackle very soon--joystick input being one of them.

While testing out the sketches and playing around in the game I did, however, notice a bunch of little bugs during gameplay. These ranged from some sprites not resetting themselves properly to some combos not doing everything they should have been doing. I also discovered a few problematic combos that are going to need a bit of tweaking before they can be considered "easy to use," which is something I want every combo in the game to be. Currently there are some that require a lot of precision before using them. During the frantic gameplay it's not always easy to tell which queued combo is waiting to be used. Adding in another complexity of having to use it in a perfectly located situation is just too much to ask of any player.

The dictionary item todo list is now (textually) complete. This brings the total number of dictionary items currently in the game to 83. It seems like there are more items than I had originally anticipated for the first pass through of basic stuff, including the implemented combos. I think that when complete, there will be at least 100 items, if not more. Of course, as I've mentioned many times, I still have to create sketches for many of the dictionary items. That's the next big ticket next on the agenda. I can't mark off that todo list as complete just yet!

en more items have been added to the dictionary. As usual, this is the textual data only. Sketches have yet to be completed for these items. Only nine items remain left on the current list of "Dictionary Item Todos." Of course, this is not the end of the complete dictionary; there will be many more items to come. But, for the time being there are only 9 left. Once I finish fleshing out the textual data for these last nine items, it's off to whipping up sketches for all those items that require it.

In site news, it appeared that some stuff was broken regarding the Allegro.cc banner network. The issue has since been cleaned up. During the process, though, I created a new banner image to replace the old one that was currently being shown on other people's sites that display banners from the banner network. Below is what I'm currently using for my banner image within the banner network (yes, it is just using the background featured in the top banner image of this site!)

Today is a big news day. I've been holding out on a bit of information, and also did some work over the weekend which I didn't post about. But, first things first: a new ZD level set has been added! Damien has sent along three of his tricky and dubious levels for everyone to try out. Head over to the level set page and grab Zep's Deeper Sleep. The last level in the set is especially fun -- it features a bit of planning ahead as well as backtracking. This is something I love to see in ZD levels.

Up next is an "official" announcement. This has been in effect for a while, but I was holding out on announcing it for no reason other than I simply wanted to wait. A collaboration has been started between myself, and a talented sound technician (that's what I like to call it). Mark Oates of markmusicproduction.com has offered up his services, for free, to create original sound content for my latest game project. So far the stuff he's done is really well done, and I'm glad to have him on board replacing all of my "homemade" sounds (me going "kshhh" into a microphone). Make sure to check out his site and let him know what you think of his work! Hopefully over time we can come to craft the best sounding effects for the game. It's also nice to have someone else to bounce ideas off of and get more input from. I am, of course, also in search of someone to create musical content, as well as someone to revamp the entire graphics set of the game.

Over in the work related side of things, the dictionary item number has now hit a total of 64. As per last update, many of these items lack a visual sketch to go along with the textual data. I still have plenty to go in my current list of "known" dictionary items before I can move onto some other things in the game; hopefully involving coding. I've been away from touching the actual code for a while because of all this content creation that's been eating up my time. What I'm really hoping for is a release (sometime soon) of new OS X Allegro code which fixes the known joystick problem. I've contacted one of the developers with an inquiry as to when a new WIP might be released. I'm sure there won't be one for quite some time, so I might throw together a "home" version of Allegro which contains all of the stuff I'm currently using, and only the updated joystick code. I'd like to minimize as much untested stuff as possible. I really want to get joystick support into the game, because this is the last thing keeping me from releasing another play test demo to a few select communities for feedback.

A lot of stuff has changed since the first demo I've released, but I'm still looking for a few gameplay elements that will turn the game from "okay" into something really fun to play. It is unique, and I believe it's fun--but I'm looking to add a bit more "oomf" to it. Currently I'm on a "quest to find the oomf" and have been considering lots of different ideas. Once dictionary content creation is out of the way (for now), if the joystick stuff is not ready, I can tinker around in the code with adding some new gameplay elements.

I'm sure you thought the post would be over there, but wait, there's more! Over the past week I have noticed that the forums have been hit by link spam bots. Currently no major damage has been done. Simply a few junk posts have been made that are filled with links to bogus websites. I've been manually stamping them out. If things pick up, I'll be changing some of the forum related stuff. If you're more interested about this subject, swing over to the forums where I've started a topic about the forum abuse.

Whew! That was a "mouthful." I have a feeling the updates for the rest of the week are going to be paled in comparison to today's!

I did a lot more writing today, fleshing out the descriptions of a bunch of new dictionary items. The total number of items which have textual data is up to 44, with the 44th still requiring some work before I can call it finished. Out of all those, there is still a big chunk that I need to create some sketches for. I'll be doing that soon, as the size of the sketches is a big dictator of how the text layout will look--potentially requiring me to make some changes to the items I've already written.

Hitting this high mark pulled me out of writing dictionary entries for game entities that aren't featured in the actual gameplay itself, but rather are part of the backstory for the game. This was a nice break of pace. Writing about individual game entities allows me to break away from the backstory and describe individual, personal stories relating to each specific item (if I so choose). I'm also at the stage where these dictionary items aren't necessarily available by default: they need to be unlocked by performing specific actions within the game.

The real fun is just starting to begin!

While adding new sounds to the game today I found a small bug related to game sound and music. Upon initialization, I was setting the base sound volume to whatever was specified within the options screen. While it might seem like the right thing to do, it was actually opposite of what I really wanted. When each individual sound is played, I play it at the given volume set in the options screen. When the volume is changed at the options screen, I basically set the value at which each individual sound is played; not the master volume. Setting the master volume to this level was wrong. Technically, the master volume should always be at maximum, because the sounds are played at a specified volume that is some amount equal to, or less than the maximum master volume level.

The problem existed in a scenario where the volume would be saved out as 0, the game loaded, master volume set to 0, and then volume set via options to maximum. Well, the master volume would still be at 0, but sounds would be playing at the maximum volume of the master, which would still be 0. That was a long explanation for something so basic. The fix was even more basic: set the master output volume to the maximum as opposed to the value specified in the options screen. Problem solved!

I've upgraded Xcode to the latest version, and turning on Univeral Building works and compiles everything without error. Unfortunately, I'm not sure if that actually works properly regarding the Allegro library (or framework in OS X lingo). I do not have an Intel version of the Allegro library built, so, what I'm assuming is going on is parts of the App are compiled under native Intel-ness, while all the Allegro parts would still be emulated under rosetta. I've asked some questions here and there that hopefully the Allegro developers will pick up on and be able to give me an answer to. For now, Universal Binary building is on hold.

Other than that, I've been chipping away at the dictionary as much as I can. Those original seven items grew a bit, and now the textual data is complete for 30 items in the dictionary. This doesn't mean that each entity the items describe is unique. For instance, there is an entity described in the dictionary that fills up 10 dictionary item slots. Doing things this way helps break up the reading and allows you to skip parts of a specific entity's description if you so choose.

A few of the items I wrote information for are lacking sketches to go along with them. I'll be switching on and off writing data and drawing sketches alternatively as I get worn out doing one or the other. So far I've nailed down a good portion of the entries, but there's still a lot of work to do -- and that's not even covering stuff like combos and other sorts of things I haven't even created yet.

Writing the dictionary entries is a bit difficult! Currently I'm writing the entries for characters in the game world that aren't actually featured during the gameplay. It's a bit tricky to write an entry that tells enough about the characters but doesn't only re-iterate what has already been stated in the game's backstory. It's a combination of filling in the holes that are left open by the backstory, but also including enough of the backstory to have everything make sense. What I really want to accomplish is giving the reader a sense of what each character is truly like, including some of their personal traits. This will allow for a better sense of feeling that everything within the game is connected.

On a very different note together, I've been informed that Zep's Dreamland has been pulled from Apple's website! I'm not sure when this happened, and definitely wasn't informed about it. I was originally going to just resubmit my game, but, I figured it might be rejected on the grounds that my game already existed in Apple's listing at one point in time. So, I emailed them. To my amazement, I got a reply back about an hour later. That's pretty awesome!

Apparently Apple prunes out old projects and is only privy to listing stuff that's new and/or updated frequently. They noted that ZD hasn't been updated in about two years--and that's actually correct. It's pretty amazing to think that ZD has such a long history. In order to get ZD back up on the downloads section I'll have to do some kind of update. The person who replied to my email made a suggestion about making a Universal Binary. That's actually a good idea, and something I would have done eventually anyway.

I'll be upgrading Xcode to the latest version (which gives me the capability of creating Universal Binaries). If all goes well, expect a Universal Binary of Zep's Dreamland soon!

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!