The player now has completed animation handling code for moving left, right, jumping, and falling. I must say that seeing it in action with some good-looking sprites feels nice. There were a few kinks to work out, though. For instance, dealing with how which sprites had precedence over one another wasn't easy. While jumping, the running animation shouldn't take place, but when a jump is complete, the running animation should kick in automatically. In addition to that, since I have built the system in such a way that the upward and downward motion of a jump are two different animations, I had to prevent strange things from happening like switching the facing direction on the transition from up to down.

There are still a few little particulars to work out. For instance, it's possible to jump "backwards" by pressing the keys in a certain fashion. I also don't prevent the player from jumping in one direction, and then pressing backward to move in the opposite direction. This keeps the sprite facing the same direction the whole time, but I'm not sure if that's exactly how I want to set things up. To be honest, though, I'm not sure if I want to allow the player to "back up" during jumping in the first place.

For now, things look quite decent and I'll probably throw out a demo at a few people to see how they take to the movement and jumping. I'd like take some time from the codebase and figure out the next chunk of work that needs to be done. I am envisioning it to be some sort of NPC structure or framework, but that may change if there are issues with how the player control handles.

Map exits and transitioning is now functional in the main game engine. Using the method I described earlier of simply having a vertical or horizontal "trip-line", and positioning the player on the receiving map relative to where the originating exit destination has been placed allows for a nearly seamless map transition. What this means in basic terms is that if the player is jumping while crossing map boundaries, they will not be placed arbitrarily in some weird position when they come out the other end. Instead, they will appear as if they simply jumped right through the invisible barrier. Pictures make everything easy to understand:


The player is at the edge of map 1.


The player jumps through the edge boundary


The player is then transitioned to map 2, but is in the same "relative"
positioning from the ground that they were before the transition happened


The player lands on the ground, completing a jump across the boundary between two maps



While is seems like something really trivial, not having this kind of map transitioning really breaks immersion for the player. During the process of implementing this feature I came upon a few areas in the engine that were a bit buggy. One of those areas regarded the map's internal name representation for itself. I originally thought that I had put in some code for it, but never actually set it to anything. It turns out, however, that I was using it, but filling it win with the fullpath to the file instead of simply just the filename. I decided that this should change.

By referencing maps by filename only, I can use the resource manager to find paths to them. The only restriction brought up by using this method is that no two maps can have the same name. Technically they could, but the resource manager returns the first one it finds. I don't think I'll be updating the RM to return a list of all the files that match the given filename. That said, this overs big advantages. If I ever choose to reorganize the map files on disk there is no need for me to go back and have to edit them to make sure all the pathing references are correct. I prefer this behavior, as I know from experience how much of a pain in the butt it is to fix absolute paths to files (relative to the executable of course).

Map exits, in terms of the editor, and now finally complete. In the end, I opted not to use a generic button system in order to be able to handle the exits, but rather added all sorts of complicated key combinations that must be used in order to manipulate them. While this goes along with how the rest of the editor is, it isn't how I'd like things to stay in the long run; but I'll talk more about that later.

I've put off actually implementing this feature set for a while. I tried many times to get into gear and simply crank it out, but each time I was diverted. I can't say exactly what it is that was turning me away from completing this task, but something was. Most likely it was just the daunting fact that there would be all of this "special case" code for handling when the user was tinkering with map exits. In addition to that, there'd be even extra special case code for certain things like displaying an alternate map when placing the entry on one map following the exit on the original map. That's always fun to manage. Thankfully, the saving and loading of this data was mostly complete with a few minor glitches that I fixed up. It was really nice to have the structure saving/loading complete before actually implementing its visual manipulation. Usually what ends up happening in my case is the reverse: after going through all the cramming of making the actual editing of objects complete, I had to then perform the mundane task of dumping it all out to file. Ahh, this was a nice divergence from the norm.

So, I was talking about the state of the editor earlier. One thing that is already very evident is that it simply is not user friendly. For now, this is okay, as my main concern isn't making the editor user friendly, but putting enough of it together quickly in order to create some sort of demo that I can put out there and get feedback on. Of course, there's still a lot more work to do before I have NPCs and world objects to interact with, but at least now I'm almost primed for being able to make a little test world that the player can navigate through. That said, if the project takes off, the editor is really going to have to go through an overhaul and be taken from completely non-user friendly to the a shiny, easy to use editor.

The thought of doing that conversion is daunting. Not only is making things "usable" difficult enough, I'm going to have to write a basic user interface to remove the dependency on "special key" hell. Ultimately, it'd be nice if there were no special keys that the user had to remember and everything could be controlled and edited via the mouse--using keyboard input only where required (for things like typing in values). For now, though, the very developer-centric UI of the editor will work just fine.

