b>Happy Holidays and Happy New Year to all!

It's been a little while with no real development updates. I feel that the engine is far enough along that I really need to sit down and do a bit more design and creative work. I really want to replace the "borrowed" sprites and music that I'm currently using with original content. So far I've replaced all of the borrowed music. I have yet to replace the player's sprite with something of my own, however.

I'm stuck trying to come up with a decent player sprite. Unfortunately, I think I need to go through a bit more of the design process to flesh out exactly what I want the player to look like. With nothing concrete, I can't hone in on one specific thing and end up not being able to pixel anything at all.

Two minor issues were put to bed today. Those were the ability to place the player anywhere during editing of a map and properly handling when focus to the game's window is lost. Those tasks were pretty trivial, but extremely useful. In regards to window focus: instead of allowing the game to run when it is not in focus, it will "pause" itself instead. Currently a makeshift screen pops up, but eventually it will be replaced with a real pause screen.

With those items out of the way I then started on the big task at hand: integrating world object placement into the game editor. So far I've been manually hardcoding in objects into the engine for testing. Implementing this isn't technically incredibly difficult, but there is a lot of coding that goes into managing the different editor modes. The most time consuming part of implementing the initial stages of object placement dealt with drawing the objects in edit mode. Since I'm using the same objects within and outside of the editor, there needs to be different offsets when drawing objects. When they are drawn in the main game engine, they take into account the camera's current position. While in the editor, however, the camera is not used. The object's draw method doesn't allow you to specify whether you want to take the camera into account or not, mainly because 99% of the time you want to do so.

Currently the editor has the ability to place one object type onto any map. Stuff that still needs to be done includes: selecting already placed objects, removing objects, moving already placed objects, and saving the master object list. So far it looks like maintaining each object type that is going to be placeable in the map is going to be a coding chore. I'm investigating ways I can make the whole process a bit easier than having to copy/paste chunks of code and change a few values here and there.

During the testing of object placement I noticed that pushable objects were, unfortunately, stuck with a pretty severe bug. It turned out that when simultaneously pushing more than two objects at a time, the engine would spit objects to the end of the pile of objects. That's now how pushing multiple objects should work! The problem existed where after an object has detected it should push the object in front of it, additional checks to ensure that it was not supposed to be pushing more objects were missing. Instead of telling objects to move and perform proper bounds checking while pushing other objects, I was simply moving them manually. Calling methods that ensure proper collision detection occurs fixed that problem.

A whole slew of news to discuss today! The first round of basic object types (both solid and pushable) are now ready for use. The entire idea of having pushable objects react to different speeds at which they are pushed determined by their "weight" is now in place. In addition to that, pushable objects are able to push other pushable objects. Each time a pushable object pushes into something else, the force with which it does so diminishes. So, if you line up a whole bunch of objects, eventually you will reach some limit and not be able to push them any longer. I have yet to decide whether I want to implement pulling of objects. Ultimately it would be an easier job than pushing, as you cannot pull multiple objects at once given how the world is structured. The code to handle which direction the player is facing and what minimal proximity to a pushable object must exist would actually be harder than getting the actual pulling of the object itself to work.

Object placement is still unavailable in the game editor. I've been flip-flopping between two different methods of handling object placement. One would let the editor place a generic object type and then change different properties on it, ultimately morphing it into the end result object that they desire. The other methods would simply let the editor pick from a visual layout which object type they'd like to create. I'll most likely be running with the latter implementation. This is one of the items that is next on the list of things to do. With the capability to place world objects comes the requirement of being able to save them for later use. This functionality already exists, partially. Each new object that is created must be able to save and load itself. Once that is out of the way, object management should be a breeze. The only thing to look out for is that when playing, object may be moved/etc, and jumping in and out of play/edit mode and then saving the world object file may have destructive results. My method of managing this will be to allow the ability to save different versions of the world object files. One can be used for testing and the other can be the true, "initial", world object file -- detailing how every object should be for a fresh new start of the entire game.

