Tunnels and components infrastructure

I've started laying down the foundations for real graphics. The first (of many, many steps to come) was to add "tunnels" between portal entrances and exits. The tunnels are currently represented by lines, but once the line texture is replaced with an actual tunnel drawing it should look OK. The tunnels are created somewhat randomly at the beginning of the level. So that each time you load a level its tunnels are slightly different. This has no effect on gameplay and is just for the visual sake. Tunnels may overlap and intersect freely (if more than one portal pair is present in the level). Right now they look like this:

On an unrelated note, I've recently come across this article, and the problem described in it was one I know all too well. So I've taken some time to implement the components architecture it mentioned. Turns out it was rather simple to implement. Right now I don't think I'll refactor pachinguys to use it. In terms of functionality and gameplay pachinguys is very nearly done, so my benefit from refactoring would be minimal. But I do believe my next project will be based on this components architecture.

Next I intend to focus on creating more levels using the new fan and upside down triangle elements. Keeping in mind the request for more difficult levels I received from my "beta testers".

Upside down triangles and demographics speak

Today's new element is what was expected the moment the fan was introduced: Upside down triangles! They operate similarly to regular triangles, when touched from the bottom, they push the Pachinguy that hit them to the side. When touched from the top they provide a resting point for Pachinguys (like pegs and other solid blocks). Seen here at the top of the "pyramid":

In other news, after a visit to a family gathering, I have renewed faith in the project. Children as young as 9 years old quickly figured out how to play and had lots of fun (according to them). They also found a couple of bugs (now fixed). So it was win win for everyone involved.
The major "complaint" I received was that there need to be more difficult levels. To which my reply can be summed up with: challenge accepted!

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.

Engine Port Success !

The title says it all. After the disaster revealed in the last update, I have been slaving away at moving the entire game to the more stable andengine. This android specific open source game library works differently then what I'm used to (Specifically, it forces onto the project a scene2d like approach, where every screen is a scene with game elements attached to it as children).

After getting myself up to speed with this new library and methodology, I got down to the process of transferring the game screens and logic. At this point most of the old functionality has been regained.
We now have a working screen/scene transfer system. A loading screen, the level menu screen, the play screen and the results/score screen. The main menu and credits screen will be added back at some point.

On top of that, a new machine element is now in development, its full function and details will be revealed at a later post. But yeah, it’s awesome.

Here you can see how the game looks on the new engine. It’s fairly similar (which is good). The pink highlights are the areas where touch events are registered for both the guy-spawner (top middle) and the actual pachinguys. Clearly the "art" is very much in the placeholder stage. That will also change as work on the project continues.