It's been a slow week. I've been struggling with a bunch of shearing issues. Previously, I wasn't able to observe the problem on my own hardware. A few others showed symptoms of shearing, though.

With a recent monitor upgrade, I too, now suffer from the insane amount of shearing that my came is capable of producing. So far I've yet to be able to find a working solution that works on my hardware. If I were doing things in Windows I'm quite certain some sort of page flipping/triple buffer method would work without any problems. Unfortunately, Allegro is a little picky with OSX. While my system should be able to do triple buffering without a problem, Allegro can't make it happen. This is one of the downsides regarding Allegro in OSX: it's using some deprecated technology and really should be updated to harness the power of what's available on the system now.

All of that said, I'm taking a look at AllegroGL to see if I can't simply force hardware acceleration. Yet again, there are issues with AGL on OSX: I can't build universal binaries anymore if I go this route. While that's not a major concern anymore as I have both a PPC and an Intel Mac which I can use to do the compilation, its still a bit of a hassle. Anyhow, my first attempt at using AllegroGL to solve the problem with the least amount of code structure change failed--it stopped shearing, yes, but caused the game to run at an abysmal framerate.

It make take a bit of code mangling to get everything to work correctly; if it's even possible at all. This shearing issue has really put a damper on my spirits in regards to the game. It's be one thing if it was just an issue of changing from a double buffering mode to page flipping, or triple buffering. It's another when the main solutions to a shearing problem aren't even able to run on the hardware you intend to do all of the development (and playing) on!

Another light day. I added some very basic and rudimentary AI to the Flowrians. Now they decide between randomly standing still, or running around for no reason whatsoever. They love running into walls, or just standing around for way too long.

In testing out their logic, though, I noticed that something wasn't quite right. I could make them collide with solid objects when moving into them, but I was able to push solid objects right through them! This was not good. It all had to stem from how I set up solid objects to be able to tell when they can be pushed through other objects or not. I could, of course, just say that the NPCs were "solid objects." The downside to this, however, was that they would also block the player. That definitely wasn't good. It turns out that the solution was pretty simple. It required a slight bit of code duplication, but it provided the perfect result. Solid objects could collide against other solid objects and NPCs (which are a special type of solid object which don't carry the solid flag [which causes the problem I'm describing]). NPCs, however, override the block-checking code so that when they are checking if they are blocked by something, they only check against blocked objects and not other NPCs. This prevents NPCs from blocking each other. With a bit of polymorphism and virtual function goodness (I know some of you may disagree with the fact that it offers "goodness") I can easily pull off a proper solution to the problem I was facing.

