n3wt0n!

The previous picture really doesn’t show off the backdrop layer manager, so here’s a video.

If you’d run the previous demo, you would have noticed that whenever you pressed jump, the hero would jump as high as he could, every time, no matter whether or not you held the jump key or simply tapped it. I’ve fixed that, so a tap results in a slight hop.

Edit: I finally found the link to the article that this effect is based on.

The backdrop layer manager is nearing completion. It’s functional at the moment, but doesn’t yet sort the background images in order of ascending width (important).

The following picture does not do it justice, but it shows off 4 images, layered accordingly.

So once again, I thought I’d work on the backdrop layer manager. I didn’t get anything done with it. There’s something about attempting to work on it (and I don’t think it would be difficult to code), but there’s something about it that makes me work hard on something else.

I had this little problem lurking around at the back of my mind. I wanted a simple way of specifying where our hero starts in the level. Up to now I had just been dropping him in the top left of the level (position 10,10).

Not any more. I’m using the Tiled editor’s “group” layer, as you can see.

There’s that “ACTORGROUP” layer, that holds the location of the Hero, and later on will tell G2DP where to create the NPCs. Notice the little orange box labelled “Player”.

That gives us easy hero placement.

To avoid confusion with the term “background”, I’m deciding to call the background image of G2DP a “backdrop”. The potential for confusion is in regard to my naming convention of tiles in the Tiled map editor.

I have decided that the maps created in Tiled, and used in G2DP, require three layers. That is a requirement. One layer named “PLATFORMS”, one layer named “FOREGROUND”, and one layer named, you guessed it, “BACKGROUND”.

You do not necessarily have to put any tiles in the foreground or the background. The map renderer just looks for it, and I think it’s a good property for a two-dimensional platform map to have. Like a bald guy with “hair colour” on his drivers license.

The “background” of the Tiled map relates to just the individual tiles that the hero does not come in contact with. Therefore, “backdrop” refers to the screen’s background. I’m not trying to step on any toes, but that seems less confusing for me.

Today started out with the intention of coding a backdrop layer manager, but the plan quickly diverted to fixing the hero’s “wiggle walk”. What is a wiggle walk, I hear you ask? Ever see a kid playing with paper cut-outs glued to a popsicle stick? That’s what I’m calling a wiggle walk. I’m foregoing any player walking animations for a (more charming?) rotation of the hero’s image. I can’t make it work in print, so you’ll have to see for yourself soon enough.

And in case I piqued any interest about the “backdrop layer manager”, it’s just a system of rendering layers of images in such a way that an illusion of depth is added to the background. It simulates the same sensation as when you are driving down a country road and, off in the distance, you see a barn slowly travel across your field of view. But along the side of the road, fence posts zoom by at the speed of the car.

There was a nice article and demonstration in Flash that I found a while back. I can’t find it, though.

I’ll leave you with a nice screenshot of what is the beginning of the backdrop layer manager.

Each of the tiles pictured below are 32 pixels wide by 32 pixels high. Regardless of whether or not the images make up one long platform, or a curvy one, etc, each 32×32 pixel tile had a 32×32 pixel “body” associated with it. In this sense, a body is the “physical” object represented in a Phys2d world. Static bodies make up the world, because they don’t move. Other bodies, such as the red box I’ve pointed to, can move and are subject to gravity and physics. But I’m getting ahead of myself.

Earlier this week, I ran into a problem with the hero getting stuck between tiles. Now, he didn’t fall between them, he just simply stopped moving as if he were colliding with a wall. This was no good, as he was simply walking along a flat surface. This may be a small limitation of the Phys2d engine, but I am certainly not complaining. The solution was actually pretty simple.

Rather than create n number of bodies for n number of tiles, I scan the world and create one long, stretched body for the entire span of adjacent platform tiles. This does not cut down the number of bodies to the bare minimum, as I have a feeling I may be able to subtract the platform tiles from a much larger body, and then invert the values when the scan is done. Still, counting the number of bodies above, the static bodies, the ones that never move, I see 18. That’s certainly a lot fewer than even the number of tiles used in only the first 5 lines of the map.

Now the hero has flat surfaces to walk on and the number of bodies to keep in memory have been reduced.

Source code snippet/solution found here on the Slick forums.