There isn't much to report. Since the latest fixes to the jumping I still have yet to have it tested to see what kinds of impovements are noticed by players. As of right now I have packaged them up and will be distributing the new build to a few friends to test out and see if any of the kinks they mentioned with the previous jumping code are now, in fact, worked out.

Jumping is now, for the most part, implemented. This is usually a stickler point for me, as it's quite difficult to emulate the type of jumping I usually envision in my mind. Even if I am able to, everyone has their own preferences on how jumping should "feel." This first iteration has, at least in my opinion, enough hang time to feel suitably natural. Of course, I won't be able to truly test it out until I create some maps to run around on that actually utilize it properly.

In implementing the jumping code, I noticed that the code which checks whether the player is falling or not was not behaving properly. To the player, it was doing everything it should: if there was nothing under the player, they would fall--otherwise, they wouldn't. Unfortunately, on the code side the player was almost always considered to be falling (even when they shouldn't have been), and just happened to be ejected out of the ground before the next logic/drawing loop. This is not how I wanted things to perform! Now the code checks properly whether the player should be falling or not, and sets the status accordingly. This little problem actually led to the jumping feeling sticky: that is, when pressing the jump button it didn't always perform the jump. This is because in order to jump the player could not be in the falling state. As you can see, the previous fall check code posed a few problems for the jumping.

So, jumping is working out well. I've noticed through using Beeboxer to produce the bounding boxes for the player sprite that some changes need to be made. Most specifically, putting together functionality for using the same bounding box across all frames on a sprite is imperative. Currently, because of my imprecision in drawing the bounding boxes, it's possible to have the player be ejected into the nether when standing near a wall. Since the bounding box expands as the frames of the sprite are drawn, they end up within a blocked tile on the map. This, in turn, shoots the player out the top, because the player believes they are "in the ground." One of the other remedies for this problem is to implement proper ejection code when the player has found themselves in a wall. This is also something I will be doing, even if it is unnecessary when the bounding boxes are properly constructed. There are a few movement types that I want to add to the player that could potentially allow them to insert themselves into a wall, and proper ejection would be required in such a case.

In coupling the player's interaction with the map (mostly just collision detection at this point), the need came for the concept of a "camera" in order to pan the map while keeping the player in the appropriate position on the screen. In the past, I've taken different approaches to the camera to what I've implemented this time. The camera code is essentially complete, and handles very nicely. Instead of tying the player and the map too closely together, I am using the camera to decide how far the map should be offset.

In order to do this, I allow the camera to have a specific target. Originally, the camera was set on the player, but I decided that in the long run I would like the cam to focus on more than just the player itself. My original plan was to have hard-coded targets that the camera would be able to be set to. This was a pretty reasonable approach seeing as how I currently only have one object that can be targeted: the player. After giving it a bit of thought, there was an easy answer to making the camera's targeting capabilities much more robust. Instead of hard-coding targets, I allow for any "camera targetable" object to be the target of the camera. What does this mean?

Using the goodness of inheritance, I simply created a base class that has the special property which deems it targetable by the camera. By deriving from this base class, an object can be passed to the camera as a target and update the cameras coordinates depending on the specifics of the type of object itself. Unfortunately, this doesn't make drawing of the actual targeted objects on the screen very easy. When an object is not a target of the camera, things are simple: if it's within the camera's boundaries, then draw it; otherwise, don't. When the object is the target of the camera things are different. For instance, consider the player. When the player is the target of the camera, we have to deal with the following classic scenario: when the player is at the edge of the map, we move the player to the edge of the screen. When the player is in the middle of the map, and not near the boundaries, the player should be drawn in the middle of the map while it scrolls (simulating movement).

All of this special drawing of the objects themselves on the screen while they are the target of the camera is the only downside of this mechanism. Thankfully, however, I may be able to abstract the common behavior just described for what will probably be the majority of objects that may be targeted by the camera (if at all).

All in all it's a pretty great system. It's an incredible leap ahead of what I did in Fruit of the Loomsoft for switching the camera between the Apple character and the Blueberry character. Looking back at FotLS, the camera work seems incredibly forced and hacked together. I suppose that makes sense since it was for SpeedHack!

Happy new year, everyone!

Making archives for a month with only two postings in it is quite disappointing. What is incredibly unbelievable, though, is that loomsoft has been around for 5 and a half years. This is just absolutely incredible. I would, of course, liked to have put out more than just the games that are available today--but there are more pressing matters in life than leisure game development!

All of that said, there is some news regarding progress. I've taken my current project idea a few steps further and have fleshed out most of the tilemap capabilities. I've thrown together a basic player class and have it interacting with the map in the most rudimentary fashion. Most of what I've done so far is the basic tilemap construction, which is more or less the same type of framework every time I do any kind of tile mapped project. I have gutted a lot of useful stuff from Fruit of the Loomsoft, inserting new (and better) code here and there. So far I haven't done anything editor-wise, and have just been hardcoding test map files that I simply dump to file with a function call. It fills my need of a test area to move around on for now.

So far, I haven't done anything novel or new. I'm simply rebuilding a tile engine (something I've done far too many times at this point).