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.

The Libgdx Disaster

As I've mentioned before, when I started work on Pachinguys I had no android device to test on. This led me to use libgdx. The claim libgdx made was that it can create parallel desktop and android games. And testing the desktop version often and the android version rarely should be enough. Sounds good right?

Wrong. I've sunk a few months into Pachinguys so far. Testing on the pc and the android emulator. Both of these worked flawlessly. However, I've recently acquired a brand spanking new galaxy s3. Naturally I proceeded to test Pachinguys on it. And then, disaster:

After running the game, the touch screen crashed, the apps manager crash, the entire machine ran slower and slower until it froze and I had to give the whole thing a factory reset.

Following this incident I did what any programmer would do. Googled the problem. However since libgdx is still in development and the community leaves much to be desired, the web gave me no answers. And so I started breaking apart my code to find the cause of this catastrophic breakage. However the only code I've written deals with the internal logic of the game. Nothing device specific (libgdx was supposed to cover that). And so after a few days, some advice from other programmers and many attempts to salvage the project. I've decided to give up on libgdx.

The good news is, now that I have a device to test on I’m no longer limited to libgdx. I'm now in the process of moving Pachinguys to a more stable engine. This will take some time naturally. And so updates may be scarcer in the coming weeks. But work does continue. Pachinguys lives on!

Current Pachinguys state and some of my early work

Development on Pachinguys is going strong. There are now 16 complete levels. Utilizing the existing elements and their combinations to create challenging puzzles is a time consuming process. but it is the kind of creative work that makes game development so much fun.

I started developing games at a very early age, from simple microsoft-form based "games" made in VB during my army service, to making prototypes in flash using AS2 and some basic HTML. to games written in C# using XNA for the PC. And now a JAVA game for the PC and Android. 

Here is a video example of my early work. It's a prototype called Color Walkers.

Color Walkers is a unique puzzler. The player controls three "characters" (represented as circles). One red, one green, one blue. The locations of these characters determines the color of the background. (Using the RGB color base). There are solid platforms, on each level, that the characters can't pass through. However, once the background is the same color as a platform. The platform essentially "blends" into the background and becomes non solid. The goal is to get all three characters to the right side of the screen. The video demonstrates the mechanics and a full solution to a single level.

I've also added here another video of a new level of Pachinguys. Just to give a taste of things to come.