Monday, 14 September 2015

Making Audio go private

Today I have been working on getting my Audio system implemented, mostly in order to keep the Activity Lifecycle happy- ie ensuring that media is paused, resumed and released appropriately. The initial implementation I made was an Audio class which was built up of static methods, each able to do a specific function, and if necessary call each other to use pre-existing functionality. The class worked, and is in a small project not a bad model, but I have been reading up on ways to setup a game View and it seems that the Audio class needs to be less public.

Honestly, my first reason for making methods static was that I read that using getters and setters was potentially heavy on resources, but in further reading I have found that for my audio needs this won't be an issue.

The main root of my game framework is now a base activity which is able to create and switch between views, the views themselves after a little experimentation are now extensions of the SurfaceView, and are able to take a pre-initialised Audio instance as a parameter. What this does is allow the main activity to set up the audio environment in one place, passing in itself for context rather than having the Audio being setup in the beginning of a new "screen".

The audio environment is now also much more encapsulated, and as such should only be passed to one screen and any reference will be lost as that screen dies. The activity itself can also ensure that the correct settings are in place for the audio-stream, should the app framework be used for other app types.

The project I have been working on is a soundboard which emulates the character select screen of Mortal Kombat 3, a childhood favourite of mine. So far I have been able to load the 15 game characters names and corresponding "introduction" speech files from the game, and I have it set up to play a random one from this list and display the name on each touch event.
The names themselves exist in an array which is organised in the order that the game presents them on the screen, however it may be necessary at a later date to have them sorted alphabetically- which we will do if needed. One string array (in the strings.xml resource) holds these names, and another array holds the filenames for the audio files in the same order. The reason I have kept the two seperate instead of trying to parse one array into an audio filename, is that I am able to localize the name strings and they will still line up with the sound files whose names are written in english. While the game characters names are the same in any language, it may not be the same in character based languages, and if I ever work on supporting those it would be great to not have to rewrite my audio file loading.

There are probably many other ways to link the names in an array to specific sound files but for now this seems to be the simplest and works well for this project.

The next step will be to load in a music track to loop in the background and then I can begin working on graphics!

No comments:

Post a Comment