Level System Infrastructure

This week's work has been put into the level system.

On the technical side, levels are now loaded from an external file. In retrospect it may have been better to keep them as xml files and let the system parse them into objects as I load each level. Sadly, I did not consider that option a few months ago when I sat down and wrote my own parser. Seeing as I already have a written parser. It does not seem like there would be much benefit from moving to xml based levels at this point. So the levels file is just a simple text file with a string representation of levels.

On the functional side, the levels menu can now hold an infinite(ish) number of levels and is scrollable. This was my first chance to implement gestures. it took some doing but I'm quite pleased with the results. Basically, when a touch event occurs, I mark its location, when it moves I calculate its distance from the original point. If it is above a certain threshold, I interpret it as a swipe. Otherwise it’s a click (on a level button).

Naturally the graphics for the level menu is, like all the game's graphics, in the placeholder/programmer art stage. Once I'm satisfied with the level of the content in the game the art work will begin. (i.e., still a long way down the line).

On the content side, a tutorial level for the new element (fan) has been created. This brings the current level count to 19. Next I will be adding another element that goes hand in hand with the fan, and then some more level design work. I also have some plans for an interesting graphical enhancement, but that one I'll keep secret till it’s done.

New element: the fan.

It's been a while since a new element was introduced, and so I'm proud to present, the fan !

Seen in this screenshot on the left side is a red fan. Fans operate in a fairly obvious way. When active, they propel any pachinguy in their range upwards. When non active they do nothing. Fans present some interesting interactions with other elements of the game. For example : When the blue bridge above the fan is lowered, it blocks the fan's updraft, making the pachinguy fall onto the bridge. Retractable blocks affect the updraft in a similar manner. Triggers can now be activated from below, and so on.

On a technical level, the fan is the first time I've used animated sprites in pachinguys. (Both for the actual fan and the updraft animation, represented in this screenshot by the black w's). Their implementation in Andengine seems fairly straight forward and intuitive. So they easily integrated into the existing code.

Some infrastructure work has gone into the game. Mainly, we now have a layer system that allows me to keep tighter control of the order of drawing (anything on the bottom layer gets drawn first, then the second layer, etc..). I've also moved all the blocks into "block containers", which allow me to attach visual effects (like the updraft animation) to them. Those effects inherit their block's location but not its rotation, color, visibility etc.. This lays the ground work for more elaborate graphics to be added.

I still have another element in mind (one that really takes advantage of fans). And after that I will go back to designing levels. As my updraft w's plainly show, I need help when it comes to art. so I will also be looking for a graphics/art person.