So I though I would post up my work in progress clone. It is about 80% finished at this point and is an actual playable arcade clone.

So what made it to this first release?

• Player movement.
• Player lives and death.
• Asteroids, movement and splitting.
• Scores.
• Sound effect for most actions.
• Multi language support via Google Translate
• Flying Saucers

So what is yet to come?

• Online high scores
• Player explosion animation
• Small flying saucers shooting needs to target the player
• Play testing and tweaking

Since the list of things not in the game does not stop it from being playable I have decided to do a release now and see if I can get any feedback on it. I will release the source code to Asteroids after I have finished up the remaining items on the to do list.

So for now you can have fun and give Asteroids v0.11 a bash.
Play Asteroids

ShareThis

A simple step by step tutorial with some screen shots, source code and Ant build script included.
An example Java applet can be seen here Hello world demo
The source code can be found here Hello world source code

ShareThis

In Asteroids the player controls a triangle shaped space ship. The basic controls are rotate left, rotate right and accelerate in the direction the spaceship is currently pointed.
The spaceship will then continue to travel in the direction it is pointed at as long as the engines are still on. Once the engines are turned off the spaceship will slowly come to a halt.
If the player pilots the spaceship off the edge of the screen it will reappear on the other side.

So on paper this all sounds pretty easy. The question is how do we program this behavior?
There are several properties we will need to keep track of to enable us to make our spaceship move as described above. They are as follows.

Thrust
We the player activates the spaceships engines it generates thrust. This variable controls how fast the spaceship will accelerate when the engines are activated.

Maximum Thrust
If the amount of thrust is not capped the players spaceship would continue to accelerate as long as the engines are active. This variable will allow us to place a cap on the maximum speed the player can move at.

Rotation speed
The player can rotate their spaceship, this variable places a cap on how fast they can rotate left or right.

Friction
In Asteroids there is a friction component to the players movement. If the engines are turned off the player will drift for a short distance before coming to rest. This variable controls how fast the player slows down if they do not have the engines running.

X and Y Velocity
These variables control how fast and what direction the players spaceship will move in the current game update. They are calculated from the rotation variable, thrust variable, maximum thrusts variable and the friction variable.

So the basic flow of calculating the players movements are
If the engines are on:
Calculate the current x and y velocities.
Cap the x and y velocities if they are greater than the allowed maximum thrust
Else
Apply friction to the spaceships current x and y velocities.

Move the spaceship by the current x and y velocities.

If the spaceship has left the bounds of the screen:
Wrap the spaceship to the other side.

Calculating the current x and y velocities
Calculating the current velocities can be achieved by constructing a right angled triangle and using
Pythagorean theorem to solve for a hypotenuse with a length of 1 unit. To make this a bit easier to explain I have whipped up a quick diagram in paintbrush.

The red triangle is our spaceship.
The pink arc is our current rotation.
The black line with the arrow is our hypotenuse with a length of 1 unit.
The blue line is the length we ant to solve for our x velocity.
The green line is the length we want to solve for our y velocity.

Pythagorean theorem for a right angled triangle states that the sine of the angle of our spaceships rotation will equal the length of the blue line divided by the hypotenuse.
Since our hypotenuse is 1 we can simplify it in this case to the length of the blue line is equal to the sine of the spaceships rotation.

So to calculate our x velocity for 1 unit we simply do x velocity = sine(rotation)

For the y velocity it is a very similar deal except instead of the sine we use the cosine.
Again our hypotenuse is 1 and we can simplify the equation down to y velocity = cosine(rotation)

We have now calculated the x and y velocity for 1 unit of travel. Since our spaceship is moving on a screen 1 unit of travel is 1 pixel. Moving by 1 pixel every game loop if not that fast. So we simply multiply them by the thrust value. Which will give us the following.

x velocity = sine(rotation) * thrust
y velocity = cosine(rotation) * thrust

So we can now work out the velocity for the thrust for the spaceships current rotation. However we are missing one more part before we can use these velocities. They have not taken into account what velocity the spaceship is all ready moving at. Imagine that you fly up the screen and turn the engines off. The spaceship will gently continue to coast up the screen. You could then rotate the ship to point down and fire the engines. It would instantly take off down the screen instead of slowing down and then start to accelerate down the screen.
Luckily this is very easy to take into account. We simply add the new velocities to the old velocities.

Old x velocity += sine(rotation) * thrust
Old y velocity -= cosine(rotation) * thrust

Notice that I have subtracted the new y velocity from the old velocity. This is because computer screens have the (0,0) location in the top left hand side and not the bottom left hand side. So to go up you need to use subtraction and to go down you need to use addition.

The next step is to cap the maximum speed of the players spaceship.
This is step is easy.
If x velocity > maximum thrust:
x velocity = maximum thrust

If y velocity > maximum thrust:
y velocity = maximum thrust

If x velocity < -maximum thrust:
x velocity = -maximum thrust

If y velocity < -maximum thrust:
y velocity = -maximum thrust

Applying friction to a drifting spaceship is also very easy too.
x velocity = x velocity * friction
y velocity = y velocity * friction

Finally updating the players position and then wrapping the players spaceship around the screen is a simple task of checking if they have crossed a screen boundary and if so setting them to the other side.

x = (x + xVelocity);
y = (y + yVelocity);

if(x < 0)
{
x = getWidth();
}

if(x > getWidth())
{
x = 0;
}

if(y < 0)
{
y = getHeight();
}

if(y > getHeight())
{
y = 0;
}

Finally if none of the above made any sense you can check out a basic demo of the ideas in action below. You will need Java installed to play it. The left and right arrow key rotate the space ship and the up key turns the engines on.
The full source code is also provided. You will need to download the Pulpcore API to build it. I used version 0.11.3 for this example. Asteroids Movement Source Code

Play the Asteroids Movement Demo

ShareThis

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.

ShareThis

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.

ShareThis

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.

ShareThis

I have been researching Java frameworks to help with the cloning of Asteroids. Since my main focus is on cloning classic arcade games, it makes sense to use a framework that will take care of the details concerning rendering graphics, collecting player input, playing sounds and managing game assets. My research has led me to this great Java applet library called Pulpcore. It handles all of the basics needs for a 2d rendered game implemented as a Java applet. In short Pulpcore makes a great boiler plate for my arcade game clones.

Even tho I am going to use a third party library for the graphical rendering, sound and input all the clones will run in a similar manner and it make sense to reuse as much of that code as possible. This leaves me to design a basic clone framework built on top of Pulpcore to handle loading the right assets, displaying generic menus, high score entry and display screen. This then frees me to focus on cloning the game play for each arcade game and not rewriting the same high score table five times.

I have started to flesh out the main classes and interactions in the framework by creating some quick prototypes and using UML to model the ideas generated. I recommend StarUML for drawing UML diagrams. It is free, open source and works great for me.

I will post some more details on the framework design as I complete it. If you are thirsty for more Asteroids information you can read the Asteroids Overview and the Asteroids Specification

ShareThis

Each of the classic arcade games that I clone will feature the following.

An overview of the game. A gameplay and features specification describing what will be cloned. A web playable arcade game implemented as a Java Applet and finally the source code to the clone will be released as an open source project so that other game developers can learn from my cloning attempts.

I will strive to make each arcade game clone look, sound and play as close to the original as able. Since these clones are being built from scratch an exact replica will not possible but they will remain faithful to the original game. If exactness is what you are after then you should probably check out an arcade game machine emulator like MAME

Well lets get this show on the road and clone some classic arcade games!

ShareThis