A while back I started drawing some static sprites for many of the races that will inhabit the game world. I took these and began coding in the shells of what will eventually compose each individual race as an NPC type within the game. Technically, all I've done so far is add the ability to choose a specific race type in the game's editor and place their starting position on any arbitrary map. There isn't much else other than being able to draw themselves in non game mode. While it's nothing incredible, at least it's a start. I have a few more races to go (I haven't even drawn generic sprites for them yet), so it may be a while before I have shells for all of them. The main purpose for this is to make it a little easier when it comes time to making each race unique. Most of what I've done so far was simply a bunch of grunt work that was, for the most part, time consuming.

On the other side of development, I've been implementing a useful and nifty feature into the game engine: a map system. More specifically, I'm putting together a mini-map system where the player will be able to see their position in the overall world map, as well as track where they have and have not visited. This is absolutely critical for a game of this style where exploration and, potentially, backtracking will be required. At first I was unsure of how I was going to approach the whole minimapping issue, but after some suggestions from fellow developers and a bit of thinking I came up with a solution that works for me. Each "screen-sized" portion of an in-game map corresponds to a single "tile" in the mini-map. Using this method, it's easy to correspond in-game maps to one another simply by telling the mini-mapping system which "start tile" an area given in-game map represents. In simpler terms, while editing a map I can simply tell it: the screen you're looking at right now corresponds to this specific tile on the minimap. Now that you know this, you can track the player's movement throughout the entirety of this in-game map and the mini-map will be able to update accordingly. So, the only burden this places on level creation is that each map must be made to correspond to some specific area in the minimap -- a small price to pay for a relatively automatic system.

It's still pretty generic at this point. So far all you get is a pink filled square for every area you have visited -- nothing exciting. I hope to replace this with the filling in of what looks like an actual map and some neat graphical representations of the places you have visited so far. Only after doing a mockup will I be able to tell if it will actually be worth it. The first thing in line isn't that, though. Now that I know what the minimap might look like in its entirety on the screen I am going to attempt to carve out an initial version of the game world to fit within a screen's dimensions in the minimap. The last thing I want to do is to have to create some sort of scrolling or zoomable minimap. It's annoying enough to have to keep toggling a minimap so you can see where you are, much less having to actually navigate around on it.

Things have been moving incredibly slowly lately. To be honest, I still haven't even made that mini short-term task list that was supposed to help jump-start things. Hopefully within the next few days I can pump that out. One of the first items I'm going to plop down on that is to make simple shell class structures for each of the races that currently do not have one. This will at least give me a place to tinker around in when I feel like coding and taking a break from high level design stuff.

In addition to that, I know for sure that I want to implement sloping tiles. While jumping around is fun and all, having to do it any time the ground level inclines even just a bit is really a pain. I have implemented a neat way to do raised inclines that could handle any amount of bumpiness whatsoever instead of a generic 45 degree incline, etc. I hope I can throw that same style of collision detection at the game without any problems. It used some hackery and Allegro-specific functions to look at the pixel contents of given bitmaps used to render the tiles. With my new library I'm not sure I can easily to this, especially given how I need to structure textures. I'm sure it's possible, but I personally don't know how (yet)!

There are still so many things to do to even get things into a pseudo playable version of what the final game will be like.