Now that map exit manipulation is complete within the editor, I simply have to go about updating the engine to make use of them. After that task is done I might actually need to generate some fake sprites that simulate a player running... sounds like a fun little diversion from all the coding I've been doing recently.

It turns out that I was already using the latest version of DUMB on my Windows machine, so I saved my self a bit of compilation on that front. One thing I did notice, however, is that it's been a very long time since I've last built the game in Windows. In doing so I found a very silly bug in my code.

In my map code I have a nifty little function that will set which tileset filename the map uses. It's pretty smart and will free up the internal pointer before trying to overwrite it with new information, given that the string could be of any length up to some given max. It's nice to conserve memory (even though it probably won't make much of a difference) if possible. While this is all nice and dandy, there was one little flaw. This function is intended for use in the scope of code that does not have access to the internal pointer that it is resetting. Silly me, I went ahead and used it within some of the map's loading code. Calling this function with the pointer that it is actually modifying itself as the argument was not a good thing! In essence, what was happening was I was freeing the internal pointer, and then trying to use it to copy to itself! This should never happen. Ultimately it was a problem of using a function when it should not have (and it was actually unnecessary to do so), as well as not putting enough preventive measure around the function to ensure it cannot cause data loss.

It took a little while to track down, but now it's all nice and documented as to what the behavior is. Prior to this it was simply a bug because I had never anticipated it happening. Now there are caveats to using the function, of course.

While on the subject of maps: map exits are coming along. I've updated the class to now be able to represent horizontal as well as vertical orientations. In order to be able to place them down on the map I need some sort of basic clickable area, or a very generic button. Since the map exit will effectively be a one pixel wide or high line, I need some sort of anchor point that can serve as a selector and/or dragging mechanism for exits. The basics for that button class are in place, but it still needs testing.

One thing I have been thinking about lately is how to interlink the maps that the game engine is going to use. The game world is not going to be comprised of levels, but rather out of a "world" that the player is free to explore, allowing backtracking (which I still need to figure out how I'm going to implement this so it works), among other things. Because of this, I need a system where the passage between physical maps is somewhat seamless, and just appears like moving from one area to the next in the game to the player.

I had done something like this in a previous game engine I had created, but the method to how it worked left a bit to be desired. What I'd really like to implement is when a play passes through between one map and the next, their relative positioning to the map "exit" is kept in check. In one of my previous engines, this was not so. If the player happened to be jumping through a map exit, they would appear on the next map in a predefined spot, as opposed to still "jumping through." That method used special tiles in order to determine when to change maps.

My first thoughts on how to tackle this problem to allow for a more natural looking transition is to ditch the tile based scheme. Instead, there will be a simple single pixel wide vertical line, if you will. When the player crosses a certain part of this line -- say, when the player's bounding box is halfway passed the line -- the map transition will take place and the player will be moved to the next map. How this will work to keep relative positioning should be quite simple. Since the map exit will exist in the start map and the end map, I can simply place the player relative to the map coordinates for the map exit, instead of creating an absolute position on the map itself where the player is transitioned into.

Hopefully this will work. I have the basic structure for the map exits in place. They are currently saved and loaded from map files. The only thing missing is the ability to actually place them on a map and link maps up to eachother. One thing my current setup doesn't allow for is horizontal exits. Since there are only vertical exits, I'm restricted to transitioning between maps horizontally. With a few minor tweaks I should be able to set things up so both horizontal and vertical exit lines can be used.

Without actually generating any new tracks, I used a few songs I already had stashed away simply to test out whether music playback on map loading worked correctly--which is does. Unfortunately, it looked like loading music on the fly took entirely much too long. I had a quick discussion with the author of DUMB, the music library I'm using. It turned out that I was using an out-of-date version of DUMB. I'm not entirely sure how I missed an update to the library, but it offers a pretty neat little set of functions that help out in the loading area.

I was able to build the library successfully in OSX without any issues. Next up is upgrading my build in the Windows world.

While I still haven't come up with any decent tracks to use with my map testing, I did do some coding. Most of it revolved around filenames that the editor needs to use, but that I don't want to have pulled from one specific directory. More specifically, I made some changes to the way I handle which tilesets and music tracks are "visible" to the level editor. This is done by simply creating a list of relative filenames for each file. The editor will then read these in an cycle through them when selecting tilesets and music tracks.

Previously, the only data I was pulling from these file lists were tilesets. Upon the addition of the music tracks, I realized I should really have some universal and easy way to grab a list of filenames from a given "data file" (this is essentially just a plaintext list), without copying my code all over the place. In the end I opted to simply make a generic file list class and subclass it for whatever specific file types it was listing.

I like this method of loading up the filenames up front because then I can leave it to the resource manager to do the grunt-work of finding exactly where the file exists in the data area on disk. This allows me to move around the files to different folders or even organize the actual data files into subfolders, if I so choose.

For example: if I had a set of music tracks and then later decided that half of them belong to "underworld" and the other half belong to "fireworld", I can simply create the respectively named subfolders, move the files into those folders, and the game engine will still handle everything perfectly.

Being able to develop a music chooser in the editor and then finally building out music playback on a per map level sort of requires, well..., some music to use! While I do have some old pieces of music other games, I'd like to have at least two unique and original pieces for what I'm putting together right now. I'm quite happy with how my "title" song has turned out to be, and will probably use it for a while.

I think I'm having a hard time because it's difficult to imagine just exactly where some piece of music should go. It could very well be possible that I should put off coming up with something that sounds really nice until I'll know exactly what kind of environment it's going to be used in.

All in all, I didn't complete much tonight. I struggled a bit with my tracking software and created a few small templates for a few songs that might work for the game. Other than that, I did some svn repository cleanup and maintenance to include all data files and "work" files.

I was originally going to keep these out of the repo, but I decided that it's nice to have backups of everything, so I might as well include them!

I added one minor little nicety to the map editor, which is being able to select an already placed tile with the right mouse button. This is incredibly useful, but what I might like to extend this to is the ability to do a multi-layer selection, as well as a multi-tile selection. I'll be considering these things, but they're pretty low priority compared to the other stuff I'd like to get thrown together.

I also fixed an overlooked issue of allowing the player to continue "jumping" even when they blocked from above. Now the player will begin falling, which is what I intended from the start. This was a rather tiny adjustment to the player code to do simply perform a "am I blocked from above" check while jumping is in progress.

In addition to all of that, I've been doing a bit of research into the 100% CPU usage "issue" that is found in most Allegro applications. I've discovered a proposed method of preventing such usage via using semaphores. I'll probably be testing this out in the future and determining whether it works for me or not. I'll be checking out whether there are any other obvious solutions to preventing busy-wait loops while nothing "useful" is happening in the game engine.

I haven't done a whole lot since the my previous graphics spree except for incorporating the potential character graphics into the game engine. It turns out that it took slightly a bit more work than I had anticipated. It turns out that I hadn't created accessor functions to a sprite's bounding box information. While it was a trivial task to implement, it still added more work to do.

I was going to start working on some tile art, but instead opted to simply rip the tiles I used in Fruit of the Loomsoft instead, since they were already 16x16 and should fit in nicely until I need to create some "real" tilesets to use.

One piece of upcoming work includes creating an implementation for including a way to define a piece of music to be played on a certain map. Additionally, I need to figure out a good way to perform map transitions. This sounds pretty simple, but since I'd like the game world to be "seamless", I need an easy way to ensure that the player's relative positioning in one map matches the relative positioning in another map.

Consider the scenario where the player is moving from one map to another. On the first map, the player is at the very bottom of the map contents, and moving into a new map where the player should be positioned at the very top of the map. Additionally, the player may be jumping and in mid-air during the map transfer. There are plenty of games that do this, and do it right. For the most part I'm uncertain as to how, exactly, they do it so well. I'm going to have to do some poking, prodding, and experimentation to get it "just right". While on that subject, though, this brings me to another point.

Since I'm using palettes, I may have to do some additional trickery in order to make map swapping a bit more seamless. That is, if I wanted to swap between two maps without a fade-in or fade-out, but rather some sort of scrolling, I would need to first move into some map that shares some palette colors with both maps, much like some old NES games have done in the past. Then again, I could always make map changes occur when moving through a doorway, or some sort of passage or the like -- since with current day machines I'm quite sure I could make maps relatively "large" without any worries.

I spent some time doing some graphical work. I created a basic standing sprite for one of the creature types that I designed early on. While it took a bit of time to get to the stage its in now, everything progressed quite naturally as I was doing the sprite-work. I found it interesting that it turned out looking much more "macho" than I had originally intended. That said, I still kind of like it! Here you can see the progression and the flow of how I put the sprite together.



In addition to that, I started drawing what the player character could potentially look like. I've been tinkering with the idea that the player may be a robot, and this is a quick design I came up with. Even if this sprite isn't used for the player character, it could be used for some other race or character in the game. There's still a bit more work that needs to be done in terms of shading, highlights, and adding some colors in.



For the amount of time I spent on these, I must say I'm definitely pleased with how these turned out. I don't think I'll be animating them anytime soon, but it will be great to having something other than solid flat colors for objects when I run my builds now.