Looking back at my last post about basic scenes you will see that I plan to implement a lot of basic functionality in my classic arcade game frame work. Another feature that I would like to implement is a simple transition engine.

What is a transition engine?

When you change from one scene to another in a Pulpcore applet it does a straight out swap between the two scenes. The old scene is gone and the new scene is shown. It would be nice to do some thing a little bit more fancy, say a side swipe, color fade or other nifty transition effect. This is where the transition engine would come in.

My basic design is to make a new scene called the transition scene. The transition scene would take a parameter of Itransition. Itransition would be an interface that individual classes could implement to allow them to be used as a transition.

In my current prototype I have implemented a very simple transition engine in this manner. My transition interface look like the following:

public interface ITransition
{
   void initialize(Scene2D scene);
   boolean update(int elapsedTime);
}

As you can see the interface is pretty simple. There are only two method on the interface. And initialize that takes a scene object. This is so the transition can add sprites and groups to the current scene so it is able to draw them. The other is an update function. This lets the transition be called every game loop to update the transitions progress, when the transition is complete it can signal this by returning a false flag.

The transition scene is also quite simple.

public class TransitionScene extends Scene2D
{
   private ITransition transition;
   private Scene nextScene;
 
   public TransitionScene(ITransition transition, Scene nextScene)
   {
      this.transition = transition;
      this.nextScene = nextScene;
      transition.initialize(this);
   }
 
   public void update(int elapsedTime)
   {
      if(!transition.update(elapsedTime))
      {
         Stage.setScene(nextScene);
      }
   }
}

So you can see that the transition scene takes and instance of an object that implements the Itransition interface and then every game loop tells the transition to update it's self and then inform it if the transition is complete. When the transition is complete it then sets the stage to the new scene.

What would an implemented transition look like?

A transition could look like any thing as long as it implements the Itransition interface. I believe this will make it flexible enough to create nearly any transition effect I can think of.
I currently have a single transition effect, it is a fade the current scene to a color effect.

public class FadeToColorTransition implements ITransition
{
 
   private FilledSprite background;
   private ImageSprite foreground;
   private int duration;
 
   public FadeToColorTransition(CoreImage image, int color, int duration)
   {
      background = new FilledSprite(color);
      foreground = new ImageSprite(image, 0, 0);
      this.duration = duration;
   }
 
   public void initialize(Scene2D scene)
   {
      scene.add(background);
      scene.add(foreground);
      foreground.alpha.animate(255, 0, duration);
   }
 
   public boolean update(int elapsedTime)
   {
      boolean continueTransition = true;
      if(foreground.alpha.get() == 0)
      {
         continueTransition = false;
      }
 
      return continueTransition;
   }
}

So from the code you can see the transition effect is quite short but still pretty powerful.

It takes the following parameters on construction. A CoreImage object which is generally a screen shot of the scene you are transitioning away from, a color to fade the image into and a duration in milliseconds for the fade to take place over. The transition then animates the alpha of the image to fade out over time and blends it with the colored background to generate the fade effect. When the image alpha is at 0 the effect is over and the transition returns a false.

An beneficial side effect of implementing the transition effects in this way is that you can make as many of them as you want. When you run the Ant build script in release mode it will run the Progaurd build action. One of the things Progaurd does is strip out any unused code so only the transitions that you actually use will make it the end jar file. This results in a smaller jar, less time spent waiting for the jar file to download and a better user experience when the player wants to try your game.

In Pulpcore applets are made up of a collection of scenes, scenes are where you group together common details to implement a screen. For example the code to fetch and then display the games current high score table could be contained in a single scene. The applets scenes are then played out on the applets Stage object. Like a play at the theater the applet will have one stage and can have one or more scenes.

For my classic arcade game clones I will have a set of basic scenes that will be the same for all the cloned games. Each of these scenes will be written in a generic fashion so that each game built from this common framework of scenes will be able to quickly configure the games details like titles, high score tables and then focus on implementing the actual arcade game code.

There are several common scenes that will be shared across all the arcade games.

Loading Scene
The loading scene is where the applet will decide on which asset file to download based on the users locale. After downloading the applicable asset file it will then transition to the main title scene.

Title Scene
The title scene will display the tile of the arcade game and the main menu. The main menu will consist of the following options.

• Play Game
• Highscores
• Language
• Credits

Play Scene
The implementation of the actual arcade game.

Highscore Scene
Connects to the web server, fetches the latest high scores and displays them to the player.

Language Scene
Lets the player select the language they would like the game displayed in. This scene will then take the user back to the loading scene so it can load the newly selected languages asset file.

Credits Scene
Displays a big thanks to all the people who have helped out.

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.