All of the classic arcade game clones will have certain assets they need to load for the game to run. My main goal is to abstract the loading of game assets away from the calling code.

One reason for this abstraction is games are often constructed with placeholder assets. When the final asset is ready you can simply link the asset into the games build, update any mappings in the resource loader and it will be changed consistently through out the rest of the applet. As an added bonus if designed right it would make the internationalization of the applet easier.

So how doe we achieve this goal? Well first we must take a look at how Pulpcore handles game assets and work within it's boundaries. Luckily for us Pulpcore handles assets in a very straight forward and easy manner. Game assets are either loaded from the jar file or from an assets catalog. The assets catalog is generally populated from a compressed zip file that the applet downloads at run time.

So how does the applet know which assets go where and what files to download?

Well in a Pulpcore applets source tree there is a folder called res. Under the res folder there are two more folders called jar and zip. It is here that the applets resource assets are held.

When a developer starts the build process using the default supplied Ant build script the applets resources are processed depending on which folder they are contained in. All the assets in the res/jar folder are packaged up in the final resulting jar file with the rest of the applets class files. All the assets in the res/zip folder are packaged up into a compressed zip file.

When you write a Pulpcore applet you get the option to automatically load this zipped up asset file or override the existing loading scene and hand pick which asset file to load.

After the assets have been loaded using them in an applet is simply a case of calling the static load function on the asset type that you want to create and passing it the folder and file name of the asset.

Now we have the general background and some understanding on how Pulpcore handles asset files. We are now able to focus on how to abstract the loading of an individual asset from the rest of our applet.

My approach is to have a class dedicated to the loading of resources. It shall be called the resource class. The resource class will provide functions for loading each type of asset available, for example it will provide a method for loading CoreImage, CoreFont and Sound objects. These load functions will take an enumeration type named after the type they enumerate for example ImageResource, FontResource and SoundResource. The resource class will also have a mapping of the enumeration type to a specific directory and filename. This mapping will be implemented as a ResourceBundle.

Why do we need to map the enumeration type to a resource bundle?

My goal here is to make the mapping easy to find, easy to change and also be easy to internationalize. By using a resource bundle we can provide different assets based on locale in the same compressed zip file and have the correct asset loaded for the players locale. For example you may have spoken phrases played in your applet. You would want and English player to hear the English phrases and the German players to hear the German phrases. You would be able to have both in the same zip file and have the resource bundle mappings pick the correct files to load and thus the applet would play the correct language.

If your asset files are small then having all your internationalized assets in the same zip file is probably an acceptable solution with out negatively impacting on your players overall experience with your applet. However if you make extensive use of sound effect, images and other assets for your internationalization then you will not want to make your player wait as the game downloads several megabytes of data they will never use. The solution? I would recommend breaking apart the assets into a common base and then several zip files that contain the differing assets for each locale. At load time you would be able to load the base assets, discover the players locale and pick the appropriate localized asset file to download. This could be quickly implemented as a second overridden loading scene. By labeling each loading scene to keep the user informed of the loading process you would still be able to provide an acceptable end user experience.

How would you implement the resource file splitting in a easy to use way?

I think the best solution would be to have folders under the main zip file that would provide a tree structure for each localized asset file. Then update the Ant build script to build the assets in this way. Unfortunately at this point my Ant skills are not up to scratch to tackle this task, when the time required to manually generate the localized assets file becomes prohibitive I will learn Ant build scripts and automate the process.

So there you have it, a quick brain dump on abstracting resource loading away from the calling code to allow for easier use of place holder assets and internationalization.