Today was a bit of a light day. I threw together an incredibly basic animation of the Flowrian race walking in both directions (they are just mirrors of eachother. Code-wise, this was simply adding in a new object type. I wanted to have some finer control over what all NPC objects would be able to do, and what default attributes they will have, so I added a base type for NPCs to the engine, as well. Of course, I had to go through the whole process that is required when adding a new object type to the game: throwing in code in the editor to instantiate them, and updating code in the main game engine to load them properly from the object list file. With that all said and done, it was really funny to create a few dozen Flowrians and unleash them on the player all at once. As of right now, their logic is simply set to hone in on the player at all times. This will obviously be updated in the coming days to be a bit less silly!

I also did a bit more design work today, fixing up the wiki to contain more accurate information. I didn't add anything new or interesting, but mostly removed old inaccurate information.

The total object count in the game engine has now increased by one. That's exactly twice the amount of objects previously! Alright, so that comment is a bit tongue-in-cheek, but it's a bit of an accomplishment. I've been holding off on adding objects because I wasn't sure what types of objects I needed and/or wanted to support in the game world other than pushable ones. In allowing the player to save only at designated areas during gameplay, there was a new necessity for a fancy new object type: the save station.

With the addition of the save station object type, saving can now be done from the game engine, which will pop up the previously (in yesterday's post) mentioned save game browser. The user can pick to overwrite an existing file, create a new one, or back out entirely. Currently it lacks full proper usability. For instance, it will not ask the user if they want to overwrite an existing save if they choose to save in a pre-existing slot. All in all, though, it's neat to push a button while standing in front of a save objet and have the browser pop up instantly.

One thing adding this new object type to the game did bring to attention though is that there is a lot of manual work involved in adding a new object type to the game and the editor. I am going to need to do some investigation to see if I can make it a little more automated, or at least a little less cumbersome. Currently there are special cases for each object type within the code that sets up the editor, as well as the code which reads objects from the master object list. In either one place, or the other, distinction among object types must be made--it simply cannot be avoided, otherwise I won't know what types of objects to instantiate. I do think, however, that making the distinction in multiple places is overkill and probably unnecessary.

Hopefully I'll be able to make dealing with adding new object types to the game a little more developer-friendly. It's very easy to forget a small piece of code that will otherwise render the game unplayable. One case in point is the loader of the world objects file. It requires code that checks an objects type and instantiates a proper object of that type during loading. If you go through the trouble of adding a new object type that can save itself to a file, but then you never make sure that when loading such a file you actually instantiate an object, you'll be left scratching your head and wondering why things didn't work. Fortunately, in this specific case, if an object exists but isn't loaded, I stop the game from running. This may be changed in the future, however...

Lastly, I finally got around to doing a Windows build of all of this new functionality I've been putting into the game. I found a few bugs and errors in my code, which is nice. The only problem, though, is that they only existed because of the way Windows plays with directory creation, and use of the mkdir function. I also need to keep in mind that there are other Windows-specific bugs regarding sifting through directory structures. For now, it has only affected two people who have tried the game. Hopefully its either not a large issue, or the solution is simple.

It's been a while without updates. I've been a little busy with some system maintenance and setup. Things are up and running well now, and since they have been I have some stuff to talk about now.

After making the switch to running in a higher colordepth (but still using 8bpp image from disk), I've thrown together most of what will make up the saving and loading interface for the users. It currently works a lot like how Zep's Dreamland visualized the whole idea: with a list of saves that the user can select from. If they don't want to overwrite an old save, they can start a new one. Currently there is no way to manage deleting saves that are unwanted. This is something that's going to require a slight bit of hackery to get working because of how I'm dealing with names for saved files and their data, but it can be done.

During the process I stumbled upon quite a few little bumps with the actual saving and loading of game data. I'm sure there are more to come. One of the big issues had to do with making sure the map was properly re-initialied along with any other world object data. In addition to all of this, I'm going to need to create something that's going to keep track of game state information that should be saved to the game save file. This would include stuff like the amount of playtime that has been accumulated, along with the number of items/collection rate that has been obtained. This is going to have to wait, however.

Currently only the saving loading works properly. I have yet to implement usage of the game data visualizer to enable game saving. I'm planning on having the game feature savepoints instead of the ability to save anywhere. For now, during testing, there will just be a magical "save anywhere" key to test things out. Most likely things will be this way for a while, until I settle on just exactly how I want the saving mechanism to work. That is, I want some sort of obvious visual indicator that a given object in the game is a save spot.

Alright, so it's been a little while since the last update. Between then and now a few things have changed, and a whole bunch of things have been implemented. First off, let's talk about that options screen and key configuration...

Key configuration is now complete, and saving/loading of the options data is now in place. The keyconfig screen will have to be updated eventually once I put in usage of objects which will require an extra key that's currently unaccounted for. More interesting, though, is how testing the saving and loading of options is going to work. Since I'm building in OSX I'm using a cool method of loading data from the application bundle. Since I took the lazy route, when building the app I simply copy the data directories into the application bundle as a whole piece, instead of only updating those things that do not already exist. This has the unfortunate side-effect of removing any saved settings I have every time I build the application! That's because the application is saving data directly within itself, not to the data folder which is eventually copied over. So, I'm going to have to do a bit of hackery here and there to get things to work. In addition to all of that, Mac OS X has some specific guidelines about where application save/preference data should be stored--and it's definitely not within the application itself. This is something that I'll have to sort out later when I know just exactly what type of data I'll be creating during gameplay. Hopefully there is an easy way to get access to the directories (there is a framework that gives you the paths of where to store stuff) that I can use in C/C++, since Allegro isn't Objective-C friendly.

While playing around with different screen transitions and coming up with ideas for the loading screen (which has started but hasn't had much work done to it), I have come to the realization that running in an 8bpp paletted mode is just causing more headaches than it is worth. So, instead, I'll be running at the native color depth, but still using 8bpp images. This will give me a little bit of the best of both worlds, and as long as it works out I'll end up keeping it that way. I need to do some more testing, but I think it will relieve a lot of unnecessary restrictions that I've been dealing with so far.

There isn't much to report aside from doing gruntwork on the menu system, putting together all of the inner workings of the options screen and selecting/modifying various game settings. During that process, though, I stumbled upon some other work that needed to be done regarding the palettes.

Since I'm working in 8 bit mode, I need to use palettes. At times, the main screen is displayed at the same time as the gameplay. That might sound a little confusing, but when you see the screen transitions in action you'll understand what I mean. This means that all palettes that are used during gameplay must also contain the color information required for the screen. Because I want to be able to change palettes depending on which tileset is currently used in the game, I had to shift around the color entries in order to ensure that the title screen, and other static colors that are used globally throughout the game must exist in each and every palette.

So, long story short: I went back and recreated a "static" palette set which contains all of the static colors so far. Then each of the tileset palettes build on top of that static palette. Once the change was made, I had to re-export all of the image data to now reference the new palette entries properly. It was a lot of gruntwork, but it's nice to know that it's out of the way--for now, at least!

I spent some more time with the title screen and the menu system. It's turning out to perform really slick, so that's a plus. I've incorporated all sorts of nifty transitions when switching between screens.

With much of that in place and a bit of new artwork created for each of the new screens I can now begin creating the interface for modifying game options including sound/music volumes, keyboard controls, and fullscreen vs windowed mode preference. I hope that all, if not most, of the option choices will fit within a single screen for manipulation by the user. I don't want to get into this crazy business of having to transition between tons of subscreens. For now, all I really want is the following setup: title screen, options screen, load game screen -- that's it! If anything, I'll only be able to add one additional screen anyway. That might sound a little strange, but once you see how I've implemented the main title menu, it will all make sense.

In due time!

So, maybe I lied about working on the NPCs next. Instead, I started revamping the title screen to the game to hold some of the infrastructure of starting a new game, resuming a game in progress, loading a saved game, and setting game options.

While game saving doesn't exist yet, I'd like to have the main menu screens to handle it before I end up putting it in. Mostly, though, I really wanted somewhere within the game itself for players to adjust settings like key configurations, volume levels, and music quality. So far for all of the demos that I've had people play: there has been no control over any of these things. Obviously, this isn't that big of a problem right now, but it would be nice to have this kind of thing in the demos so that people can play around with it and potentially find bugs here and there.

In setting up the menus I then began the whole process of thinking about how saving in the game is going to work. I don't think saving will be allowed just "anywhere" in the game. I'd like to create a setup where there are save points scattered throughout the game world. Nothing is etched in stone just yet, though.

I churned through a bunch of spriting and pulled together jumping, falling, and pushing animations for the pseudo main character. At this point, I might as well say that the robot character will end up being the main player character, as I probably won't ever end up changing the sprites myself. Regardless, with the new sprites in place, everything looks pretty awesome.

I spent a lot of time putting together a few maps to put my editor to the test. I found a few minor bugs, but for the most part it is quite stable. All of the issues I found can be worked around without losing data, so that's good.

So, lately, progress has been made content-wise. I think moving forward I will be coding in the basics of some of the NPC types, and see where things go from there.

Minor update: but I did a bit of bounding box tweaking on the new character sprite and it seems to be working out okay. I have to do a few more animations to get myself back to the spot where I was when using "borrowed" spritework. For now, I'm behind on jumping and falling sprites in both the left and right directions. Hopefully I can make short work of it as I'm currently just mirroring the right facing sprites to make the left facing ones.

In addition to jumping and falling, I really want to throw together a "pushing stuff" sprite before I move forward with anything else.

I've been fiddling around with more character sprites, trying to replace my "borrowed" material with some original content. So far, I've come up with this very rough animation of the original robot character:

So far, it's decent enough and it gets the job done. Using the robot sprite within the game, however, yielded some results I wasn't expecting. Unfortunately, the sprites I have at the moment seem slightly too tall for the game world. In order for things to work out in a way I would like, the sprite would have to be smaller than 32x64 pixels. If the player character is any taller than that, problems start to arise with laying out map elements, since each map tile is 16x16 pixels. If the player is a single pixel over 64 tiles high, then any tile must be placed a full tile's height higher than the player's height in order for the player to fit underneath it and still look normal (regardless of bounding box hackery).

So, while this animation is pretty fluid and gets the point across, I'm going to have to create some more test maps and tweak around with the bounding boxes to see if it's something I can use--or whether I need to scrap it and go for something smaller.