Unrelated to objects, the map exit code had to be partially revamped. There have been some issues concerning the passage between one map and another using the exit portal system. One major issue that plagued the system was how exits behaved at the point in time immediately after the player moves through them. If the player exits a map and is placed on the "return exit", you obviously wouldn't want to instantly portal them back. Instead, you negate the effects of the portals until the player moves off of them, or changes direction. This works fine for vertical portals, but not so much for horizontal portals that the player should jump through. Walking left and right while standing on top of a horizontal portal would, obviously, trigger it. Because of that, I had to gut out the map exit checking routines to work on only a given orientation at a time. Additionally, I had to separate the logic between disabling the triggering of exits to be orientation independent. Now map exiting is a bit more sensical and acts how you would expect it to.

I finished up some more framework code for maintaining the master object list and the "for this map only" list generation. So far it seems to be working out alright, but I've only tested it with a single map that is just set up to appear on any map without preference.

Currently I have a makeshift object class that is a bit of a hack. That said, it was simple enough to throw some code at the player class and have everything work out correctly. Performing the collision against objects from the player's view was pretty simple. It was cool to be colliding with an awesome red bounding box on the screen. In addition to that, I did a simple prototype test of the ability to push objects. While the pushing only worked when moving toward the right, it was really cool to see it in action. When pushing the object over a ledge, that object would fall and collide with the ground. I have yet to deal with the object colliding horizontally with the map or other objects.

What I'd really like to do is allow for objects to determine just how fast they move when pushed according to their "weight." This system could be extended to allow multiple objects to be (or not) pushed simultaneously in a line. There's a bit of class structure design that's going to go into this, so I'll be working those details out before I go create a full fledged implementation of these type of collidable, pushable objects.

I've bounced back into coding after thinking about a whole bunch of things that needed to be implemented. One of the major things that I was thinking about was making objects in the game world persistent. That is, when they are moved from one map to another, that will be remembered. Additionally, I need some way to keep track of which NPCs have been made happy, and which have not. My original thoughts about how object placement was going to work would be in the editor, and then saving out that information to each specific map. When I pulled back a little bit and thought about that, it was obvious why that approach wouldn't work.

I haven't approached this specific problem before, so it's nice to be developing something new to me for a change. The technique I'm planning on using is as follows: I will have a global list which will contain pointers to all "world objects". On loading of a map, I will zip through that list and find objects that "belong" to the given map. Those will be stored in a separate list which, in turn, will be processed each logical loop by the map itself. If an object is moved from one map to another, it's internal reference to the map name will be modified -- so then on map transition, when the process is repeated again, the object will simply appear in the correct place.

The major gruntwork of this entire system is having some way to serialize and deserialize all "world objects" from the master list to a file. In layman's terms, I need a way to store all the object information when the user decides to stop playing, or save their progress. What it boils down to, really, is that every individual world object is going to have to have save and load functions. On top of that, said functions need the ability to read from an already open file pointer as opposed to simply opening a file pointer. Why? That's simply because I don't want to be writing individual files for each object. They need the ability to store at any arbitrary point in a file pointer so that I can simply have a single file containing all of the information I need.

In addition to being able to save and load there's also the requirement of being able to signal which types of objects to instantiate. So, in addition to writing themselves, objects will need to write some identifier as to what their type is, so upon loading I can instantiate the correct objects and call their load objects on the open file pointer.

Lastly, and unrelated to that whole scheme of object persistence: I did a little cleanup and fixed some improper usage of the STL Map type. I was previously using indexing to obtain information as to whether a specific key existed, which was incorrect. Now I'm properly using the find() function. While the old method worked fine, it was not the correct method of doing a query; and required a bit of hackery to make work properly (when searching via index, if the index does not exist, a null pointer is returned. That, however, then makes it appear that such an index does exist, when in fact it should not).

It's been a few days and those people who have played through the little test walkaround demo haven't had any major issues. If anything, there were minor little hiccups when it comes to the rendering/playback of music -- the portion of the game that there are no controls over whatsoever. In the end there will be some options that can be changed for those who prefer performance over quality, etc.

I'm taking some time out from coding to get a little bit more design specced out before moving on to the next stage. I want to create a list of the major puzzle elements to the game since most of that is currently floating in my mind as of right now. It'll be good to get those down into a more formal format.

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.