Boss fights? Boss fights.

My dear girlfriend mentioned that 60 levels of straight progressive puzzles can get somewhat repetitive. Others have mentioned this to me before, but she helped come up with a good solution: Boss fights. 

The basic idea is that every 20 levels or so the regular flow of puzzles will be interrupted by a special level that introduces unique mechanics and a greater challenge. These levels will be harder, faster, and more exciting than the usual flow of the game, while still using the core puzzle components introduced until that point. 

Seeing as boss fights are rather challenging, I will most likely add a "skip" button to them, as my main demographic may be a bit too young to handle that level of challenge. I will have to have these levels beta tested by as many people as possible, but I believe they are a great addition to the game. 

So far two of the planned three boss fights have been designed and implemented. the third will be the final level of the game and as such requires more time to plan and execute (your ideas are always welcome). 

These snapshots demonstrate the first two bosses, both of them keep the Pachinguys from reaching their goal in some way, and both create interferences in the Pachinguys way, which represent the first and probably last place where randomness will exist in the game. 

The development names for these bosses are hydra and runner. Hydra shoots fireballs from its many heads and runner shakes the world when he jumps and shoots lasers from his eyes (that last one may be changed to something that makes more sense when graphics and story are considered). 

With two more levels built and a third "taken" for the final boss I am less than 10 levels away from a complete game (including challenge levels, not including graphics and sound).

Generic Tutorial System

I've finally gotten around to implementing the tutorial system. It’s been a challenge as I've decided to make it as general as possible. But it turned out great.
It has three major components:

1) Hooks: places within the system that initiate some form of tutorial interaction. For that end I've created a new block type, the tutorial block, which is invisible, numbered, and calls the tutorial system when a guy passes through it. I've also added a hook on the start and finish of levels. 

2) Strategy: as part of a strategy pattern. The behavior of the tutorial system relies on interchangeable strategies. These strategies can be swapped according to the level being played to allow separation of the logic of different levels strategies into separate strategy objects. Currently only one level needs a tutorial but my goal was a general system so I've taken the time to implement it properly. 

3) Core tutorial system: this system is responsible for providing the methods for the strategies for placing tutorial overlays and hints on the game scene.
This system went through several design iterations. It started as a regular class. Became a singleton (first implemented as a java enum but later changed for several reasons). Until finally it became a truly stateless component (once the strategy pattern was in place) and thus implemented as a static class, much like the sound system.
The final product can be seen in these screenshots (the light gray blocks are the tutorial blocks, only drawn for debugging, will be invisible in the release version):

Tutorial overlay with placeholder graphic
explaining the players' goal.

A tutorial hint explaining
a specific game mechanic.

The main focus for me in the tutorial design is to minimize the use of writing. It serves the double benefit of avoiding the need for localizations, and opening the game for non readers (young and casual gamers). 

I'm very proud of the way this system turned out. It was a lot of work but it now feels right, is very open to enhancements, and is flexible enough to be used in future games as well.

Animation and sound infrastructures.

It’s been a while since new code went into Pachinguys. I've spent my time creating two infrastructure systems that will become increasingly important as time progresses, handling animation and Sound.

Animation system: contains mappings from animation names to their corresponding animated sprites, so, in essence I can just say "play the Pachinguy idle animation now" and have all the details abstracted. Every animation object gets its location, rotation, visibility etc. from a single parent sprite that serves as the model. So the existing static sprite system (the squares and circles) can be used as parents. In time every static sprite will have an animation object attached to it, and the static sprites will be made into Entities (all the data qualities of sprites but non drawable), so only the animations will remain. Andengines implementation of scene graph made this system very easy to implement.

Sound system: the sound system maps sounds and music to names. So again I can just say "play background_music_1 now" and have the details abstracted. It differs from the animation system in its implementation though. The sound system is static. Meaning there is only one "instance" of it in the entire game. This is because playing, for instance, two background tracks, at the same time, makes no sense. Having a single entry point for sound and music enables me to easily keep track of how many sounds are playing, and avoid noise clutter.

I found Andengines sound and music support to be lacking. The main issue was the lack of ability to check if a certain sound has finished playing (required to avoid playing the sound over itself). There is even no way to get the duration of a sound. Android's native MediaPlayer resolved that issue as it provides both duration and completion getters. For now both Andengines and native androids schemes are supported, only Andengines is currently used. This may change as the needs of the sound system become clearer (haven't really thought about sound until now to be honest :) ). 

the next thing on the agenda is some research into how Andengine handles asset resolution for different screen sizes (the 32X32 pixels textures used for the phone version would get stretched beyond recognition on a tablet so some way to use bigger textures will need to be found). Sadly it seems that Andengine bypasses the native android resource system which does exactly that, hopefully it has some other trick up its sleeve for this purpose. And of course the final levels still need to be designed.

