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.