Lots has been done since last week (which, I guess wasn’t even an update.). The basic physics and controls of the game are done, along with level building. I may tweak the player’s movement a bit but as for now I’m pretty comfortable with it.
We are still looking for some neat mechanics to throw into the game, having a jetpack is fun enough as it is, but the game lacks a defining mechanic that sets it apart from the crowd.. I’m twiddling with the idea of implementing real physics into the game (like, with boxes and everything!). Just the idea of it makes me giddy, so it could very well be something we do.
My last experience with Box2D (a physics engine) didn’t go so well. It felt a little hard to implement, but that was about a year and a half ago. Today I played around with APE and found it surprisingly easy to implement. If I remember correctly, in Box2D you needed to structure your game around the engine, having your core class extend “World” or something. In APE it’s much more simple, and hopefully it won’t interfere with FlashPunk.
I’ve got a lot done in the game so far, so I tried to capture it all in one screenshot:
This was both a pain and quite a bit of fun to implement at the same time. I’m currently using Tiled to manage my levels, because I feel that since there is already a great, capable editor out there, why shouldn’t I use it?
Now, Tiled has 5 options for ways you can output raw tile data:
- Base64 (uncompressed)
- Base64 (gzip compressed)
- Base64 (zlib compressed)
Originally, I was using XML. The raw tile data altogether weighed in at a whopping 14,691 bytes, or 14.7kb! Now, with modern storage and how cheap it is, this really wouldn’t be too big of a problem, but remember, this level was fairly small (see previous picture). If you had 100 levels that were double the original size of this level, the raw tile data of the levels in your game would weigh in at 2,938,200 bytes (or 2.93MB)! That is quite a bit or data for only levels.
After coming to the realization that XML would take up a bit more space than needed, I attempted to switch over to Base64 compressed with zlib. However, I came across a few obstacles, the first of which was that the majority of the Base64 decoders I used either:
- Did not work, or
- Were clunky, or not exactly the easiest to implement.
Eventually, I found that Steve Webster’s Base64 class worked pretty well. Thank goodness! But alas, my triumph was short-lived. For some odd reason, Tiled exports the raw unsigned integers backwards.
So a uint with the value 1 that should look like:
This caused quite a big problem, because a tile with the value 1 would be essentially shifted over 31 bits to the left, and it would cause the number read by the game to be very big. After some twiddling around I found out how to reverse a ByteArray, and it all worked out pretty well.
The original tile data for XML was 14,691 bytes large. Now that I am compressing it and then using Base64, the new size is only 152 bytes! Give a big hand to the makers of the Tiled editor on that one!
Not too much interesting here. As you can see in the picture I posted of the in-game level earlier, I added some poorly-drawn backgrounds. You can’t see it now, but there is a faint parallax effect when you move, which gives the level a much more dynamic feel.
Although they add a really nice atmosphere to the level, I feel like having mountain backgrounds just doesn’t fit the type of gameplay that we are going to have in this game. Some levels can be incredibly large, or some relatively small. What I need is a background that can work for all sizes. For example, The Company of Myself just used a plain sky background with minute detail if I remember correctly.
What will end up here is probably just a dirt background to give the impression of being underground, or a sky-blue background.
So, I knew from the start that smoke coming from the jetpack would be a really nice effect to add to the game. Althought it’s not really an essential ‘engine’ feature core to the gameplay, while working on games it’s always nice to allow yourself a small amount of time to polish a specific feature.
At my first try of implementation, I did not realize that FlashPunk had a Emitter class, that emits particles, so I tried to write my own smoke trail. Man, did it suck! Even without holding the space bar down to long, the game would drop to about 20FPS for some people.
Next, I tried to use a Particle Emitter from the FlashPunk forums that someone had made. Still, not much better.
After some tweedle-dee’ing and tweedle-dumb’ing, I finally found out that FlashPunk has that previously mentioned Emitter class, and boy does it work swell! I get a solid FPS with a nice little smoke trail. All is well!
Camera / Intro
Another interesting project I did was a little introduction for each level. Originally, the levels would only have one layer, the “regular” layer. This regular layer had the player spawn, blocks, and all that fun stuff.
Now, since the levels are so big and almost always surpass the size of the screen (800×600(I think?)), I wanted a way to introduce the player to the level, so they can see all the neat stuff and get a general feel of where they are going. I figured that having built-in tiles that the game reads and then tweens the camera to would look good, and it would avoid the pain of having to hard code every camera position in (like having properties in the map).
Now what if I want to place one of these ‘camera tiles’ on top of any other tile? Well, because we only have one layer, it would overwrite that tile. What I ended up doing was adding a second layer called “specials”, and reading that separately. The outcome is a nice smooth tweening from point to point.
That’s about it for this week, thanks for reading! Merry Christmas and Happy (belated!) Holidays!