A new twist on an old elemnt

After taking a while to clear my mind with some side projects, I've returned to the development of Pachinguys. A second "beta test" session with the kids in my family showed a positive response to the tunnel lines I've added since the last session. Hopefully the level design push will be done soon and I'll have some time to add more graphical enhancements like this. At the very least the plan is to bring the "guys" to life, give them some idle and active animations, and some reactive sound as well.

As the level design process grinded to a writer’s block type halt. I've decided to take a fresh look at my game elements to see what can be improved. The results are: Triggered portals. They are functionally similar to regular portals, but they also have a cover that enables/disables them, triggered according to their color as usual. A covered portal does not react with passing guys at all. And an uncovered portal reacts like a regular portal. A closed green portal can be seen in the picture below.

You may have also noticed that retractable blocks have been graphically changed a bit. This is also in response to some tester feedback (mainly saying the old graphics were too unclear). While the entire sprite scheme will change eventually, it’s still better to have clearer temporary graphics for testing purposes.

Some tweaks to the existing movement engine had to be made to enable portals that were opened when a guy was already on them to function properly, as this situation could not happen with any other block type until now. (Retractable blocks would only alert passing guys to changes in their state when they were above or below them to avoid guys getting "trapped" by retractables opened on them.
These tweaks open the door for other possible block types that may use this interaction type. Which may or may not be used as the creative process and level design continues.

One more element idea remains to be implemented if the current elements are not sufficient to complete my 60+10 level goal. So I'm now confident that the level goal will eventually be reached. As long as work and life distractions stay out of my way long enough.

Bugs in motion

I've spent time listening to some interesting indie game presentations and one sentence really stuck with me: "content is what kills you as an indie". Considering I've spent the better part of my development time on Pachinguys levels. I can definitely relate. Luckily as the effort of level making continues I find myself creating levels that push and abuse the underlying engine. And as a result flush out many new bugs for me to squash. This week saw two "game breaking" bugs fixed. Both relating to the interplay of fans, portals and triggers:

- When stepping off a peg where a) updraft is present and b) a portal is just below the Pachinguy. The Pachinguy now floats up instead of teleporting (see the situation in the attached image).

- If said Pachinguy then hits a trigger from below, and losses his updraft, the trigger now un-triggers correctly (previously the trigger would think it’s still active).

As you can see I've taken the call for harder levels to heart, doing my best to create complex, non obvious levels. So while, yes, content is the major bottleneck in Pachinguys. I'm quite pleased with how it’s progressing. I continue to stand my ground against automated level generation and introducing "just for one level" mechanics. I do believe I will reach my 60-10 level goal without breaking these guidelines. I may choose to introduce one or two new components to the "machine" but as for now the currently available components provide me with plenty to work with.

Faster level creation infrastructure.

Many technical improvements were made this week. The entire level creation and testing process was streamlined to allow for faster level creation. The level file parser was made a bit stronger and the blog received a tiny addition.

to recall, the way things worked was that the editor ran in debug mode only, dumping its output (the actual level) as a string to the console, where I would copy it and transfer it to the hard coded levels file. Clearly this was very cumbersome and required switching between the editor project and the game project, and recompiling the game, just to see the level in action. Any changes to the level after its initial design were done either by recreating it in the editor or, more commonly, by manually altering the level string, and would again require a recompile of the entire game.

In an effort to make this process more efficient, the editor is now a standalone file. Just small enough to be sent by mail to wherever I happen to be. It now dumps its output to a file. I then transfer this file to a specific folder on my testing device by USB. The game is now able to translate this file into a playable level (in fact, a menu of many playable levels), without needing to recompile. What this means is that I no longer need my development environment to create and test new levels. Wherever I have a computer with internet access and a USB cable I can create levels. (Of course, I would never create levels when I should be working, that is not the point of this update at all).

Levels created in this way are not classified (story/challenge) and instead exist in the new "testing" level menu. When I'm happy with the new design, I transfer the complete level to the hard coded levels file (either the story levels file or the challenge levels file). Recompile, and only then is it considered a part of the final game. The entire level testing infrastructure would be removed from the final version.

While I was enhancing the game's level file parser to handle the new external file, I took some time to strengthen it a bit more. Now level files can have line comments (any line starting with an * is considered a comment line). Also a level string no longer has to define its par (how many guys are required to finish it). If a level does not specify its par, a very large default par is used.

One of the newly designed levels

The next step in this process would be to enable the editor to read in a level file to allow for editing of preexisting levels. This step would be rather time consuming so I'm delaying it for now. When beta testing of levels comes around and changes to existing levels becomes a common activity I'll likely have to get around to it. But, for now, the system is good enough.

In addition to all that, several new levels have been designed. And a new level counter was added to the blog. I will update it from post to post to reflect the level design progress. So stay tuned.