If you have landed on this page from a search engine you should first view part 1 of this platform game tutorial. This is going to be a very busy and varied tutorial. We will learn the theory of the Singleton design pattern. We will then be introduced to another of the classes of the Java Collections, HashMap in which we will see how we can more efficiently store and make available the wide variety of bitmaps that are required for this project. We will also get started on our new and improved Transform class, code the first of the component-based classes, code the all-new Camera class, and make a significant start on some of the more familiar classes, GameState, PhysicsEngine, Renderer, GameEngine, and more besides.

Here is a list of what to expect and the order to expect it.

• The Singleton pattern
• The Java HashMap class
• The memory problem and the BitmapStore
• Coding a basic Transform
• Coding the block-based component classes
• Creating the game levels
• Coding a stripped-down GameObjectFactory
• Coding the GameState
• Coding the SoundEngine
• Coding the PhysicsEngine
• Coding the Renderer
• Explaining and coding the Camera class
• Coding the HUD
• Coding the UIController
• Coding the Activity
• Coding the GameEngine
• Coding a stripped-down LevelManger
• Running the game for the first time

By the end of this chapter, we will see the game in its first runnable state!

Throughout the course of this chapter, there will be loads of errors in Android Studio because so many of the classes are interconnected and we can’t code them all simultaneously. Note also that when there is an error in an interface file (and there will be) attempting to implement that interface will also cause an error in the implementing class. Stick with it until the end of this chapter as it all comes together, and we will see the first results on our screens. Be sure to read the information box at the top of chapter 22 as well as the one below for the quicker copy-and-paste approach you might like to take.

If you want to copy and paste the code read this next information box.

Feel free to copy and paste these classes if you prefer. All classes go in the usual folder except where I specifically point it out (for Level based classes). Be aware that my domain name is used in all the package names in the download bundle. The first package declaration in all the files will probably auto-update to your package name when you paste them into your project. However, when the import code refers to the packages that we have created …GOSpec (in the previous chapter) and …Level (later in this chapter) you will probably need to change the domain name and possibly the project name manually in some or maybe all of the files that import …GOSpec and …Level.

If you want to type everything then you will just need to add a new class of the correct name by right-clicking the appropriate folder and selecting New | Java Class.

Let’s talk about another pattern.

The Singleton pattern

The Singleton pattern as the name suggests is a pattern that is used when we want only one of something. And more importantly, we need to absolutely guarantee we only have one of something. The something I refer to is an instance of a class. Furthermore, the Singleton pattern is also used when we want to allow global access to some of its data or methods. The class can then be used from anywhere within a project and yet is also guaranteeing that all parts/classes of the project that access the class are using the exact same instance.

Part of the Singleton conundrum is simple. To make parts of it available to any other class you simply make the methods public and static.

But how do we guarantee that only one instance can ever be created? We will look at the code next but as a look-ahead what we will do is create a class that has a private constructor. Remember that a private method can only be called from within the class itself. And a public and static method that creates an instance then returns a reference- provided an instance has not already been created- and if it has then a reference to the existing instance is returned. This implies that the class will hold a reference to its own instance. Let’s look at this with some sample code.

The Singleton code

Here is the class declaration and it contains just one variable. A private and static instance of an object that is the same type as the class itself.

class SingletonClass {

private static SingletonClass mOurInstance;

}

The name of the class is not relevant just that the name of the class is the same as the type being declared.

Next, we can look at the constructor method.

private SingletonClass() {

// This is only here to prevent instantiation

}

It has the same name as the class as do all constructor methods but note it is private. When a method is private it can only be called by code within the class. Note that depending upon the needs of the project, it is perfectly acceptable to have some code in the constructor, just as long as the constructor is private.

This next method is default access and returns an object of type SingletonClass. Take a look over the code.

// Calling this method is the only way to get a BitmapStore

static SingletonClass getInstance(Context context) {

if(mOurInstance == null) {

    mOurInstance = new SingletonClass();

}



return mOurInstance;

}

As the class is default access, any code in the same package can call the method. In addition, because it is static, it can be called without an instance of the class. Now look at the code in the body. The first line checks whether the private member, mOurInstance has been initialized with if(mOurInstance == null). If the object has not been initialized (is null) then the private constructor is called, and the instance is initialized. The final line of code returns a reference to the private instance. Also note as will be the case in the platform game, it might not even be necessary to return an instance.

Now we add a method that actually does something. After all, a class must have a purpose.

Static void someUsefulMethod() {

// Do something useful

}

Note the previous method, someUsefulMethod is static so it too, like getInstance can be called without a reference to the class. This is why I said the getInstance method doesn’t necessarily have to return an instance of the class.

Next, we add another method. Note that it is not static.

void someOtherUsefulMethod() {

// Do something else useful

}

As someOtherUsefulMethod is not static, an instance of the class would be needed in order to call it. So, in this specific case getInstance would need to return a reference to the object.

Now let’s see how we could use our new class in some other class of our project. First, we declare an instance of SingletonClass but as we cannot call the constructor we initialize it by calling the static getInstance method.

SingletonClass sc = SingletonClass.getInstance();

The getInstance method will check whether the member SingletonClass object needs to be initialized and if required calls the constructor. Either way, getInstance returns a reference to the private member instance of SingletonClass which initializes sc.

Now we can use the two methods that actually do something useful.

// Call the static method

SingletonClass.someUsefulMethod();



// Call the other method

sc.someOtherUsefulMethod();

The first method, someUsefulMethod is called without using a reference because it is static. The second method is called using the sc reference we initialized using getInstance.

It might surprise you to learn that the Singleton pattern is controversial. Its very use is discouraged and even banned in some situations. There are a number of reasons for this but in one-person or small-team projects, many of the objections are either not relevant or much less relevant. Android Studio even has a way to auto-generate a singleton. If you are interested in a discussion about the use of the Singleton pattern then a quick Google will bring up strong condemnations, spirited defenses, and even heated arguments about its use. I suggest you read this article because it gives a fairly balanced view of Singleton and from a game development perspective. http://gameprogrammingpatterns.com/singleton.html. Note that the article discusses Singleton in the context of a different programming language, C++ but the discussion is still useful.

If you are going for an interview for a programming job very soon you need to read the previous paragragh. Otherwise, enjoy your Singletons.

Next, we will learn about the Java HashMap class and then we will get to code a Singleton for real.

More Java Collections – Meet Java Hashmap

Java HashMaps are neat. They are part of the Java Collections and a kind of cousin to ArrayList. They basically encapsulate really useful data storage techniques that would otherwise be quite technical for us to code successfully for ourselves.

We will get practical with HashMap in the next section when we discuss a problem regarding storing Bitmap instances in our GameObject instances. HashMap will be the second part (Singletons are the first part) of the solution to this problem.

I thought it would be worth taking a first look at HashMap on its own.

Suppose, we want to store the data of lots of characters from an RPG-type game, and each different character is represented by an object of type Character.

We could use some of the Java tools we already know about like arrays or ArrayList. However, Java HashMap is also similar to these things but with HashMap we can give a unique key/identifier to each Character object and access any such object using that key/identifier.

The term hash comes from the process of turning our chosen key/identifier into something used internally by the HashMap class. The process is called hashing.

Any of our Character instances can then be accessed with our chosen key/identifier. A good candidate for a key/identifier in the Character class scenario would be the character’s name.

Each key/identifier has a corresponding object, in this case, it is of type Character. This is known as a key-value pair.

We just give HashMap a key and it gives us the corresponding object. No need to worry about which index we stored our characters, perhaps Geralt, Ciri, or Triss at, just pass the name to HashMap and it will do the work for us.

Let’s look at some examples. You don’t need to type any of this code just get familiar with how it works.

We can declare a new HashMap to hold keys and Character instances like this code:

Map<String, Character> characterMap;

The previous code assumes we have coded a class called Character.

We can initialize the HashMap like this:

characterMap = new HashMap();

We can add a new key and its associated object like this.

characterMap.put(“Geralt”, new Character());

And this:

characterMap.put(“Ciri”, new Character());

And this:

characterMap.put(“Triss”, new Character());

All the example code assumes that we can somehow give the Character instances their unique properties to reflect their internal differences elsewhere.

We can then retrieve an entry from the HashMap like this:

Character ciri = characterMap.get(“Ciri”);

Or perhaps use the Character class’s methods directly like this:

characterMap.get(“Geralt”).drawSilverSword();

// Or maybe call some other hypothetical method

characterMap.get(“Triss”).openFastTravelPortal(“Kaer Morhen”);

The previous code calls the hypothetical methods drawSilverSword and openFastTravelPortal on the Character class.

The HashMap class also has lots of useful methods like ArrayList. See the official Java page for HashMap here: https://docs.oracle.com/javase/tutorial/collections/interfaces/map.html.

Now we can use HashMap for real. Before we do let’s look ahead in this project and we will see that we have a bit of a memory problem.

The memory problem and the BitmapStore

In all the projects on this website so far, the class representing the object in the game also held a copy of the Bitmap.

When we have just one or a few of each object as we did in previous projects this is not a problem but, in this project, we will have more than a hundred of some of the Bitmaps representing the tiles that make the platforms. At best this is inefficient and will waste memory, and device power and make the game run more slowly and at worst (especially on older devices) the game will crash because it has run out of memory.

We need a way to share Bitmap instances between objects. This suggests a central store. Hey; what about that HashMap and that Singleton thing we just learned about? How convenient.

Coding the BitmapStore class

All our game objects already have a specification that holds the name of the required Bitmap in a String. We have also just learned how we can store objects in a HashMap and retrieve them using a key. In addition, we know how to make a class available to all other classes using the Singleton pattern.

What we will do is code a Singleton class called BitmapStore which will hold all the required Bitmap instances using the bitmapName String (from the graphics-based component classes). We will however only store one of each Bitmap.

When the initialize method of the graphics-related component class executes instead of initializing its own Bitmap it will call the addBitmap method of the BitmapStore class. If the Bitmap in question has not already been added to the HashMap then it will do so. When the Bitmap needs to be drawn (during the draw method) each object will simply call the getBitmap method of the BitmapStore class. The BitmapStore, as we will see, will have two HashMaps, one for the regular Bitmap instances and one for reversed instances. The BitmapStore class will also have a getReversedBitmap method.

Create a new class called BitmapStore, and add the following members and the constructor as shown next.

import android.content.Context;

import android.graphics.Bitmap;

import android.graphics.BitmapFactory;

import android.graphics.Matrix;

import android.graphics.PointF;



import java.util.HashMap;

import java.util.Map;



class BitmapStore {

private static Map<String, Bitmap> mBitmapsMap;

private static Map<String, Bitmap> mBitmapsReversedMap;

private static BitmapStore mOurInstance;



// Calling this method is the only way to get a BitmapStore

static BitmapStore getInstance(Context context) {



mOurInstance = new BitmapStore(context);

return mOurInstance;

}



// Can't be called using new BitmapStore()

private BitmapStore(Context c) {

mBitmapsMap = new HashMap();

mBitmapsReversedMap = new HashMap();



// Put a default bitmap in each of the maps

// to return in case a bitmap doesn't exist

addBitmap(c,

"death_visible",

new PointF(1, 1),

128,

true);

}

}

There are three private members. Two HashMaps called mBitmapsMap and mBitmapsReversedMap. They will hold all the Bitmaps and reversed Bitmaps (when an object requires it) respectively. Notice that they use a String as the key and of course a Bitmap as its pair.

The third and final private member should be as expected. It is an instance of BitmapStore itself as discussed in the Singleton pattern. And, also as should be expected the constructor is private. It cannot be called from outside of the BitmapStore class.

As expected with the Singleton pattern we have a static getInstance method that calls the BitmapStore constructor if it hasn’t done so already and then returns a reference to the one and only instance of the class.

Inside this constructor, the two HashMap instances are initialized and the addBitmap method is called. We will code the addBitmap method shortly so there will be an error because the method doesn’t exist yet. It is worth explaining the details of this call now, however.

If you look at the arguments in the call to addBitmap you will see, we pass in the Context (c), a PointF containing a size (which will allow addBitmap to scale the Bitmap) a somewhat arbitrary value of 128 and a boolean with a value of true.

The value of 128 is a value that has been predetermined as the number of pixels on the device which represents one meter of the game world. If the game world is to be scaled by our soon-to-be-coded Camera class, then it needs to know what to scale it to. When you see the Camera class later this chapter this will be clearer.

The final boolean indicates whether a reversed copy of the Bitmap is required as well.

We mentioned in the previous chapter while exploring the graphical assets that the death_visible graphic is for creating an inescapable wall around the level which will kill the player if touched. This helps avoid bugs like the player falling out of the level and then tumbling for eternity through space. The graphic is noticeable, so the level tester can clearly see that he has sufficiently wrapped the level during the development phase and then before the game is released it can be replaced with a blank graphic so that only the background is visible, but the player is still contained within where the level designer wants him.

All the other calls to addBitmap will be made by the initialize method within the graphics-related component classes.

Now add the getBitmap and getBitmapReversed methods.

static Bitmap getBitmap(String bitmapName) {



if (mBitmapsMap.containsKey(bitmapName)) {

return mBitmapsMap.get(bitmapName);

} else {

return mBitmapsMap.get("death_visible");

}

}



static Bitmap getBitmapReversed(String bitmapName) {



if (mBitmapsReversedMap.containsKey(bitmapName)) {

return mBitmapsReversedMap.get(bitmapName);

} else {

return mBitmapsReversedMap.get("death_visible");

}

}

All that these methods do is receive a String and then return the Bitmap that matches the key. The return statements are wrapped in an if-else block so that when a Bitmap does not exist the death_visible Bitmap is returned. This might at first seem odd. When we see how to lay out level designs we will see that we specifically have a way of adding these death_visible objects. And we will specifically request the death_visible Bitmap when it is required. By returning the death_visible Bitmap as a default, when we neglect to add a Bitmap the death_visible Bitmap will appear within the level when the game is tested, and we will know we have a Bitmap missing. In addition, it will prevent the game from crashing as it would if an uninitialized Bitmap was returned.

Add the addBitmap method shown next.

static void addBitmap(Context c,

String bitmapName,

PointF objectSize,

int pixelsPerMetre,

boolean needReversed) {



Bitmap bitmap;

Bitmap bitmapReversed;



// Make a resource id out of the string of the file name

int resID = c.getResources().getIdentifier(bitmapName,

"drawable", c.getPackageName());



// Load the bitmap using the id

bitmap = BitmapFactory

.decodeResource(c.getResources(), resID);



// Resize the bitmap

bitmap = Bitmap.createScaledBitmap(bitmap,

(int) objectSize.x * pixelsPerMetre,

(int) objectSize.y * pixelsPerMetre,

false);



mBitmapsMap.put(bitmapName, bitmap);



if (needReversed) {

// Create a mirror image of the bitmap

Matrix matrix = new Matrix();

matrix.setScale(-1, 1);

bitmapReversed = Bitmap.createBitmap(

bitmap,

0, 0,

bitmap.getWidth(),

bitmap.getHeight(),

matrix, true);



mBitmapsReversedMap.put(bitmapName, bitmapReversed);

}



}

The addBitmap method should look quite familiar by now. The code loads the Bitmap from the String representing the Bitmap’s name. The Bitmap is scaled in the usual way using createScaledBitmap. The only difference to what we saw in the graphics-based component classes of the previous project is that the size of the object and the value representing the pixels-per-metre is used to determine the size.

The Bitmap is added to the HashMap and if a reversed copy of the Bitmap has been requested then the Matrix class is used to create a reversed copy and the Bitmap is added to the HashMap for reversed Bitmaps.

Add the clearStore method shown next.

static void clearStore() {

mBitmapsMap.clear();

mBitmapsReversedMap.clear();

}

The clearStore method does two things. It first uses the clear method of the HashMap class to empty the mBitmapsMap HashMap and then does the same thing for the mBitmapsReversedMap HashMap. This is needed because typically each level will use a different selection of graphics files and if you don’t clear them then every time the player attempts a different level they will be left with unnecessary bitmaps in the store.

To be realistic about this, it really wouldn’t matter even for a very basic device to have every single bitmap loaded at once- it’s still way more efficient than we have been up until now as we used to load a bitmap for every instance of every game object. But if you added more levels and more object specifications then eventually your game would perform poorly so it is good practice to clear the store before loading the required bitmaps for the current level. This is the purpose of this method.

Coding the basic transform

In this project, we will do a better job of the Transform class. In the Scrolling Shooter project, the Transform was packed full of variables and methods that many of the objects didn’t need. It served its purpose to prevent the project from getting even bigger and we got away with it because there was a limited number of objects in the game.

What we will code now is a very simple version of the Transform and it will contain only the members and methods needed by all game objects. When we need a Transform that does more specific things we can then extend this class and add the required extra members and methods.

Add a new class called Transform. Code the member variables and the constructor as shown next.

import android.graphics.PointF;

import android.graphics.RectF;



public class Transform {

RectF mCollider;

private PointF mLocation;

private float mSpeed;

private float mObjectHeight;

private float mObjectWidth;

private PointF mStartingPosition;

private boolean mHeadingUp = false;

private boolean mHeadingDown = false;



private boolean mFacingRight = true;

private boolean mHeadingLeft = false;

private boolean mHeadingRight = false;



Transform(float speed, float objectWidth,

float objectHeight,

PointF startingLocation) {



mCollider = new RectF();

mSpeed = speed;

mObjectHeight = objectHeight;

mObjectWidth = objectWidth;

mLocation = startingLocation;



// This tells movable blocks their starting position

mStartingPosition = new PointF(

mLocation.x, mLocation.y);

}

}

The members should look quite familiar and self-explanatory. We have a RectF to represent the collider (mCollider), PointF instances for the current location and the starting location (mLocation and mStartingPosition), float variables for speed, height, and width (mSpeed, mObjectHeight, and mObjectWidth), and boolean variables for each direction the object could be heading.

In the constructor, all the variables representing position, size, and speed are initialized. All the values come from the method’s parameters. We will see later in the chapter that the GameObjectFactory class will have access to all the specifications needed for a level and will instantiate all the Transform instances by passing the data we have just seen to the Transform constructor. Just as it was in the previous project except this time GameObjectFactory will have more than one type of Transform to choose from.

Code updateCollider and getCollider methods are shown next.

public void updateCollider() {

mCollider.top = mLocation.y;

mCollider.left = mLocation.x ;

mCollider.bottom =

(mCollider.top + mObjectHeight);



mCollider.right =

(mCollider.left + mObjectWidth);

}





public RectF getCollider() {

return mCollider;

}

The updateCollider method uses the position of the object along with its width and height to make sure the collider is up-to-date so that collision detection can be done on its precise position. The getCollider method makes the collider available to the PhysicsEngine class so collision detection can be performed.

Add this bunch of getters and setters shown next.

void headUp() {

mHeadingUp = true;

mHeadingDown = false;

}



void headDown() {

mHeadingDown = true;

mHeadingUp = false;

}



boolean headingUp() {

return mHeadingUp;

}



boolean headingDown() {

return mHeadingDown;

}



float getSpeed() {

return mSpeed;

}



PointF getLocation() {

return mLocation;

}



PointF getSize() {

return new PointF(

(int) mObjectWidth,

(int) mObjectHeight);

}

Although quite a long list the methods we just added are quite simple. They allow the instances of the Transform class to share and set the values of some of its private member variables.

Add these getters and setters next.

void headRight() {

mHeadingRight = true;

mHeadingLeft = false;

mFacingRight = true;



}



void headLeft() {

mHeadingLeft = true;

mHeadingRight = false;

mFacingRight = false;

}



boolean headingRight() {

return mHeadingRight;

}



boolean headingLeft() {

return mHeadingLeft;

}



void stopHorizontal() {

mHeadingLeft = false;

mHeadingRight = false;

}



void stopMovingLeft() {

mHeadingLeft = false;

}



void stopMovingRight() {

mHeadingRight = false;

}



boolean getFacingRight() {

return mFacingRight;

}



PointF getStartingPosition(){

return mStartingPosition;

}

These are the final methods for the Transform class. They make available to get and set, more of the members of the Transform class. Familiarize yourself with the method names and the variables they work with.

Coding the inanimate and decorative components

In the previous tutorial, we coded all the interfaces for our component classes. We coded GraphicsComponent, UpdateComponent, and InputComponent. Now we will code the three simplest component classes that will be enough to complete quite a few of our specifications.

Let’s start with the DecorativeBlockUpdateComponent.

DecorativeBlockUpdateComponent

The update-related components all implement just one method, update. Add a new class called DecorativeBlockUpdateComponent, implement UpdateComponent and add the empty update method as shown next.

class DecorativeBlockUpdateComponent implements UpdateComponent {

@Override

public void update(long fps,

Transform t,

Transform playerTransform) {

// Do nothing

// Not even set a collider

}

}

Yes, the update method is meant to be empty as the decorative objects don’t move or collide.

InanmiateBlockGraphicsComponent

Add a new class called InanimateBlockGraphicsComponent and add the code shown next.

import android.content.Context;

import android.graphics.Bitmap;

import android.graphics.Canvas;

import android.graphics.Paint;

import android.graphics.PointF;

import android.graphics.Rect;



import com.gamecodeschool. platformer.GOSpec.GameObjectSpec;



class InanimateBlockGraphicsComponent

implements GraphicsComponent {



private String mBitmapName;



@Override

public void initialize(Context context,

GameObjectSpec spec,

PointF objectSize,

int pixelsPerMetre) {



mBitmapName = spec.getBitmapName();



BitmapStore.addBitmap(context,

mBitmapName, objectSize,

pixelsPerMetre,

false);



}

}

Note the highlighted import might need correcting if you are copying and pasting the class files.

Notice that despite this being a graphics-based component there is no Bitmap object, just a String to hold the name. The class implements the GraphicsComponent interface and therefore must provide the implementation for the initialize and draw methods.

In the code you just added you can see that it receives the required data in the parameters of the initialize method then retrieves the name of the Bitmap from the GameObjectSpec reference.

All the method needs to do is pass all the data on to the addBitmap method of the BitmapStore class and all the work of initializing a Bitmap and storing it for later use (if it hasn’t already) is taken care of by BitmapStore. Just note that the name of the Bitmap is retained in the mBitmapName member variable so InanimateBlockGraphicsComponent can later access the Bitmap again using getBitmap.

Add the draw method to the InanimateBlockGraphicsComponent as shown next.

@Override

public void draw(Canvas canvas,

Paint paint,

Transform t,

Camera cam) {



Bitmap bitmap = BitmapStore.getBitmap(mBitmapName);

// Use the camera to translate the real world

// coordinates relative to the player-

// into screen coordinates

Rect screenCoordinates = cam.worldToScreen(

t.getLocation().x,

t.getLocation().y,

t.getSize().x,

t.getSize().y);





canvas.drawBitmap(

bitmap,

screenCoordinates.left,

screenCoordinates.top,

paint);





}

Inside the draw method, the getBitmap method of the BitmapStore class is used to initialize a local Bitmap object. The Bitmap is drawn to the screen in quite a standard way using drawBitmap but before it is drawn the Camera reference cam is used to get the coordinates at which to draw this game object.

Remember that all game objects have world coordinates. The game objects don’t know or care anything about the device’s screen resolution. The Camera class (in the worldToScreen method) does a calculation based on the position of the camera to translate the object’s world coordinates into appropriate screen coordinates. As we will see later in the chapter, the camera follows the player. So as the player moves through the game world the camera adjusts where on the screen (if anywhere) the game objects get drawn.

InanimateBlockUpdateComponent

Now add a new class called InanimateBlockUpdateComponent and code it as follows.

class InanimateBlockUpdateComponent

implements UpdateComponent {



private boolean mColliderNotSet = true;



@Override

public void update(long fps,

Transform t,

Transform playerTransform) {



// An alternative would be to update

// the collider just once when it spawns.

// But this would require spawn components

// - More code but a bit faster

if(mColliderNotSet) {

// Only need to set the collider

// once because it will never move

t.updateCollider();

mColliderNotSet = false;

}

}

}

The class implements UpdateComponent and therefore has an update method. It has one member variable, a boolean called mColliderNotSet. In the update method, the mColliderNotSet boolean is checked to test whether the updateCollider method on the Transform needs to be called. The boolean is then set to false to save a few CPU cycles for the rest of the game. As this object will never move in the game world (although it will move on the screen relative to the camera) this single call to updateCollider is sufficient.

Now we have completed three components we can make some levels that have objects that use these components.

Creating the levels

Before we make some levels let’s create another new package to put them in. As a reminder from the previous chapter, when you create a new package, it is important to do so in the correct folder. The correct folder is the same one that we have been putting all the Java files in throughout this book. If you called this project Platformer it will be the app/java/yourdomain.platformer folder.

In the Android Studio project explorer, right-click the app/java/yourdomain.platformer (NOT yourdomain.platformer(androidTest) or yourdomain.platformer(test)), select New | Package and  name it Levels.

The step of creating a package is essential before you can copy and paste the class files.

We will now add some classes that will define all the layout of the levels of the game starting with a generic Level class which all the others can extend.

Don’t add this code yet, just glance at the different letters and numbers in the layouts that will represent different game objects.

// Backgrounds 1, 2, 3(City, Underground, Mountain...)

// p = Player

// g = Grass tile

// o = Objective

// m = Movable platform

// b = Brick tile

// c = mine Cart

// s = Stone pile

// l = coaL

// n = coNcrete

// a = lAmpost

// r = scoRched tile

// w = snoW tile

// t = stalacTite

// i = stalagmIte

// d = Dead tree

// e = snowy trEe

// x = Collectable

// z = Fire

// y = invisible death_invisible

Now let’s see the actual levels comprising the letters and numbers starting with the base class.

Level

This class is really short. It will just be used as a polymorphic type, so we can use the extended classes in common code.

Create a new class called Level and add the following code.

package com.gamecodeschool.c22platformer.Levels;



import java.util.ArrayList;



public abstract class Level {

// If you want to build a new level then extend this class

ArrayList<String> tiles;

public ArrayList<String> getTiles(){

return tiles;

}

}

Change the highlighted package statement if copying & pasting

That’s it. It just has an ArrayList called tiles to hold all the game objects and a getter called getTiles which unsurprisingly returns a reference to the ArrayList.

LevelCity

We have already seen these next couple of images in the previous chapter. They are shown again here for completeness. Copy the LevelCity file from the Chapter 23/Levels folder of the download bundle. It is not recommended that you try and manually add the code. Paste the file into the Levels folder/package of your project in the Android Studio project explorer window.

This is what the level looks like at the end of the project while the camera is zoomed-out.

Next, add the Montains level.

LevelMountains

Copy the LevelMountains file from the Chapter 23/Levels folder of the download bundle. It is not recommended that you try and manually add the code. Paste the file into the Levels folder/package of your project in the Android Studio project explorer window.

This is what the level looks like at the end of the project while the camera is zoomed-out.

Now for the final level.

LevelUnderground

Copy the LevelUnderground file from the Chapter 23/Levels folder of the download bundle. It is not recommended that you try and manually add the code. Paste the file into the Levels folder/package of your project in the Android Studio project explorer window.

This is what the level looks like at the end of the project while the camera is zoomed-out.

I spent quite a bit of time designing and testing the City level. It should be quite challenging and possible to keep replaying and improving on your best time. The Mountains and Underground levels I quickly threw together for the sake of showing how the level structure works and how easy it is to have multiple levels. They are intended as a project for the reader to improve or perhaps start again from scratch.

Coding a stripped-down GameObjectFactory

The next step is to code the GameObjectFactory class. This class will look very similar to the class of the same name in the previous project but there will be a few differences that I will point out. We will code just enough in order to build the game objects that are ready to be built and we will revisit this class in the next chapter once we have finished coding all the component classes.

In this and other upcoming classes remember to check that when you import your own classes (everything from the GOSpec package) make sure/change to the correct package name.

Add a new class called GameObjectFactory and add the following member variables and constructor method.

import android.content.Context;

import android.graphics.PointF;



import com.gamecodeschool.platformer.GOSpec.GameObjectSpec;



class GameObjectFactory {

private Context mContext;

private GameEngine mGameEngineReference;

private int mPixelsPerMetre;



GameObjectFactory(Context context,

GameEngine gameEngine,

int pixelsPerMetre) {



mContext = context;

mGameEngineReference = gameEngine;

mPixelsPerMetre = pixelsPerMetre;

}

}

The GameObjectFactory needs three members. A Context and an int with the number of pixels for every meter of the game world so it can pass them to the graphics-related component classes and a GameEngine reference, so it can pass it to any of the input-related component classes, so they can register as observers. These three members (mContext, mGameEnginrReference and mPixelsPerMetre) are initialized in the constructor.

Next, add the create method. We will come back to this method in the next chapter and add more code to the switch block.

GameObject create(GameObjectSpec spec, PointF location) {

GameObject object = new GameObject();



int mNumComponents = spec.getComponents().length;

object.setTag(spec.getTag());



// First give the game object the

// right kind of transform



switch(object.getTag()){

case "Background":

// Code coming soon

break;



case "Player":

// Code coming soon

break;



default:// normal transform

object.setTransform(new Transform(

spec.getSpeed(),

spec.getSize().x,

spec.getSize().y,

location));

break;

}





// Loop through and add/initialize all the components

for (int i = 0; i < mNumComponents; i++) {

switch (spec.getComponents()[i]) {

case "PlayerInputComponent":

// Code coming soon

break;

case "AnimatedGraphicsComponent":

// Code coming soon

break;

case "PlayerUpdateComponent":

// Code coming soon

break;

case "InanimateBlockGraphicsComponent":

object.setGraphics(new

InanimateBlockGraphicsComponent(),

mContext, spec, spec.getSize(),

mPixelsPerMetre);

break;

case "InanimateBlockUpdateComponent":

object.setMovement(new

InanimateBlockUpdateComponent());

break;

case "MovableBlockUpdateComponent":

// Code coming soon

break;

case "DecorativeBlockUpdateComponent":

object.setMovement(new

DecorativeBlockUpdateComponent());

break;

case "BackgroundGraphicsComponent":

// Code coming soon

break;

case "BackgroundUpdateComponent":

// Code coming soon

break;



default:

// Error unidentified component

break;

}

}



// Return the completed GameObject

// to the LevelManager class

return object;

}

First, in the create method a new instance of GameObject is declared and initialized. Just as we did in the previous project we capture the number of components in the current specification and then call the setTag method on the GameObject instance. The GameObject can now be properly identified by a tag.

Next, we see something new compared to the previous GameObjectFactory from the Scrolling Shooter project. We switch based on the tag of the specification. There are three possible case statements that can be executed. One for “Background”, one for “Player” and a default as well.

For now, we just add code to the default option that calls the setTransform method on the GameObject instance and passes in a new Transform reference. In the next chapter we will extend Transform twice to make special versions for the player and the backgrounds. This is how we make sure that every object gets the Transform it needs.

Next, we loop around a for loop once for each component in the specification. And just as we did in the previous project we initialize the appropriate component at each case statement by calling either setGraphics or setMovement on the GameObject instance and passing in a new component of the appropriate type according to the specification.

Also note I have added all the case statements to handle all the other components although most of them are currently empty. This will make it easy to show where the new code goes in the next chapter.

Coding a slightly commented-out game object

The game is coming together nicely, and we can now turn our attention to the GameObject class. Much will look familiar to the previous project. Create a class called GameObject and add the following member variables.

import android.content.Context;

import android.graphics.Canvas;

import android.graphics.Paint;

import android.graphics.PointF;



import com.gamecodeschool.platformer.GOSpec.GameObjectSpec;



class GameObject {



private Transform mTransform;





private boolean mActive = true;

private String mTag;



private GraphicsComponent mGraphicsComponent;

private UpdateComponent mUpdateComponent;



}

Check the highlighted import statement is correct for your project.

The members are almost the same as the previous project except we have an instance of an UpdateComponent replacing an instance of a MovementComponent.

Next, add the following methods which are used to initialize the component-based and Transform instances that we just declared.

void setGraphics(GraphicsComponent g,

Context c,

GameObjectSpec spec,

PointF objectSize,

int pixelsPerMetre) {



mGraphicsComponent = g;

g.initialize(c, spec, objectSize, pixelsPerMetre);

}



void setMovement(UpdateComponent m) {

mUpdateComponent = m;

}



/*

Uncomment this code soon

void setPlayerInputTransform(PlayerInputComponent s) {

s.setTransform(mTransform);

}

*/



void setTransform(Transform t) {

mTransform = t;

}

The methods we just coded are called from GameObjectFactory and pass in the specific instances of the GraphicsComponent, UpdateComponent and Transform.

Notice I have commented out setPlayerInputTransform as we haven’t coded this Transform extended class yet. Commenting it out will enable us to run the project at an earlier opportunity.

Add the rest of the methods to the GameObject class.

void draw(Canvas canvas, Paint paint, Camera cam) {

mGraphicsComponent.draw(canvas,

paint,

mTransform, cam);

}



void update(long fps, Transform playerTransform) {

mUpdateComponent.update(fps,

mTransform,

playerTransform);

}



boolean checkActive() {

return mActive;

}



String getTag() {

return mTag;

}



void setInactive() {

mActive = false;

}



Transform getTransform() {

return mTransform;

}



void setTag(String tag) {

mTag = tag;

}

The code we just added includes the key update and draw methods which are called each frame and the familiar bunch of getter methods for getting data from the GameObject instance.

Coding the GameState

The GameState class holds multiple fastest times, and which level is being played. The GameState class also takes care of knowing (and sharing) the current state of paused, playing, drawing, thread running, etc.

Create a new class called GameState and add the member variables and constructor as shown next.

import android.content.Context;

import android.content.SharedPreferences;



final class GameState {

private static volatile boolean

mThreadRunning = false;



private static volatile boolean mPaused = true;

private static volatile boolean mGameOver = true;

private static volatile boolean mDrawing = false;

private EngineController engineController;



private int mFastestUnderground;

private int mFastestMountains;

private int mFastestCity;

private long startTimeInMillis;



private int mCoinsAvailable;

private int coinsCollected;



private SharedPreferences.Editor editor;



private String currentLevel;



GameState(EngineController gs, Context context) {

engineController = gs;

SharedPreferences prefs = context

.getSharedPreferences("HiScore",

Context.MODE_PRIVATE);



editor = prefs.edit();

mFastestUnderground = prefs.getInt(

"fastest_underground_time", 1000);

mFastestMountains = prefs.getInt(

"fastest_mountains_time", 1000);

mFastestCity = prefs.getInt(

"fastest_city_time", 1000);

}

}

We have Boolean variables to represent whether the game thread is running, the player has paused, the game is over or currently drawing. We also have an EngineController reference so GameState can reinitialize a game/level directly.

Next up we have three int variables to hold the fastest time on each of the three levels. The startTimeInMillis variable will be initialized each time a level is attempted to record the time the level was started so it is possible to calculate how long the level took.

There are two more int members to hold the number of coins it is possible to collect in a level and the number of coins actually collected. They are mCoinsAvailable and coinsCollected.

The final two members in the previous code is an instance of SharedPrefferences.Editor for writing new high scores and a String which will represent the current level to be played, City, Underground or Mountains.

Now add this quite a long list of getters and setters to the GameState class.

v

oid coinCollected() {

coinsCollected++;

}



int getCoinsRemaining() {

return mCoinsAvailable - coinsCollected;

}



void coinAddedToLevel() {

mCoinsAvailable++;

}



void resetCoins() {

mCoinsAvailable = 0;

coinsCollected = 0;

}



void setCurrentLevel(String level) {

currentLevel = level;

}



String getCurrentLevel() {

return currentLevel;

}



void objectiveReached() {

endGame();

}



int getFastestUnderground() {

return mFastestUnderground;

}



int getFastestMountains() {

return mFastestMountains;

}



int getFastestCity() {

return mFastestCity;

}

A detailed description of each of the methods we just added would be somewhat laborious because they each do just one thing.

• Set a value(s)
• Return a value
• Call another method

It is, however, well worth closely inspecting each method’s name to aid understanding as we proceed.

Next, add three more methods to the GameState class for starting a new game, getting the current time, and taking action when the player dies.

void startNewGame() {

// Don't want to be handling objects while

// clearing ArrayList and filling it up again

stopEverything();

engineController.startNewLevel();

startEverything();

startTimeInMillis = System.currentTimeMillis();

}



int getCurrentTime() {

long MILLIS_IN_SECOND = 1000;

return (int) ((System.currentTimeMillis()

- startTimeInMillis) / MILLIS_IN_SECOND);

}



void death() {

stopEverything();

SoundEngine.playPlayerBurn();

}

The startNewGame method calls the stopEverything method. We will code the stopEverything method soon. The next line of code uses the GameController reference to call the startNewLevel method on the GameEngine class. Once the startNewLevel method has done its work we call the startEverything method (which we will code soon) to get things going again. The reason we do these three steps is that otherwise, we will be trying to update and draw objects at the same time as the GameEngine is also deleting and reinitializing them. This would be bound to cause a crash. The last thing we do in startNewGame is initialize the startTimeInMillis variable with the current time.

The getCurrentTime method shares the current time. Note that it takes the start time from the current time and divides the result by one thousand. This is because we want the player to see their time in seconds not milliseconds.

The death method simply calls stopEverything and then uses the SoundEngine to play a death sound.

Now code the endGame method and then we will discuss it.

private void endGame() {



stopEverything();

int totalTime =

((mCoinsAvailable - coinsCollected)

* 10)

+ getCurrentTime();



switch (currentLevel) {



case "underground":

if (totalTime < mFastestUnderground) {

mFastestUnderground = totalTime;

// Save new time



editor.putInt("fastest_underground_time",

mFastestUnderground);



editor.commit();

}

break;

case "city":

if (totalTime < mFastestCity) {

mFastestCity = totalTime;

// Save new time

editor.putInt("fastest_city_time",

mFastestCity);



editor.commit();

}

break;

case "mountains":

if (totalTime < mFastestMountains) {

mFastestMountains = totalTime;

// Save new time

editor.putInt("fastest_mountains_time",

mFastestMountains);



editor.commit();

}

break;

}

}

The first line of code in endGame calls stopEverything so the game engine will halt updating and drawing.

Next, a local variable, totalTime is declared and initialized. The total time (as you might remember from Chapter 22: Platform Game: Bob was in a hurry section) is calculated by the total time the player took added to a penalty for each coin that the player failed to collect.

Next in the endGame method we enter a switch block where the condition is the curremtLevel String. The first case is when the underground level has been played. The code uses an if statement to check if totalTime is less than mFastestUnderground. If it is then the player has a new fastest time. The editor.putInt and editor.commit methods of the SharedPrefferences.Editor instance are then used to save the new record for posterity.

The next two case blocks do the same thing for the city then the mountains levels.

Now code the final methods for the GameState class.

void stopEverything() {// Except the thread

mPaused = true;

mGameOver = true;

mDrawing = false;

}



private void startEverything() {

mPaused = false;

mGameOver = false;

mDrawing = true;

}



void stopThread() {

mThreadRunning = false;

}



boolean getThreadRunning() {

return mThreadRunning;

}



void startThread() {

mThreadRunning = true;

}



boolean getDrawing() {

return mDrawing;

}



boolean getPaused() {

return mPaused;

}



boolean getGameOver() {

return mGameOver;

}

The final getters and setters control when the game engine does certain tasks like start/stop the thread and call update and/or draw. Familiarize yourself with their names and which members they interact with.

Let’s make some noise.

Code the SoundEngine

Fortunately, the SoundEngine class holds no surprises. This is essentially the exact same class as we coded in the Scrolling Shooter project. The only exceptions are that we load different sound effects and the methods which play the sound effects have different names and play different sounds. We have also made it a Singleton to avoid the long parameter lists that we had in the previous project when we passed a SoundEngine reference into so many other classes/methods.

Add the following code for the member variables and the getInstance method.

import android.content.Context;

import android.content.res.AssetFileDescriptor;

import android.content.res.AssetManager;

import android.media.AudioAttributes;

import android.media.AudioManager;

import android.media.SoundPool;

import android.os.Build;



import java.io.IOException;



class SoundEngine {

// for playing sound effects

private static SoundPool mSP;

private static int mJump_ID = -1;

private static int mReach_Objective_ID = -1;

private static  int mCoin_Pickup_ID = -1;

private static  int mPlayer_Burn_ID = -1;



private static SoundEngine ourInstance;



public static SoundEngine getInstance(Context context) {

ourInstance = new SoundEngine(context);

return ourInstance;

}

}

The getInstance method provides access to the full functionality of the class as well as calling the constructor method to initialize all the sound effects into a SoundPool. Add the constructor method.

public SoundEngine(Context c){

// Initialize the SoundPool

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {

AudioAttributes audioAttributes =

new AudioAttributes.Builder()

.setUsage(AudioAttributes.USAGE_MEDIA)

.setContentType(AudioAttributes

.CONTENT_TYPE_SONIFICATION)

.build();



mSP = new SoundPool.Builder()

.setMaxStreams(5)

.setAudioAttributes(audioAttributes)

.build();

} else {

mSP = new SoundPool(5, AudioManager.STREAM_MUSIC, 0);

}

try {

AssetManager assetManager = c.getAssets();

AssetFileDescriptor descriptor;



// Prepare the sounds in memory

descriptor = assetManager.openFd("jump.ogg");

mJump_ID = mSP.load(descriptor, 0);



descriptor = assetManager.openFd("reach_objective.ogg");

mReach_Objective_ID = mSP.load(descriptor, 0);



descriptor = assetManager.openFd("coin_pickup.ogg");

mCoin_Pickup_ID = mSP.load(descriptor, 0);



descriptor = assetManager.openFd("player_burn.ogg");

mPlayer_Burn_ID = mSP.load(descriptor, 0);



} catch (IOException e) {

// Error

}

}

Now the sound files are loaded in to memory ready to play. Add the methods that play the sounds, as follows.

public static void playJump(){

mSP.play(mJump_ID,1, 1, 0, 0, 1);

}



public static void playReachObjective(){

mSP.play(mReach_Objective_ID,1, 1, 0, 0, 1);

}



public static void playCoinPickup(){

mSP.play(mCoin_Pickup_ID,1, 1, 0, 0, 1);

}



public static void playPlayerBurn(){

mSP.play(mPlayer_Burn_ID,1, 1, 0, 0, 1);

}

These methods are public and static so are accessible from anywhere without an instance of SoundEngine.

Any class can now play any of the sound effects.

Coding the physics engine (without collision)

The PhysicsEngine class is responsible, first, for updating all the game objects and secondly for detecting and responding to collisions. This next code handles updating the game objects in the update method and we will code an empty detectCollisions method ready to add more code in Chapter 25.

Add the PhysicsEngine class and then we will discuss the code.

import android.graphics.PointF;

import android.graphics.RectF;

import java.util.ArrayList;



class PhysicsEngine {



void update(long fps,

ArrayList<GameObject> objects,

GameState gs) {



for (GameObject object : objects) {

object.update(fps,

objects.get(LevelManager.PLAYER_INDEX)

.getTransform());

}



detectCollisions(gs, objects);

}



private void detectCollisions(GameState gs,

ArrayList<GameObject> objects) {

// More code here soon

}

}

The update method receives the current frames per second, an ArrayList full of all the GameObject references, and a reference to the current GameState. It then loops through all the GameObject instances calling each and every update method after first checking that the GameObject is active. Finally, the detectCollisions method is called although for now, we have left this method empty.

Coding a Renderer

As with many of the classes in this chapter. Renderer will be very similar to the earlier project, so we can zip through it and move on.

Create a new class called Renderer then add the following members and constructor.

class Renderer {

private Canvas mCanvas;

private SurfaceHolder mSurfaceHolder;

private Paint mPaint;



// Here is our new camera

private Camera mCamera;



Renderer(SurfaceView sh, Point screenSize){

mSurfaceHolder = sh.getHolder();

mPaint = new Paint();



// Initialize the camera

mCamera = new Camera(screenSize.x, screenSize.y);

}

}

The Renderer has the Canvas, SurfaceHolder and Paint instances as we have come to expect. It also has a Camera instance called mCamera. We at last get to code the Camera class when we are done with Renderer.

In the constructor, the SurfaceHolder, Paint, and Camera instances are initialized.

Now add the getPixelsPerMetre and draw methods.

i

nt getPixelsPerMetre(){

return mCamera.getPixelsPerMetre();

}



void draw(ArrayList<GameObject> objects,

GameState gs,

HUD hud) {



if (mSurfaceHolder.getSurface().isValid()) {

mCanvas = mSurfaceHolder.lockCanvas();

mCanvas.drawColor(Color.argb(255, 0, 0, 0));



if(gs.getDrawing()) {

// Set the player as the center of the camera

mCamera.setWorldCentre(

objects.get(LevelManager

.PLAYER_INDEX)

.getTransform().getLocation());



for (GameObject object : objects) {

if (object.checkActive()) {

object.draw(mCanvas, mPaint,

mCamera);

}

}

}



hud.draw(mCanvas, mPaint, gs);



mSurfaceHolder.unlockCanvasAndPost(mCanvas);

}

}

The getPixelsPerMetre method uses the instance of the Camera class to return the number of pixels that represent a virtual meter in the game world. We will code the Camera class including this method next.

The code in the draw method prepares the surface, checks it is currently OK to draw then sets the camera to whatever the player’s location is using the setWorldCentre method. We will code the Camera class including this method next. Then the code loops through all the objects checking which ones are active and drawing them. Then the HUD is drawn and the now familiar unlockCanvasAndPost method is called.

Coding the camera

This class is completely new to this project. The key to understanding it is to remember that all our game objects have sizes and positions in virtual meters. All the movement and collision detection will be done using these virtual meters. Here is the key-key point:

These virtual meters currently bare no relation to the pixels on the screen. The Camera class will know the screen’s resolution and translate these virtual meters into pixel coordinates. Not all game objects will be on the screen every frame. In fact, most game objects will not be visible, most frames.

Add a new class called Camera and add the following member variables and the constructor.

import android.graphics.PointF;

import android.graphics.Rect;



class Camera {



private PointF mCurrentCameraWorldCentre;

private Rect mConvertedRect;

private int mPixelsPerMetre;

private int mScreenCentreX;

private int mScreenCentreY;



Camera(int screenXResolution, int screenYResolution){

// Locate the centre of the screen

mScreenCentreX = screenXResolution / 2;

mScreenCentreY = screenYResolution / 2;



// How many metres of world space does

// the screen width show

// Change this value to zoom in and out

final int pixelsPerMetreToResolutionRatio = 48;

mPixelsPerMetre = screenXResolution /

pixelsPerMetreToResolutionRatio;



mConvertedRect = new Rect();

mCurrentCameraWorldCentre = new PointF();

}

There are five, member variables as follows:

• The PointF mCurrentCameraWorldCentre instance will hold the central position (in virtual meters) the camera is centered on. This will be updated each frame and is the same as the position of the player.
• The Rect mConvertedRect instance will hold the four converted points that have been translated from virtual meters to pixel coordinates. This is the Rect that will be used by all the graphics-related component classes in their draw methods when they call drawBitmap. Look back to the InanimateBlockGraphicsComponent section if you want to confirm this.
• The int mPixelsPerMetre member is the number of pixels on the screen that represent one virtual metre.
• The int mScreenCentreX member is the pixel coordinate of the central pixel, horizontally on the screen.
• The int mScreenCentreY member is the pixel coordinate of the central pixel, horizontally on the screen.

It is the way we calculate and combine these five values that makes the class do its magic.

Next, add the following getters and setters to the class.

int getPixelsPerMetreY(){

return mPixelsPerMetre;

}



int getyCentre(){

return mScreenCentreY;

}



float getCameraWorldCentreY(){

return mCurrentCameraWorldCentre.y;

}



// Set the camera to the player. Called each frame

void setWorldCentre(PointF worldCentre){

mCurrentCameraWorldCentre.x  = worldCentre.x;

mCurrentCameraWorldCentre.y  = worldCentre.y;

}



int getPixelsPerMetre(){

return mPixelsPerMetre;

}

Four out of five of those methods simply return a value/reference to one of the members. We will see where they are used as we proceed. The setWorldCentre method however is more interesting. It receives a PointF reference as a parameter. The setWorldCentre method is called after the update method but before the draw method by GameEngine on every frame. The PointF that is passed in is the position of the Bob in the game world (in virtual metres).

This next method is the meat of the whole class and it uses all the members and the position of Bob to translate virtual metres into pixels. Notice that it receives the object’s horizontal and vertical positions (in virtual metres) as well as the objects width and height (also in virtual metres). Also notice it returns a Rect so that each game object’s graphics-related component class can use it in the call to drawBitmap. Add the worldToScreen method and then we will examine its body.

// Return a Rect of the screen coordinates

// relative to a world location

Rect worldToScreen(float objectX,

float objectY,

float objectWidth,

float objectHeight){



int left = (int) (mScreenCentreX -

((mCurrentCameraWorldCentre.x - objectX)

* mPixelsPerMetre));



int top =  (int) (mScreenCentreY -

((mCurrentCameraWorldCentre.y - objectY)

* mPixelsPerMetre));



int right = (int) (left + (objectWidth

* mPixelsPerMetre));



int bottom = (int) (top + (objectHeight

* mPixelsPerMetre));



mConvertedRect.set(left, top, right, bottom);



return mConvertedRect;

}

Let’s go through the body a line at a time. The first line of code declares and initializes a local int variable called left.

int left = (int) (mScreenCentreX -

((mCurrentCameraWorldCentre.x - objectX)

* mPixelsPerMetre));

The initialization code uses a cast, (int), to convert the float result to int. The calculation subtracts the objects horizontal position from the current focus of the camera which in turn is subtracted from the central horizontal pixel position. By multiplying the result by mPixelsPerMetre the world (virtual meter) positions are now a pixel coordinate. Note that at this stage we have only calculated the horizontal pixel position of one of four points.

This next line of code does the same thing except using the vertical values of the screen center, world center and object position.

int top =  (int) (mScreenCentreY -

((mCurrentCameraWorldCentre.y - objectY)

* mPixelsPerMetre));

The next two lines of code use left then top in conjunction with the width and height (respectively) to calculate the right and bottom pixel coordinates (respectively).

int right = (int) (left + (objectWidth

* mPixelsPerMetre));



int bottom = (int) (top + (objectHeight

* mPixelsPerMetre));

Let’s invent some hypothetical positions for the player and an example object so we can see those calculations in action.

Suppose that the player is at (top left corner) the world location of 120 virtual meters horizontally and 90 meters vertically. The player is 1 meter wide and 2 meters tall. There is a platform at the world location of 116 meters horizontally and 89 meters vertically. The platform is 1 meter by 1 meter in size. If our calculations are to do their job, then they need to convert these sizes and positions into screen coordinates where the platform is to the left of the player by four times as much as it is above the player. This exercise will assume the screen is 1920 pixels wide by 1080 pixels high. First let’s calculate the player’s pixel coordinates.

Testing the formulas with hypothetical coordinates

The formula for the player’s left (in English not in code) is as follows:

Remember that the world camera center coordinates are the same as the player’s top-left coordinates and are updated each frame after update but before draw is called.

We can see that the left of the player is drawn in the horizontal center of the screen, 960 pixels.

Now for the top variable using the player’s world coordinates.

We can now see that the player’s top-left coordinates on the screen is 960, 540. This is the center of a 1920 x 1080 screen. Wherever in the game world the player moves, because mCameraCurrentWorldCentre is updated with each frame, the player stays in the center of the screen.

Let’s look quickly at how the right and bottom values are calculated and then we can run the hypothetical platform coordinates through the same formulas.

Here is the formula for the right variable.

The bottom calculation uses the following formula:

The rectangle representing where Bob will be drawn will be at the following pixel coordinates:

Left: 960, Top: 540, Bottom: 1048, Right: 636.

The formula for the block’s left (in English not in code) is as follows:

We can see that the left of the block is drawn in the horizontal center of the screen, 960 pixels.

Now for the top variable using the block’s world coordinates.

Let’s look quickly at how the right and bottom values are calculated. Here is the formula for the right variable.

Left pixel coordinate + (width in meters * pixels per meter)

The bottom calculation uses the following formula:

The rectangle representing where the block will be drawn will be at the following pixel coordinates:

Left: 960, Top: 540, Bottom: 1048, Right: 636.

Look closely at the results for converting the player’s and the other object’s world coordinates and you can see that they are within the scope of being able to accept them as correct. When we see hundreds of objects all neatly drawn in exactly the right place it will be certain the formulas work.

Finally, mConvertedRect is initialized with the four values using the set method and then returned to the calling code.

mConvertedRect.set(left, top, right, bottom);

return mConvertedRect;

Try making up some more hypothetical object positions and calculating their pixel positions. Try some values that are some distance away (perhaps 50 meters) and notice how they are at a position that will not be seen on screen.

Now we have a system for converting all the floating-point world positions into integer pixel positions we can turn our attention to the HUD class.

Coding the Hud

The HUD in this game is no more complex than the previous game. We will define some Rect instances to draw the controls on the screen, we will rely on GameState to provide the time and fastest times for each level and we will make the button Rect ArrayList available so that GameEngine can pass then them to our two classes that require them to handle the player’s input.

Get started by adding a new class called HUD and add the following members and constructor method.

import android.content.Context;

import android.graphics.Bitmap;

import android.graphics.BitmapFactory;

import android.graphics.Canvas;

import android.graphics.Color;

import android.graphics.Paint;

import android.graphics.Point;

import android.graphics.Rect;



import java.util.ArrayList;



class HUD {

private Bitmap mMenuBitmap;



private int mTextFormatting;

private int mScreenHeight;

private int mScreenWidth;

final float ONE_THIRD = .33f;

final float TWO_THIRDS = .66f;



private ArrayList<Rect> mControls;



static int LEFT = 0;

static int RIGHT = 1;

static int JUMP = 2;



HUD(Context context, Point size){

mScreenHeight = size.y;

mScreenWidth = size.x;

mTextFormatting = size.x / 25;



prepareControls();



// Create and scale the bitmaps

mMenuBitmap = BitmapFactory

.decodeResource(context.getResources(),

R.drawable.menu);



mMenuBitmap = Bitmap

.createScaledBitmap(mMenuBitmap,

size.x, size.y, false);



}

}

The class starts off with five members that we will use to control position and formatting of the parts of the HUD. Next there is an ArrayList for our Rect buttons and next there is the static variables LEFT, RIGHT and JUMP which the UIController (that we code next) and PlayerInputComponent (that we code next chapter) can use to identify what the player is trying to do.

In the constructor we initialize some of our formatting variables using the passed in screen resolution, call the prepareControls method and load and scale the Bitmap that is used for the menu background.

Now we can code the prepareControls method that we just called.

private void prepareControls(){

int buttonWidth = mScreenWidth / 14;

int buttonHeight = mScreenHeight / 12;

int buttonPadding = mScreenWidth / 90;





Rect left = new Rect(

buttonPadding,

mScreenHeight - buttonHeight - buttonPadding,

buttonWidth + buttonPadding,

mScreenHeight - buttonPadding);



Rect right = new Rect(

(buttonPadding * 2) + buttonWidth,

mScreenHeight - buttonHeight - buttonPadding,

(buttonPadding * 2) + (buttonWidth * 2),

mScreenHeight - buttonPadding);



Rect jump = new Rect(mScreenWidth - buttonPadding

- buttonWidth,

mScreenHeight - buttonHeight - buttonPadding,

mScreenWidth - buttonPadding,

mScreenHeight - buttonPadding);





mControls = new ArrayList<>();

mControls.add(LEFT,left);

mControls.add(RIGHT,right);

mControls.add(JUMP, jump);

}

In the previous code, we initialize our remaining formatting members relative to the screen resolution in pixels. We then use them to position our three Rect objects that represent the buttons and then add them to the mControls ArrayList.

Next, add the draw method which just like the HUD in the previous project will be called each frame of the game to draw the HUD. Notice the usual suspects are passed in as parameters to enable the method to do its job.

void draw(Canvas c, Paint p, GameState gs){



if(gs.getGameOver()){



// Draw the mMenuBitmap screen

c.drawBitmap(mMenuBitmap, 0,0, p);



// draw a rectangle to highlight the text

p.setColor(Color.argb (100, 26, 128, 182));

c.drawRect(0,0, mScreenWidth,

mTextFormatting * 4, p);



// Draw the level names

p.setColor(Color.argb(255, 255, 255, 255));

p.setTextSize(mTextFormatting);

c.drawText("Underground",

mTextFormatting,

mTextFormatting * 2,

p);



c.drawText("Mountains",

mScreenWidth * ONE_THIRD

+ (mTextFormatting),

mTextFormatting * 2,

p);



c.drawText("City",

mScreenWidth * TWO_THIRDS

+ (mTextFormatting),

mTextFormatting * 2,

p);



// Draw the fastest times

p.setTextSize(mTextFormatting/1.8f);



c.drawText("BEST:" + gs.getFastestUnderground()

+" seconds",

mTextFormatting,

mTextFormatting*3,

p);



c.drawText("BEST:" + gs.getFastestMountains()

+" seconds", mScreenWidth * ONE_THIRD

+ mTextFormatting,

mTextFormatting * 3,

p);



c.drawText("BEST:" + gs.getFastestCity()

+ " seconds",

mScreenWidth * TWO_THIRDS + mTextFormatting,

mTextFormatting * 3,

p);



// draw a rectangle to highlight the large text

p.setColor(Color.argb (100, 26, 128, 182));

c.drawRect(0,mScreenHeight - mTextFormatting * 2,

mScreenWidth,

mScreenHeight,

p);



p.setColor(Color.argb(255, 255, 255, 255));

p.setTextSize(mTextFormatting * 1.5f);

c.drawText("DOUBLE TAP A LEVEL TO PLAY",

ONE_THIRD + mTextFormatting * 2,

mScreenHeight - mTextFormatting/2,

p);

}

// else block follows next



}

The method is long and might seem complicated at first glance but there is nothing we haven’t seen before. There is one thing to note, however. All the code is wrapped in an if block with a condition of gs.getGameOver. So, all the code we just added runs when the game is over. We will add the else block which follows this if block in a moment.

The code inside the if block draws the background, level names, and fastest times as well as the message to tell the player how to start the game. Clearly, we don’t want these things on the screen while the game is being played.

Still, inside the draw method add the else block that follows the if block which will execute while the game is being played.

...

// else block follows next

else {

// draw a rectangle to highlight the text

p.setColor(Color.argb (100, 0, 0, 0));

c.drawRect(0,0, mScreenWidth,

mTextFormatting,

p);



// Draw the HUD text

p.setTextSize(mTextFormatting/1.5f);

p.setColor(Color.argb(255, 255, 255, 255));

c.drawText("Time:" + gs.getCurrentTime()

+ "+" + gs.getCoinsRemaining() * 10,

mTextFormatting / 4,

mTextFormatting / 1.5f,

p);





drawControls(c, p);

}

In the else block, we draw a transparent rectangle across the top of the screen which has the effect of highlighting the text that is drawn on top of it. Then we draw the current time. The slightly convoluted formula (gs.getCoinsRemaining() * 10) has the effect of calculating (and displaying) the time penalty based on how many coins the player still needs to collect. The final line of code in the draw method (but still inside the else block) calls the drawControls method. This is separated out purely to stop the method getting any longer than it already is.

Here are the final two methods of the HUD class. Add the drawControls and getControls method.

private void drawControls(Canvas c, Paint p){

p.setColor(Color.argb(100,255,255,255));



for(Rect r : mControls){

c.drawRect(r.left, r.top, r.right, r.bottom, p);

}



// Set the colors back

p.setColor(Color.argb(255,255,255,255));

}





ArrayList<Rect> getControls(){

return mControls;

}

The drawControls method loops through the mControls ArrayList and draws each button as a transparent rectangle. The getControls method simply returns a reference to mControls. GameEngine will use this method to pass mControls to the other classes that need it.

Coding the UIController class

This class will have the same purpose as the class of the same name did in the previous project. It will also look very similar too.

Add a new class called UIController and add the member variables, constructor and addObserver method.

i

mport android.graphics.Point;

import android.graphics.Rect;

import android.view.MotionEvent;



import java.util.ArrayList;



class UIController implements InputObserver {



private float mThird;



private boolean initialPress = false;



UIController(GameEngineBroadcaster b, Point size) {

// Add as an observer

addObserver(b);



mThird = size.x / 3;

}





void addObserver(GameEngineBroadcaster b) {

b.addObserver(this);

}

}

The float mThird variable will help us to divide the screen up vertically into thirds. The player will then be able to tap a portion of the screen to choose the level that they want to play. The initialPress Boolean is used in a workaround to avoid a bug/glitch. Sometimes when the game ends the menu will immediately register the player’s touch causing a new level to start instantly rather than allowing them to view the menu screen at their leisure. By ignoring the very first touch we avoid this problem.

This is a hack and not a good solution to go into a finished game. Unfortunately, the solution would require at least another chapter and I am running out of space. In chapter 26 I suggest some resources to continue your learning. Be sure to look into the State pattern to improve all the projects and as a solution for this hack.

In the constructor, we call the addObserver method and initialize the mThird variable to a third of the screen’s width. In the addObserver method the code uses the GameEngineBroadcaster reference to add an observer to GameEngine.

We need to add an observer each time a new game is started, and the game objects are rebuilt because the observer list is cleared. The addObserver method allows us to re-add an observer rather than just add it in the constructor.

Now add the handleInput method which receives the MotionEvent, the GameState and the ArrayList which contains the button positions.

@Override

public void handleInput(MotionEvent event,

GameState gameState,

ArrayList<Rect> buttons) {



int i = event.getActionIndex();

int x = (int) event.getX(i);



int eventType = event.getAction()

& MotionEvent.ACTION_MASK;



if (eventType == MotionEvent.ACTION_UP ||

eventType == MotionEvent.ACTION_POINTER_UP) {



// If game is over start a new game

if (gameState.getGameOver() && initialPress) {



if (x < mThird) {

gameState.setCurrentLevel("underground");

gameState.startNewGame();

} else if (x >= mThird && x < mThird * 2) {

gameState.setCurrentLevel("mountains");

gameState.startNewGame();

} else if (x >= mThird * 2) {

gameState.setCurrentLevel("city");

gameState.startNewGame();

}

}

initialPress = !initialPress;

}

}

As we did in the previous project we handle input by accessing the event at the index which triggered the current action. There is an if – else if – else if structure where the code detects which level was pressed. These are the only touches that need to be handled. The buttons will be handled by the PlayerController component class. After an ACTION_UP has been detected, notice also that the rest of the code is wrapped in an if condition that tests whether the game is over and initialPress is false. Outside this structure, all ACTION_UP events will switch the value of initialPress. This means that the last stray touch of game-play won’t dismiss the menu screen as soon as it starts.

Code the Activity

This class is just like the one we have been coding for virtually the entire book. Take a look at the code and then add this class to your project.

import android.app.Activity;

import android.graphics.Point;

import android.os.Bundle;

import android.view.Display;



public class GameActivity extends Activity {



GameEngine mGameEngine;



@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);



Display display = getWindowManager()

.getDefaultDisplay();



Point size = new Point();

display.getSize(size);

mGameEngine = new GameEngine(this, size);

setContentView(mGameEngine);

}



@Override

protected void onResume() {

super.onResume();

mGameEngine.startThread();

}



@Override

protected void onPause() {

super.onPause();

mGameEngine.stopThread();

}

}

Everything is very familiar except you can see that I have renamed the resume and pause methods of the GameEngine class to startThread and stopThread respectively.

Now we can code the GameEngine class (including startThread and stopThread) and we will then be one small step away from running our hard work from the last two chapters.

How to Code the GameEngine

Now we get to the class that glues all the others together. In the code that follows we will declare and use an instance of LevelManager that we will code immediately after GameEngine. All the rest of the code will, at last, be error-free and nearly ready to execute.

Add the GameEngine class, its members, and the constructor as shown next.

import android.content.Context;

import android.graphics.Point;

import android.util.Log;

import android.view.MotionEvent;

import android.view.SurfaceView;



import java.util.concurrent.CopyOnWriteArrayList;



class GameEngine extends SurfaceView

implements Runnable,

GameEngineBroadcaster,

EngineController {



private Thread mThread = null;

private long mFPS;



private GameState mGameState;

UIController mUIController;



// This ArrayList can be accessed from either thread

private CopyOnWriteArrayList<InputObserver>

inputObservers = new CopyOnWriteArrayList();



HUD mHUD;

LevelManager mLevelManager;

PhysicsEngine mPhysicsEngine;

Renderer mRenderer;



public GameEngine(Context context, Point size) {

super(context);

// Prepare the bitmap store and sound engine

BitmapStore bs = BitmapStore.getInstance(context);

SoundEngine se = SoundEngine.getInstance(context);



// Initialize all the significant classes

// that make the engine work

mHUD = new HUD(context, size);

mGameState = new GameState(this, context);

mUIController = new UIController(this, size);

mPhysicsEngine = new PhysicsEngine();

mRenderer = new Renderer(this, size);

mLevelManager = new LevelManager(context,

this, mRenderer.getPixelsPerMetre());



}

}

There are a few new things happening in the code you just saw. First notice that we need to import the CopyOnWriteArrayList class. This is a version of the ArrayList class that works simultaneously on multiple threads without crashing the game. This structure will be used to hold the InputObservers. CopyOnWriteArrayList is slower than the regular ArrayList class but as it is holding just two items that are accessed infrequently (compared to the GameObject instances) it won’t cause a performance issue. The GameObject instances will be held in a regular ArrayList.

Notice as usual we have the members such as mThread and mFPS for our main game loop and measuring the frames per second. We also declare instances for many of the classes we have been slaving over for the past two chapters.

In the constructor, we initialize all the instances. Look at the way we initialize our two Singletons (BitmapStore and SoundEngine) using the getInstance method. The other initializations are just as we have seen before and should expect based on the classes we have been coding. The exception is the instance of LevelManager. Look at the parameters we pass in, a Context, this, and the number of pixels per meter (supplied by the Renderer class). We will see how we put all these things into action shortly. Let’s finish the GameEngine class.

Code the startNewLevel method and the addObserver method.

public void startNewLevel() {

// Clear the bitmap store

BitmapStore.clearStore();

// Clear all the observers and add the UI observer back

// When we call buildGameObjects the

// player's observer will be added too

inputObservers.clear();

mUIController.addObserver(this);

mLevelManager.setCurrentLevel(mGameState.getCurrentLevel());

mLevelManager.buildGameObjects(mGameState);

}



// For the game engine broadcaster interface

public void addObserver(InputObserver o) {

inputObservers.add(o);

}

First, the static method Bitmap.clearStore is used to make sure there are no Bitmap instances already in the store. Then, the inputObservers ArrayList is cleared. The reason we need to do this each new game/level attempt is because each call to buildGameObjects deletes any existing game objects and rebuilds new ones to suit the current level. This includes the player that will be composed of a PlayerInputController component class that will have registered as an input observer. Therefore, if we leave the old input observers in the ArrayList then there will be a reference to an object which doesn’t exist. Calling it will cause an instant crash.

After we have cleared the observers for the reason just stated we then need to add the UIController instance’s observer by calling addObserver. The UIController instance remains the same throughout the life of the application but we must add it to each level of course because we have just cleared it.

To end the method, we call the setCurrentLevel and buildGameObjects methods of the soon-to-be-coded LevelManager class.

The addObserver method allows the InputObservers to register themselves and be added to the inputObservers ArrayList.

Next, add the run method.

@Override

public void run() {

while (mGameState.getThreadRunning()) {



long frameStartTime = System.currentTimeMillis();



if (!mGameState.getPaused()) {

mPhysicsEngine.update(mFPS,

mLevelManager.getGameObjects(),

mGameState);

}



mRenderer.draw(mLevelManager.getGameObjects(),

mGameState,

mHUD);



long timeThisFrame = System.currentTimeMillis()

- frameStartTime;



if (timeThisFrame >= 1) {

final int MILLIS_IN_SECOND = 1000;

mFPS = MILLIS_IN_SECOND / timeThisFrame;

}

}

}

Most of this we have seen before, but this is what happens in run, step by step:

• The current time is stored in frameStartTime.
• If the game is not currently paused, then the PhysicsEngine instance’s update method is called.
• The Renderer instance’s draw method is called
• The amount of time that the previous two steps took is calculated and stored in timeThisFrame
• The current frame rate is calculated and stored in mFPS ready for use during the next frame of the game loop.

Add the onTouchEvent method along with the stopThread and startThread methods.

@Override

public boolean onTouchEvent(MotionEvent motionEvent) {

for (InputObserver o : inputObservers) {

o.handleInput(motionEvent,

mGameState,

mHUD.getControls());

}

return true;

}



public void stopThread() {

mGameState.stopEverything();

mGameState.stopThread();

try {

mThread.join();

} catch (InterruptedException e) {

Log.e("Exception",

"stopThread()" + e.getMessage());

}

}



public void startThread() {

mGameState.startThread();

mThread = new Thread(this);

mThread.start();

}

The onTouchEvent method loops through all the registered observers calling their handleInput method.

The stopThread method stops the thread (and everything else) via the GameState instance.

The startThread method starts the thread using the GameState instance.

Now we can move on to the final class for this chapter.

Coding the LevelManager class

We are nearly there. Coding this class will leave us with an executable project!

Create a new class called LevelManager and add the following members and the constructor.

import android.content.Context;

import android.graphics.PointF;

import android.util.Log;



import com.gamecodeschool.platformer.GOSpec.*;

import com.gamecodeschool.platformer.Levels.*;



import java.util.ArrayList;



final class LevelManager {



static int PLAYER_INDEX = 0;

private ArrayList<GameObject> objects;

private Level currentLevel;

private GameObjectFactory factory;



LevelManager(Context context,

GameEngine ge,

int pixelsPerMetre){



objects = new ArrayList<>();

factory = new GameObjectFactory(context,

ge,

pixelsPerMetre);

}

First, be aware of the two highlighted import statements that will need checking/correcting to your full package name.

We can tell we are getting close because we have declared the ArrayList that will hold all the GameObject instances (objects) and an instance of GameObjectFactory that will build them all.

We also have an instance of Level called currentLevel ready to be filled up with all the alpha-numeric characters that represent our level designs. The other member, PLAYER_INDEX is static and will help us insure that we keep a check on the position of the player in the objects ArrayList. In the constructor, objects and factory are initialized.

Add the setCurrentLevel method.

void setCurrentLevel(String level){

switch (level) {

case "underground":

currentLevel = new LevelUnderground();

break;



case "city":

currentLevel = new LevelCity();

break;



case "mountains":

currentLevel = new LevelMountains();

break;

}

}

}

This method allows the UIController class to change the current level by passing in a String which the code in the method body uses to create a new Level reference of one of the extended classes (LevelUnderground, LevelCity or LevelMountains).

The next code is long but not difficult. We glimpsed some of it (the comments) before in the earlier section Create the levels. Very similar to previous project it just adds a case to create the appropriate type of object based on the alpha-numeric character that is returned by the nested for loops which go through the level design a character at a time. Objects that aren’t available yet are commented out for later convenience.

Add the buildGameObjects method.

void buildGameObjects(GameState gs){

// Backgrounds 1, 2, 3(City, Underground, Mountain...)

// p = Player

// g = Grass tile

// o = Objective

// m = Movable platform

// b = Brick tile

// c = mine Cart

// s = Stone pile

// l = coaL

// n = coNcrete

// a = lAmpost

// r = scoRched tile

// w = snoW tile

// t = stalacTite

// i = stalagmIte

// d = Dead tree

// e = snowy trEe

// x = Collectable

// z = Fire

// y = invisible death_invisible



gs.resetCoins();

objects.clear();

ArrayList<String> levelToLoad = currentLevel.getTiles();



for(int row = 0; row < levelToLoad.size(); row++ )

{

for(int column = 0;

column < levelToLoad.get(row).length();

column++){



PointF coords = new PointF(column, row);



switch (levelToLoad.get(row)

.charAt(column)){



case '1':

//objects.add(factory.create(

// new BackgroundCitySpec(),

// coords));

break;



case '2':

//objects.add(factory.create(

// new BackgroundUndergroundSpec(),

// coords));

break;



case '3':

//objects.add(factory.create(

// new BackgroundMountainSpec(),

// coords));

break;



case 'p':

//objects.add(factory.create(new

// PlayerSpec(),

// coords));

// Remember the location of

// the player

//PLAYER_INDEX = objects.size()-1;

break;



case 'g':

objects.add(factory.create(

new GrassTileSpec(),

coords));

break;



case 'o':

objects.add(factory.create(

new ObjectiveTileSpec(),

coords));

break;



case 'm':

//objects.add(factory.create(

// new MoveablePlatformSpec(),

// coords));

break;



case 'b':

objects.add(factory.create(

new BrickTileSpec(),

coords));

break;



case 'c':

objects.add(factory.create(

new CartTileSpec(),

coords));

break;



case 's':

objects.add(factory.create(

new StonePileTileSpec(),

coords));

break;



case 'l':

objects.add(factory.create(

new CoalTileSpec(),

coords));

break;



case 'n':

objects.add(factory.create(

new ConcreteTileSpec(),

coords));

break;



case 'a':

objects.add(factory.create(

new LamppostTileSpec(),

coords));

break;



case 'r':

objects.add(factory.create(

new ScorchedTileSpec(),

coords));

break;



case 'w':

objects.add(factory.create(

new SnowTileSpec(),

coords));

break;



case 't':

objects.add(factory.create(

new StalactiteTileSpec(),

coords));

break;



case 'i':

objects.add(factory.create(

new StalagmiteTileSpec(),

coords));

break;



case 'd':

objects.add(factory.create(

new DeadTreeTileSpec(),

coords));

break;



case 'e':

objects.add(factory.create(

new SnowyTreeTileSpec(),

coords));

break;



case 'x':

objects.add(factory.create(

new CollectibleObjectSpec(),

coords));

gs.coinAddedToLevel();

break;



case 'z':

//objects.add(factory.create(

// new FireTileSpec(),

// coords));



break;



case 'y':

objects.add(factory.create(

new

InvisibleDeathTenByTenSpec(),

coords));



break;





case '.':

// Nothing to see here

break;



default:

Log.e("Unhandled item in level",

"row:"+row

+ " column:"+column);

break;

}



}



}



}

Each case starts with objects.add… and then calls the create method of the GameObjectFactory instance passing in the specification class of the new object to create and the coordinates at which to create it. The GameObjectFactory class returns the newly created object of the desired type and it is added to the objects ArrayList. All the specifications where we haven’t yet coded all the component classes are commented out to avoid errors/crashes.

Add the final method to the LevelManager class.

ArrayList<GameObject> getGameObjects(){

return objects;

}

This method returns a reference to the ArrayList that holds all the GameObject instances. You might remember this was called from the main game loop (run method) in the GameEngine class.

Running the game

If you execute the game, you will see the menu.

The menu allows you to start each of the three levels. But as there is currently no way to complete or fail a level you will need to quit the game and restart it if you want to see the progress on all three.

This is the City level so far.

This is the Underground level so far.

This is the Mountains level so far.

Note the camera is centered around 0,0 because PLAYER_INDEX equals zero and the first object in the objects ArrayList is at 0,0. You could count the characters in the level designs and then change PLAYER_INDEX in the LevelManager class to equal this number. Then the camera will focus on it and you can see more of each level when you run the game. When the player is added to the game the camera will center around Bob.

Summary

That was a big chapter, but much was achieved. We were introduced to the Java HashMap class and the Singleton pattern which together enabled us to code the BitmapStore class to save memory by avoiding duplicate copies of Bitmap instances. We coded the component classes for all the platforms that Bob will walk on as well as the decorative component classes that will handle things like trees and stalagmites.

We coded a new GameObjectFactory that was like the previous project except it handles multiple different types of Transform. We saw and added the code for the level designs. They are represented by extending a parent Level class.

We also coded the slightly familiar GameObject, GameState, SoundEngine, PhysicsEngine, and Renderer classes.

We learned about and coded the all-new Camera class which tracks the player’s position, keeping him in the center of all the action and translating floating point world coordinates to integer pixel coordinates.

Next, we coded the HUD and the UIController which allows the player to choose a level and draw buttons on the screen when the game is playing.

Finally, we added the main Activity class, GameEngine class, and LevelManager which handles choosing and loading levels to play.

In the next tutorial, we will add a running, jumping, and falling Bob character to the game along with a parallax scrolling background. Although we will need to wait until chapter 25 to implement the collision detection that makes him playable and interactive with the other game objects.

This project is taken from a previous version of my book Learning Java by Building Android Games. The latest version, version 3 went into more detail in earlier projects and so this project did not fit. Some of what I say in this tutorial (and the next 3 tutorials) assume you have read one of the books but a determined beginner should be able to complete this project. I have been unwell for a few years and this tutorial should have been published in 2020. May I also bring to your attention my new books (and website) for getting started with crypto.

You can get the code and the graphical assets from Git Hub starting from the Chapter 22 folder onwards here. Chapters 22… refer to parts 1… etc of these articles.

Welcome to the start of the biggest project on my site. Over the next four long articles, we will build a platform game packed full of features like parallax effect scrolling, animated controllable characters, multiple different and challenging levels, and much more.

During this project, we will discover Java patterns like the Singleton, another Java data class, and the HashMap, and explore the gaming concepts of a controllable camera and an animator.

At the same time, we will reinforce all the Java concepts we have already learned including aiding our understanding of and improving upon the entity-component/factory patterns we used in the previous project.

Here is what we will do in part 1:

• Discuss how we will build the Platformer project including design patterns, Camera class, level design files, graphics handling using the Singleton pattern, and a Transform class
• Actually, get started coding the Platformer project
• Specify all the game objects with ObjectSpec classes
• Code the interfaces for the components that we will begin coding in the next tutorial
• Code the communications interfaces like EngineController, GameEngineBroadcaster, and InputObserver

Be sure to read the next paragraph box. It is probably the most useful in the book.

Important

The first 2 articles of this project are long, and the classes are all interdependent with each other- they are parts of a system. The project is not executable until the end of Article 2. You can read and code articles 1 and 2 a step at a time if you like but it will take quite a while- make sure you have at least a day to spare. Alternatively, you could just read articles 1 and 2 and carefully review the code and the patterns to make sure you understand what is happening. Then you could simply add the graphics and sound (explained in this chapter), and create 2 packages (explained in part 2 specifying all the game objects with GameObjectSpec classes section and part 2 Create the levels section). Then you can just copy and paste all the class files from Chapter 2 folder of the download bundle into the proper package of your project (via the Android Studio project explorer window). You will then need to make sure/correct a few lines of text in a few files to do with importing your new packages and the first part of the engine can be working within an hour’s work- after having first read through parts 1 and 2 thoroughly.

Choose whichever method you find the most rewarding.

WARNING! If you don’t read the two articles first you won’t understand how to make the package import corrections, you won’t understand the structure of the code, and the code won’t work.

Now we can make a start. Let’s call the platformer, Bob was in a hurry.

Platform Game: Bob Was in A Hurry

This is the most advanced game on Game Code School. It has multiple levels and hundreds of game objects per level. The player must get from the start of the level, find and then reach the exit. The fastest times are kept as high scores for each of the three levels. However, there are also collectible coins scattered throughout the levels, and a time penalty is added to the finish time for each one left uncollected. Precise jumps are required, and the best route is not always obvious so a player wanting to do well will need to explore and experiment. The whole level is not visible on the screen all at once. The level can be dozens of times the size of the screen, so exploration is required to see the whole thing.

Let’s have a look at some screenshots to understand the game better.

In the previous image, you can see the home screen. The text labeled as number one is the fastest time for each of the three levels, Underground, Mountains, and Cave. Double tapping on the appropriate third of the screen will start the level and the timer.

Take a look at this next image taken from the Underground level.

The levels each have their own distinctive background to set them apart from each other and there is also a good selection of decorative objects, platform designs and obstacles for each level. We will see more of the graphics soon. In the previous image notice the following things:

1. The time is in the top left-hand corner. The format is as follows: number of seconds taken so far + number of penalty seconds that can be removed by collecting all the coins.
2. Number two highlights the collectible coins.
3. Number three highlights an animated fire tile. The tile will flicker, making it obvious this tile is bad for the player’s health. The slightest touch will end the level and send the player back to the home screen.
4. Number 4 is a Death tile. We need to stop the player from accidentally getting out of the level into an eternal fall. By surrounding possible exits with Death tiles, we can end the game when the player falls or gets themselves into an impossible position. The tiles use a distinctive graphic to make level design and debugging clearer. In the finished game, you would use a transparent (invisible) graphic or change it to something that matched the level.

This next image shows the Mountain level which is mainly a series of awkward jumps. The part highlighted in number 1 is the level destination. When the player reaches the highlighted game object the game goes back to the home screen and if they got a faster time it will be updated.

The next level shown below is the City level. I have borrowed the background from the previous project.

In the image, I have highlighted three rectangles. They are moving platforms. They go up and down a distance of 10 blocks. Once you see how to code them, it will be trivial to add horizontal movement or vary the distance they travel.

How we will build the game

By going through a few things in advance albeit not in great detail will give a clearer picture of how the project will eventually turn into a fully-fledged game by the end of  Part 4.

Level design files example

In all the previous projects we spawned objects like bats, balls, snakes, apples, aliens, bullets, and lasers based on logic in our code. With this game, we need a way to sit back a little and design each level. There are a few different ways we could have done this. We could draw the levels in a graphics application like Paint or Photoshop and then write code to turn a level design image into a game. Another option is to write an entire app that allows the user to select different game objects and then drag and drop them around the screen. The application could then save the design and use it in the game. I opted for the method to lay out the level designs in text, in Android Studio. In the designs, different, alpha-numeric characters would represent different game objects. This is visual and allows the game designer to create, test and tweak quite easily and is also quite simple to implement.

Take a look at this image of one of the level design files. Also, open the Chapter 23/Levels folder in the download bundle. Open the files and you can examine them more closely than the image allows.

I don’t provide the level files in the book because they are entirely impractical to try and present them on the page. Remember that the download bundle is free and quick to get hold of on the book’s page on the Packt website- in case you haven’t got it already.

This next image is a zoomed-out view of the game that the game engine translated the previous text file into.

The zoomed-out effect was achieved using the Camera class that we will explore soon.

We will look at the level designs and which letters/numbers to use in greater detail in the next chapter.

The graphics

Here is all the graphics provided for this project.

Notice the graphics we will use as tiles for the player to walk on (coal, concrete, scorched, snow, stone, turf). And look at the graphics that will be purely decorative (no collisions or interactions), dead_tree, lamppost, snowy_tree, stalactite, stalagmite, and the three backgrounds, city, mountain, and underground. There are also two obstacle graphics. Obstacles are things that don’t do anything but will need to be jumped over. These are cart and stone_pile. Notice the coin graphic which is the time-saving collectible. The graphic named platform is the moving platform mentioned earlier.

There are two graphics not mentioned so far. Look at a close-up of the player graphic.

The player graphic is a sprite sheet. It is a series of frames of animation. Only one of the representations of Bob is shown on screen at any given frame of the game. But our code will loop through them one at a time to create an animated walking effect. This will be controlled by a class called Animator.

Now have a look at the fire graphic which is also a sprite sheet and will create a flickering fire animation.

We have seen the graphics, we know how we will decide their layout although we haven’t seen any code yet but how will we decide which part of the game world should be on the player’s screen at any given frame?

Cameras and the real world

The answer to the question is a special class that can be thought of as the camera which is recording the gameplay. Look at the next image.

The image is a mock-up made in a simple graphics package that attempts to illustrate the camera in action. We can think of most of the game world existing off-screen and unseen and just the relevant portion being shown on-screen.

In the previous project, the player’s ship sat in the middle of the screen and the way we made it look like the ship was moving was a bit of a bodged job. The scrolling background did most of the work but the various …AlienMovementComponent based classes helped too. They took account of the direction the player was facing/flying and moderated (sped up or slowed down) their movement towards or away from the player accordingly. There is a better way.

In this project, all the game objects will have world coordinates. The coordinates held by each of the objects will have no connection to pixels on the screen. It could be simpler if you think about these coordinates as virtual meters. In fact, Bob is 2 units tall which is about the height of a not untypical human. Each and every piece of platform, scenery, collectible, Bob, and even the background will have a position in the game world as well as a width and height (also in virtual meters) and not know anything about the screen resolution.

Whenever we move an object we will do so in virtual metres. Whenever we do collision detection we will do so in virtual metres. The virtual meter coordinates can still be held in a RectF and the width and height (in virtual meters) can still be held in a PointF. However, when the objects are drawn to the screen the Camera class will calculate whereabouts- if at all they get drawn. The camera will follow the player so as Bob moves around, and his virtual meters-based coordinates change the camera will reposition on-screen the objects drawn around him creating the illusion of moving through the game world.

We get to see the code for this in the next chapter and it is surprisingly straightforward.

The slightly modified ObjectSpec

In the previous project, because of the lack of a camera, we had slightly ambiguous values for width, height, and speed. We used relative values that would cause them to scale to the screen size on the device it was running on. In this project, because we have the Camera we can use our new virtual meters. This will make the ObjectSpec class (which all the specification classes drive from) much clearer. We will see this class and code all the specification classes for the entire project, later this chapter.

New improved transform hierarchy

Also, in this project, we will write better code for the Transform of the game objects. We crammed way too much into the Transform class of the Scrolling Shooter project. It was a bad design, but it served the purpose of getting the project done without getting any bigger.

If the Scrolling Shooter project was an ongoing thing that was going to be extended it would be worth re-writing the Transform class and using a Camera class as well.

For the Platformer project, we will have a base/parent Transform class that has much less data in it and suits just the simple game objects like platforms and decorations and we will extend this class to create a BackgroundTransform and PlayerTransform with much more specific methods and data but also still allowing access to the base class’s data and methods.

We will code the Transform class in the next chapter and the two extended classes across the rest of the project.

Project patterns

The Entity-Component pattern will be used for every game object in this project just as it was in the previous one. We will not need any spawn-related component classes, however, because starting positions will be determined by the level layout files and none of the objects need to respawn (as the aliens and lasers did).

We will still need a component class that handles what happens during the update phase of the game loop but as many of the objects don’t move we will have an UpdateComponent interface instead of a MovementComponent interface. Same job with a new name.

We will still have a GraphicsComponent interface as we did in Scrolling Shooter. We will code these interfaces after we have coded the specification classes later in this chapter.

We will still need to communicate from the GameState class to the GameEngine and will again have an EngineController interface to achieve this. Furthermore, we will use the Observer pattern in the exact same way as before to handle communicating the user’s input with the classes that need to know about it.

We will also still be using a GameEngineFactory class to construct GameObject instances using component classes based on the various specification classes. This time the class will need to be a bit smarter to make sure each GameObject instance gets the correct type of Transform. Otherwise, this class will be very familiar. As already stated we will code all the specifications in a minute but the components themselves will take shape over the rest of the project.

BitmapStore

In this project, some of the levels will have hundreds of game objects. In all the previous projects the game object classes held a copy of the required bitmap. In the Snake game we drew lots of body segments and this was OK because the Snake class reused the body graphic over and over. The platforms, however, will only know about themselves, not all the other platforms. This implies that if there is a platform that is 100 tiles long we will need 100 game objects with 100 copies of the graphic. That is not only a waste of memory and processing power but might even cause older Android devices to crash because they have run out of memory. In the next chapter, we will code a BitmapStore class whose only job is to store and share bitmaps. Therefore, if there is a length of the platform in the game that is 1000 blocks wide if they are all the same object, perhaps turf, then there will only be one copy of the bitmap.

Levels and LevelManager

In the previous project, we had the Level class. It defined which object types and how many of them were in the game. It used the GameObjectFactory class to construct the objects we wanted in the game. If we had wanted more divers and fewer chasers we would have made changes to Level. If we had invented a new type of alien or a smart bomb for the player, we would have added it to the Level class. Most games have more than one level and this platformer is no exception.

To handle this, we will create a Level class and then extend it to create specific levels called LevelCave, LevelMountain and LevelCity. These Level-based classes will hold all the details of the specific level of the game. We will then create a LevelManager class that will understand how to use the GameObjectFactory class to load the required level when prompted to do so by the GameState class which will work in a similar way to the previous project.

Getting started with Bob was in a hurry

Now we can make a start with the project. Remember that you can do this step by step. All the instructions that follow assume you are doing it step by step, but you could just read Chapter 22 and Chapter 23 and then refer back to the information box at the start of this chapter to do a super-quick copy & paste job to get the project to its first runnable state.

Final warning! The author recommends you don’t attempt to do the copy and paste job until you have thoroughly studied chapters 22 and 23 as there are key things you need to be aware of or the copy & paste won’t work.

Creating the project and adding the assets

Create a new project called Platformer with an empty Activity called GameActivity, no layout file and without backward compatibility; just as we have for every project in the book.

Grab the project’s graphics from the download bundle; they are in Chapter 22/drawable folder. Highlight the contents of this folder and copy them. Now right-click the drawable folder in the Android Studio solution explorer and select Paste.

Get the sound files from the download bundle in Chapter 22/assets folder. Copy the entire assets folder including the folder itself. Now, using your operating systems file browser navigate to the Platformer/app/src/main and paste the assets folder into your project.

As usual, we want to make the game full-screen and locked in landscape orientation. As a reminder, here is how to edit the AndroidManifest.xml file:

1. Make sure the xml file is open in the editor window.
2. In the xml file, locate the following line of code: android:name=”.GameActivity”>
3. Place the cursor before the closing > shown above. Tap the Enter key a couple of times to move the > a couple of lines below the rest of the line shown above.
4. Immediately below GameActivity but before the newly positioned > type or copy and paste these two lines to make the game run full screen and lock it in the landscape orientation.

android:theme="@android:style/Theme.NoTitleBar.Fullscreen"

android:screenOrientation="landscape"

Specifying all the game objects with GameObjectSpec classes

In the previous project, the folder with all our class files was getting a bit crowded. This project will have even more classes, so we will help ourselves a little by separating things out into different packages. We will have a folder(package) for all the GameObjectSpec related classes and a folder for all the Level-related classes. Everything else will remain in the usual folder.

When you create a new package, it is important to do so in the correct folder. The correct folder is the same one that we have been putting all the Java files in throughout this book. If you call this project Platformer it will be the app/java/yourdomain.platformer folder.

In the Android Studio solution explorer, right-click the app/java/yourdomain.platformer (NOT yourdomain.platformer(androidTest) and NOT yourdomain.platformer(test)), select New | Package and  name it GOSpec.

We will now add a whole bunch of classes that will define all the objects of the game; their sizes, tags (for collision detection mainly), speed, starting location, associated graphic file, frames of animation and a list of components that define their behavior.

There is one parent class, GameObjectSpec from which all the other specification classes extend. There are lots of them, 23 in total and I don’t recommend you sit there and type them all in. They can all be found in the download bundle in the Chapter 22/java/GOSpec folder. You can highlight all the files, copy them and then right-click and Paste them all into the GOSpec folder/package you just created. What you might need to do manually is click into them and check that the package declaration at the top of each file was correctly auto-adjusted from my package name to yours.

If you used Platformer as the project title your package name should be:

package yourdomain.platformer.GOSpec;

If you check three or four files and the package was auto-adjusted correctly then chances are good that they all were, and you don’t need to check all 23.

While the specification classes are very similar, I thought it still advantageous to show all the code because they are worth examining. Flick through the next few pages of specification classes. When you look at them take note of the different sizes, speeds, graphics files, frames of animation, and especially the different component names in the components array. Here is the complete listing from all the specification classes with a few notes on each.

In a professionally built game, it would be more typical to load such things from text files with a single line of text per component or attribute. If you want to upgrade your project (wait until you have it all working in Chapter 25 first) you can read about parsing a text file using a simple Web search. However, sorting the required data from the text file is an in-depth process (but not beyond a determined beginner). A simple Web search will provide a good example code to get started. By doing things this way we keep all our work inside Android Studio and get to play with making our own packages.

The following list of 23 classes appears in the same order they will appear in Android Studio with the exception that I present the base/parent class to the other 22 classes first to aid understanding.

GameObjectSpec

This is the class that all the …Spec classes will extend. It provides a related member variable/object instance for each of the specifications a game object can have.

import android.graphics.PointF;


public abstract class GameObjectSpec {

private String mTag;

private String mBitmapName;

private float mSpeed;

private PointF mSize;

private String[] mComponents;

private int mFramesAnimation;


GameObjectSpec(String tag,

String bitmapName,

float speed,

PointF size,

String[] components,

int framesAnimation ){


mTag = tag;

mBitmapName = bitmapName;

mSpeed = speed;

mSize = size;

mComponents = components;

mFramesAnimation = framesAnimation;

}


public int getNumFrames(){

return mFramesAnimation;

}


public String getTag(){

return mTag;

}


public String getBitmapName(){

return mBitmapName;

}


public float getSpeed(){

return mSpeed;

}


public PointF getSize(){

return mSize;

}


public String[] getComponents(){

return mComponents;

}

}

The main method (the constructor) has the job of receiving the specifications from all the child classes and copying the values to the member variables/instances. Our code will then be able to handle instances of GameObjectSpec regardless of what the actual game object is; animated, controllable player through to dumb, unmovable tree.

All the other methods of this class are simple getter methods that the various parts of our program can call to find out more about the game object.

BackgroundCitySpec

Review the code for this class and then we can talk about it.

I will spend more time reviewing this game object because it is the first one we are looking at. In the remaining 22 I will just point out the occasional distinctive feature. It is still important, however, to glance at and make a mental note of the different specifications of the game objects.

import android.graphics.PointF;

public class BackgroundCitySpec extends GameObjectSpec {

// This is all the specifications for the city background

private static final String tag = "Background";

private static final String bitmapName = "city";

private static final int framesOfAnimation = 1;

private static final float speed = 3f;

private static final PointF size = new PointF(100, 70);

private static final String[] components = new String [] {

"BackgroundGraphicsComponent",

"BackgroundUpdateComponent"};



public BackgroundCitySpec() {

super(tag, bitmapName, speed,

size, components, framesOfAnimation);

}

}

The tag is mainly used by the collision detection code we will write in Chapter 25. Even the background which doesn’t collide needs to be identified so that we can discount it from collision detection.

The bitmapName variable holds the name of the graphics file that is used to represent this game object.

The framesOfAnimation variable is set to 1 because this is not a sprite sheet. The player object on the other hand will be set to 5 because that’s how many frames there are and the fire object’s framesOfAnimation will be set to 3.

The speed variable in this project is different from that in the previous project because it is the speed in virtual meters per second rather than some convoluted measure relative to the player as it was in the last. Now we are making the jump to game-world-based coordinates using a camera we can use these more real-world-based size and speed measures.

Next up is size and you can consider the city to be 100 meters by 70 meters. When we code the Camera class in the next chapter we will see how these virtual meters translate to pixels and how we know which parts to show on the screen of the game at any given frame.

We also have a String array for a list of components just like we did in the previous project. The actual components themselves, however, will be different to the previous project.

The exception to this is this object, the background, which has very similar components.

Notice the two actual components we will need to code to bring this game object to life:

BackgroundGraphicsComponent

BackgroundUpdateComponent

Finally, notice the constructor that does nothing other than pass all the specifications into the parent class constructor which as we saw stashes the values away in the appropriate variables.

BackgroundMountainSpec

This is the same as the previous except it uses a different graphic, mountain.png.

import android.graphics.PointF;



public class BackgroundMountainSpec extends GameObjectSpec {

// This is all the specifications for the mountain

private static final String tag = "Background";

private static final String bitmapName = "mountain";

private static final int framesOfAnimation = 1;

private static final float speed = 3f;

private static final PointF size = new PointF(100, 70);

private static final String[] components = new String [] {

"BackgroundGraphicsComponent",

"BackgroundUpdateComponent"};



public BackgroundMountainSpec() {

super(tag, bitmapName, speed, size,

components, framesOfAnimation);

}

}

BackgroundUndergroundSpec

This is the same as the previous except it uses a different graphic.

import android.graphics.PointF;



public class BackgroundUndergroundSpec extends GameObjectSpec {

// This is all the specifications for the underground

private static final String tag = "Background";

private static final String bitmapName = "underground";

private static final int framesOfAnimation = 1;

private static final float speed = 3f;

private static final PointF size = new PointF(100, 70f);

private static final String[] components = new String [] {

"BackgroundGraphicsComponent",

"BackgroundUpdateComponent"};



public BackgroundUndergroundSpec() {

super(tag, bitmapName, speed, size,

components, framesOfAnimation);

}

}

Review the specifications and move on.

BrickTileSpec

This is a regular platform tile. Bob will be able to walk on it, so we will need to perform collision detection on it. Its position in the game world never changes so it is technically inanimate. Note though that the relative position of the block on the screen to the camera will change and the brick graphic will need to be drawn accordingly but the Camera class will take care of all of that.

import android.graphics.PointF;



public class BrickTileSpec extends GameObjectSpec {



private static final String tag = "Inert Tile";

private static final String bitmapName = "brick";

private static final int framesOfAnimation = 1;

private static final float speed = 0f;

private static final PointF size = new PointF(1f, 1f);

private static final String[] components = new String[]{

"InanimateBlockGraphicsComponent",

"InanimateBlockUpdateComponent"};



public BrickTileSpec() {

super(tag, bitmapName, speed,

size, components, framesOfAnimation);

}

}

Finally, notice the size is just one virtual meter wide and high.

CartTileSpec

This specification has the same components as the previous one but note we can assign any value for the size we like. This mine cart object is two meters by one meter. The graphic must of course be drawn to suit the size otherwise it will appear squashed or stretched.

import android.graphics.PointF;



public class CartTileSpec extends GameObjectSpec {

private static final String tag = "Inert Tile";

private static final String bitmapName = "cart";

private static final int framesOfAnimation = 1;

private static final float speed = 0f;

private static final PointF size = new PointF(2f, 1f);

private static final String[] components = new String[]{

"InanimateBlockGraphicsComponent",

"InanimateBlockUpdateComponent"};



public CartTileSpec() {

super(tag, bitmapName, speed, size,

components, framesOfAnimation);

}

}

Review the specifications and move on.

CoalTileSpec

Just another walkable tile.

import android.graphics.PointF;



public class CoalTileSpec extends GameObjectSpec {

private static final String tag = "Inert Tile";

private static final String bitmapName = "coal";

private static final int framesOfAnimation = 1;

private static final float speed = 0f;

private static final PointF size = new PointF(1f, 1f);

private static final String[] components = new String [] {

"InanimateBlockGraphicsComponent",

"InanimateBlockUpdateComponent"};



public CoalTileSpec() {

super(tag, bitmapName, speed, size,

components, framesOfAnimation);

}

}

Review the specifications and move on.

CollectibleObjectSpec

Although this next object has quite a different use to say the brick object, notice that everything is the same apart from the graphic file and the tag. This is fine.

import android.graphics.PointF;



public class CollectibleObjectSpec extends GameObjectSpec {

private static final String tag = "Collectible";

private static final String bitmapName = "coin";

private static final int framesOfAnimation = 1;

private static final float speed = 0f;

private static final PointF size = new PointF(1f, 1f);

private static final String[] components = new String [] {

"InanimateBlockGraphicsComponent",

"InanimateBlockUpdateComponent"};



public CollectibleObjectSpec() {

super(tag, bitmapName, speed, size,

components, framesOfAnimation);

}

}

We can detect a collision and determine that it is a collectible item from its tag and then handle what should happen.

ConcreteTileSpec

Just another walkable tile.

import android.graphics.PointF;



public class ConcreteTileSpec extends GameObjectSpec {

private static final String tag = "Inert Tile";

private static final String bitmapName = "concrete";

private static final int framesOfAnimation = 1;

private static final float speed = 0f;

private static final PointF size = new PointF(1f, 1f);

private static final String[] components = new String [] {

"InanimateBlockGraphicsComponent",

"InanimateBlockUpdateComponent"};



public ConcreteTileSpec() {

super(tag, bitmapName, speed, size,

components, framesOfAnimation);

}

}

Review the specifications and move on.

DeadTreeTileSpec

This tile has minor differences to those we have seen so far. Firstly, it is quite large 2 metres by 4 metres. It also uses a DecorativeBlockUpdateComponent instead of an InanimateBlockUpdateComponent. The differences between these components in code is small but useful. As trees are just decoration in the background we will not bother to add or update a collider thus saving a few computation cycles per tree, per frame.

import android.graphics.PointF;



public class DeadTreeTileSpec extends GameObjectSpec {

private static final String tag = "Inert Tile";

private static final String bitmapName = "dead_tree";

private static final int framesOfAnimation = 1;

private static final float speed = 0f;

private static final PointF size = new PointF(2f, 4f);

private static final String[] components = new String [] {

"InanimateBlockGraphicsComponent",

"DecorativeBlockUpdateComponent"};



public DeadTreeTileSpec() {

super(tag, bitmapName, speed, size,

components, framesOfAnimation);

}

}

Review the code and move on.

FireTileSpec

This is the first component we have seen that has more than one frame of animation. Our code will detect that an Animator object needs to be assigned to this game object and will manage a simple flickering effect on the fire tile using the frames from the sprite sheet fire.png.

import android.graphics.PointF;



public class FireTileSpec extends GameObjectSpec {

private static final String tag = "Death";

private static final String bitmapName = "fire";

private static final int framesOfAnimation = 3;

private static final float speed = 0f;

private static final PointF size = new PointF(1f, 1f);

private static final String[] components = new String[]{

"AnimatedGraphicsComponent",

"InanimateBlockUpdateComponent"};



public FireTileSpec() {

super(tag, bitmapName, speed, size,

components, framesOfAnimation);

}

}

Also, notice that the AnimatedGraphicsComponent is used instead of the InanimateBlockGraphicsComponent.

GrassTileSpec

This is another walkable tile.

import android.graphics.PointF;



public class GrassTileSpec extends GameObjectSpec {

private static final String tag = "Inert Tile";

private static final String bitmapName = "turf";

private static final int framesOfAnimation = 1;

private static final float speed = 0f;

private static final PointF size = new PointF(1f, 1f);

private static final String[] components = new String[]{

"InanimateBlockGraphicsComponent",

"InanimateBlockUpdateComponent"};



public GrassTileSpec() {

super(tag, bitmapName, speed, size,

components, framesOfAnimation);

}

}

Review the code and move on.

This next spec is for the blocks that will cause the player to instantly die and end the game. It helps the level designer prevent embarrassing bugs like falling out of the game world.

LamppostTileSpec

This is the same as the tree that we discussed previously except for the size and the graphic. Review the specifications and move on.

import android.graphics.PointF;



public class LamppostTileSpec extends GameObjectSpec {

private static final String tag = "Inert Tile";

private static final String bitmapName = "lamppost";

private static final int framesOfAnimation = 1;

private static final float speed = 0f;

private static final PointF size = new PointF(1f, 4f);

private static final String[] components = new String[]{

"InanimateBlockGraphicsComponent",

"DecorativeBlockUpdateComponent"};



public LamppostTileSpec() {

super(tag, bitmapName, speed, size,

components, framesOfAnimation);

}

}

Review the code and move on.

MoveablePlatformSpec

This game object is new. Notice the MovableBlockUpdateComponent. We will code these to make these platforms move in the game world allowing the player to jump on them and be transported up and down.

import android.graphics.PointF;



public class MoveablePlatformSpec extends GameObjectSpec {

private static final String tag = "Movable Platform";

private static final String bitmapName = "platform";

private static final int framesOfAnimation = 1;

private static final float speed = 3f;

private static final PointF size = new PointF(2f, 1f);

private static final String[] components = new String [] {

"InanimateBlockGraphicsComponent",

"MovableBlockUpdateComponent"};



public MoveablePlatformSpec() {

super(tag, bitmapName, speed, size,

components, framesOfAnimation);

}

}

Note that we can still use a regular InanimateBlockGraphicsComponent. Just in case it is causing confusion, inanimate refers to the fact it doesn’t use a sprite sheet (has no frames of animation), we can still change its location in the game world (move it) via the MoveableBlockUpdateComponent.

ObjectiveTileSpec

The objective game object is an important game object because it triggers the player to reach the end of the level. However, as with the collectible object all the significant functionality can be handled by the PhysicsEngine via its unique tag, and no new components or features are needed for this game object’s specification.

import android.graphics.PointF;



public class ObjectiveTileSpec extends GameObjectSpec {

private static final String tag = "Objective Tile";

private static final String bitmapName = "objective";

private static final int framesOfAnimation = 1;

private static final float speed = 0f;

private static final PointF size = new PointF(3f, 3f);

private static final String[] components = new String[]{

"InanimateBlockGraphicsComponent",

"InanimateBlockUpdateComponent"};



public ObjectiveTileSpec() {

super(tag, bitmapName, speed, size,

components, framesOfAnimation);

}

}

PlayerSpec

This is perhaps unsurprisingly our most advanced game object. It has an AnimatedGraphicsComponent just as the fire tile does so that it sprite sheet graphic is used to animate its appearance. It also has a specific PlayerUpdateComponent that will be much more advanced than all the other …Update… components. It will handle things like moving, jumping and falling. The PlayerInputComponent will communicate with the GameEngine class to receive and translate the players screen touches. The communication method will use the same Observer pattern that we learnt for the previous project.

import android.graphics.PointF;



public class PlayerSpec extends GameObjectSpec {

// This is all the unique specifications for a player

private static final String tag = "Player";

private static final String bitmapName = "player";

private static final int framesOfAnimation = 5;

private static final float speed = 10f;

private static final PointF size = new PointF(1f, 2f);

private static final String[] components = new String [] {

"PlayerInputComponent",

"AnimatedGraphicsComponent",

"PlayerUpdateComponent"};



public PlayerSpec() {

super(tag, bitmapName, speed,

size, components, framesOfAnimation);

}

}

Review the code and move on.

ScorchedTileSpec

Another simple walkable object.

import android.graphics.PointF;



public class ScorchedTileSpec extends GameObjectSpec {

private static final String tag = "Inert Tile";

private static final String bitmapName = "scorched";

private static final int framesOfAnimation = 1;

private static final float speed = 0f;

private static final PointF size = new PointF(1f, 1f);

private static final String[] components = new String [] {

"InanimateBlockGraphicsComponent",

"InanimateBlockUpdateComponent"};



public ScorchedTileSpec() {

super(tag, bitmapName, speed, size,

components, framesOfAnimation);

}

}

Review the specifications and move on.

SnowTileSpec

Another simple walkable object.

import android.graphics.PointF;



public class SnowTileSpec extends GameObjectSpec {

private static final String tag = "Inert Tile";

private static final String bitmapName = "snow";

private static final int framesOfAnimation = 1;

private static final float speed = 0f;

private static final PointF size = new PointF(1f, 1f);

private static final String[] components = new String [] {

"InanimateBlockGraphicsComponent",

"InanimateBlockUpdateComponent"};



public SnowTileSpec() {

super(tag, bitmapName, speed, size,

components, framesOfAnimation);

}

}

Review the specifications and move on.

SnowyTreeTileSpec

Just like the dead tree but lusher and covered in snow.

import android.graphics.PointF;



public class SnowyTreeTileSpec extends GameObjectSpec {

private static final String tag = "Inert Tile";

private static final String bitmapName = "snowy_tree";

private static final int framesOfAnimation = 1;

private static final float speed = 0f;

private static final PointF size = new PointF(3f, 6f);

private static final String[] components = new String [] {

"InanimateBlockGraphicsComponent",

"DecorativeBlockUpdateComponent"};



public SnowyTreeTileSpec() {

super(tag, bitmapName, speed, size,

components, framesOfAnimation);

}

}

Review the specifications and move on.

StalactiteTileSpec

This is another purely decorative game object.

import android.graphics.PointF;



public class StalactiteTileSpec extends GameObjectSpec {

private static final String tag = "Inert Tile";

private static final String bitmapName = "stalactite";

private static final int framesOfAnimation = 1;

private static final float speed = 0f;

private static final PointF size = new PointF(2f, 4f);

private static final String[] components = new String [] {

"InanimateBlockGraphicsComponent",

"DecorativeBlockUpdateComponent"};



public StalactiteTileSpec() {

super(tag, bitmapName, speed, size,

components, framesOfAnimation);

}

}

Review the specifications and move on.

StalagmiteTileSpec

This is another purely decorative object.

import android.graphics.PointF;



public class StalagmiteTileSpec extends GameObjectSpec {

private static final String tag = "Inert Tile";

private static final String bitmapName = "stalagmite";

private static final int framesOfAnimation = 1;

private static final float speed = 0f;

private static final PointF size = new PointF(2f, 4f);

private static final String[] components = new String [] {

"InanimateBlockGraphicsComponent",

"DecorativeBlockUpdateComponent"};



public StalagmiteTileSpec() {

super(tag, bitmapName, speed, size,

components, framesOfAnimation);

}

}

Review the specifications and move on.

StonePileTileSpec

A pile of stones the player can jump on.

import android.graphics.PointF;



public class StonePileTileSpec extends GameObjectSpec {

private static final String tag = "Inert Tile";

private static final String bitmapName = "stone_pile";

private static final int framesOfAnimation = 1;

private static final float speed = 0f;

private static final PointF size = new PointF(2f, 1f);

private static final String[] components = new String [] {

"InanimateBlockGraphicsComponent",

"InanimateBlockUpdateComponent"};



public StonePileTileSpec() {

super(tag, bitmapName, speed, size,

components, framesOfAnimation);

}

}

Review the specifications and move on.

Summary of component classes

Looking at the components you will notice the three main types each has. We will therefore need a graphics, update and input related interface. We will code them now. Throughout the rest of this project we will then code the classes that implement these interfaces and match the component classes we just saw in the GameObjectSpec related classes.

Coding the component interfaces

Now we will code an interface to suit each of the components that will make up all the different game objects we have just coded the specifications for. We will not code a different interface for each different component type, rather we will code generic types that relate to them all. Allowing all the different types of update and graphics components to be used polymorphically in our code – as we did in the previous project.

Therefore, we will need an update component interface and a graphics component interface.

You can use copy & paste as you did in the previous section, just be sure to examine the code and understand it to avoid confusion later in the project.

Let’s start with the graphics component.

GraphicsComponent

All graphics components will need to be able to do two things. This means they will need two methods. Note that the implementation of the actual components that implement these interfaces are free to add more methods- and some will. But they will be required to implement the required methods of the interface as a minimum.

Review and add the interface to your project.

import android.content.Context;

import android.graphics.Canvas;

import android.graphics.Paint;

import android.graphics.PointF;



import com.gamecodeschool.platformer.GOSpec.GameObjectSpec;



interface GraphicsComponent {



// Added int mPixelsPerMetre to scale the bitmap to the camera

void initialize(Context c, GameObjectSpec spec,

PointF objectSize, int pixelsPerMetre);



// Updated to take a reference to a Camera

void draw(Canvas canvas, Paint paint,

Transform t, Camera cam);

}

Any component that implements this interface will have to add an implementation for its two methods. Therefore, all the graphics related components will implement this interface we can then be sure that we can just call intitialize and draw on any game object and be confident that they will handle initializing and drawing themselves in a manner appropriate to them.

There are still some errors due to missing classes. These include Camera and Transform. Don’t try and auto-import them because we need to code them first. If you try and auto-import them, you might end up with Android classes that are different from the one that we want. All the classes you need to import at this stage are included in the code listing. Especially take note that we are importing our very own package for the first time. In the listing see this line of code highlighted.

import com.gamecodeschool.platformer.GOSpec.GameObjectSpec;

You will need to adjust this if you used a different domain name to com.gamecodeschool.

UpdateComponent

In the previous project, we had several different …Movement… related component classes and we coded a MovementComponent interface. The update method of GameObject is then called move on each of the appropriate movement-related components. This interface is essential for the same job but as our objects are more diverse using UpdateComponent as the name seemed to make sense. After all trees and platforms aren’t technically moving. Add the UpdateComponent.

interface UpdateComponent {

void update(long fps, Transform t, Transform playerTransform);

}

Every single object will have one of these and get called on each frame of the game.

The player’s transform could have been left out of the argument list of the update method because it is only needed by the background (to see which way the player is moving). However, if we added enemies later they would likely need to know where the player is and what he is doing. So, I left it in rather than create another communication interface between the background and the player.

Coding the other interfaces

There are three more interfaces that we need to code. They are for communications between specific classes of the game. We need the GameState class to be able to trigger a new level via the GameEngine class and we will code the EngineController interface for that.

We will need the GameEngine class to broadcast to multiple input-related classes whenever the player interacts with the screen and we will need these input-related classes to register themselves as observers just as we did in the previous project. For this, we will code the GameEngineBroadcaster interface and the InputObserver interface.

Let’s quickly add them now.

EngineController

Add the EngineController interface as shown next.

interface EngineController {

// This allows the GameState class to start a new level

void startNewLevel();

}

In the next chapter we will make GameEngine implement this interface as well as pass a reference to GameState. GameState will then be able to call the startNewLevel method.

GameEngineBroadcaster

Add the code for the GameEngineBroadcaster interface.

interface GameEngineBroadcaster {



// This allows the Player and UI Controller components

// to add themselves as listeners of the GameEngine class

void addObserver(InputObserver o);

}

This is the first step in wiring up the GameEngine to the classes that need to be able to handle input. Classes that receive a reference to this interface will be able to call the addObserver method and receive all the details of the player’s screen interaction. We will make GameEngine implement this interface in the next chapter.

InputObserver

Add the code for the InputObserver interface as shown next.

import android.graphics.Rect;

import android.view.MotionEvent;

import java.util.ArrayList;



public interface InputObserver {



// This allows InputObservers to be called by GameEngine to handle input

void handleInput(MotionEvent event,

GameState gs, ArrayList<Rect> buttons);

}

Each of the classes that handle input will implement this interface and the required method (handleInput). They will also share an InputObserver reference via the addObserver method and our control system will be all set up and ready to go. We will do these final steps during the next chapter.

Summary

There was a lot of talk and theory in this chapter but hopefully it has set us up ready to make fast progress in the next. There was no runnable code in this chapter but in the next we will have a home screen with high scores and even be able to tap the screen to choose a level and see the beginnings of each of the playable levels.

The image above shows what we are aiming for in this project. Everything you need can be copied & pasted from the pages that make up this tutorial.

Programming the Ball class

Create a new class called

Ball

MainActivity

The Ball member variables

First, add some variables. An

RectF

<float

float

m

Add the member variables to the Ball class.

public class Ball {

    private RectF mRect;
    private float mXVelocity;
    private float mYVelocity;
    private float mBallWidth;
    private float mBallHeight;

}

The Ball constructor

In the

Ball

Note that this is a little bit different from what we did in the Snake project. We will see how we control this shortly.

Next, we call

new

RectF

Ball

public Ball(int screenX, int screenY){

	// Make the mBall size relative to the screen resolution
	mBallWidth = screenX / 100;
	mBallHeight = mBallWidth;

	/*
		Start the ball travelling straight up
		at a quarter of the screen height per second
	*/
	mYVelocity = screenY / 4;
	mXVelocity = mYVelocity;

	// Initialize the Rect that represents the mBall
	mRect = new RectF();

}

More Ball methods

Next, we will code a

public

RectF

Ball

getRect

Ball

// Give access to the Rect
public RectF getRect(){
	return mRect;
}

Next, we will code the

update

update

Ball

update

PongView

update

mXVelocity

mYVelocity

fps

We have yet to see how the frames per second are calculated but by moving the ball relative to the frames per second, it will move at a consistent speed regardless of how powerful(or puny) the device’s processor is.

After this the other points of

mRect

Add the code for the

update

Ball

// Change the position each frame
public void update(long fps){
	mRect.left = mRect.left + (mXVelocity / fps);
	mRect.top = mRect.top + (mYVelocity / fps);
	mRect.right = mRect.left + mBallWidth;
	mRect.bottom = mRect.top - mBallHeight;
}

Next, we need a few more methods that will enable us to easily deal with various events that will occur throughout the game. At various times in the game, we need to be able to do the following:

• Reverse the vertical direction
• Reverse the horizontal direction
• Set a new random x velocity
• Speed up the ball

The

reverseYVelocity

reverseXVelocity

setRandomXVelocity

increaseVelocity

Add the four methods we have just discussed to the

Ball

// Reverse the vertical heading
public void reverseYVelocity(){
	mYVelocity = -mYVelocity;
}

// Reverse the horizontal heading
public void reverseXVelocity(){
	mXVelocity = -mXVelocity;
}

public void setRandomXVelocity(){

	// Generate a random number either 0 or 1
	Random generator = new Random();
	int answer = generator.nextInt(2);

	if(answer == 0){
		reverseXVelocity();
	}
}

// Speed up by 10%
// A score of over 20 is quite difficult
// Reduce or increase 10 to make this easier or harder
public void increaseVelocity(){
	mXVelocity = mXVelocity + mXVelocity / 10;
	mYVelocity = mYVelocity + mYVelocity / 10;
}

Next, we will add some more methods that do the following things.

One which clears an obstacle on the vertical axis (

clearObstacleY

clearObstacleX

reset

Each of these methods adjusts/repositions the ball. Their usefulness will become apparent when we see them in action when we code the

PongView

public void clearObstacleY(float y){
	mRect.bottom = y;
	mRect.top = y - mBallHeight;
}

public void clearObstacleX(float x){
	mRect.left = x;
	mRect.right = x + mBallWidth;
}

public void reset(int x, int y){
	mRect.left = x / 2;
	mRect.top = y - 20;
	mRect.right = x / 2 + mBallWidth;
	mRect.bottom = y - 20 - mBallHeight;
}

Now our ball can start bouncing. Let’s get the bat coded and then we can code the game engine.

Programming the Bat class

The class has a

RectF

mXcoord

mYCoord

We have a

float

mBatSpeed

final int

STOPPED

LEFT

RIGHT

public

We also have a

private

mBatMoving

public final

STOPPED

Bat

mScreenX

mScreenY

Add the Bat member variables that we have just discussed.

public class Bat {

    // RectF is an object that holds four coordinates - just what we need
    private RectF mRect;

    // How long and high our mBat will be
    private float mLength;
    private float mHeight;

    // X is the far left of the rectangle which forms our mBat
    private float mXCoord;

    // Y is the top coordinate
    private float mYCoord;

    // This will hold the pixels per second speed that
	 // the mBat will move
    private float mBatSpeed;

    // Which ways can the mBat move
    public final int STOPPED = 0;
    public final int LEFT = 1;
    public final int RIGHT = 2;

    // Is the mBat moving and in which direction
    private int mBatMoving = STOPPED;

    // The screen length and width in pixels
    private int mScreenX;
    private int mScreenY;

}

Coding the Bat constructor

Now, we will add the constructor method. In the constructor method, we initialize

mScreenX

mScreenY

Next, the code initializes

mXCoord

mYCoord

mBatSpeed

mScreenX

Add the code for the Bat constructor.

// This is the constructor method
// When we create an object from this class we will pass
// in the screen width and mHeight
public Bat(int x, int y){

	mScreenX = x;
	mScreenY = y;

	// 1/8 screen width wide
	mLength = mScreenX / 8;

	// 1/25 screen mHeight high
	mHeight = mScreenY / 25;

	// Start mBat in roughly the sceen centre
	mXCoord = mScreenX / 2;
	mYCoord = mScreenY - 20;

	mRect = new RectF(mXCoord, mYCoord, mXCoord + mLength, mYCoord + mHeight);

	// How fast is the mBat in pixels per second
	mBatSpeed = mScreenX;
	// Cover entire screen in 1 second
}

More Bat methods

Add the

public

RectF

// This is a getter method to make the rectangle that
// defines our bat available in PongView class
public RectF getRect(){
	return mRect;
}

The

setMovementState

int

public final int

LEFT

RIGHT

STOPPED

mBatMoving

// This method will be used to change/set if the mBat is going
// left, right or nowhere

public void setMovementState(int state){
	mBatMoving = state;
}

The final method for the

Bat

update

if

mXCoord

mBatSpeed

fps

Ball

Next, it does two checks to see if the bat might be moving off the screen. If the bat is about to disappear off the left it prevents it by setting

mXCoord

mXCoord

mScreenX

Finally, based on the results of all those

if

RectF

getRect

// This update method will be called from update in PongView
// It determines if the Bat needs to move and changes the coordinates
// contained in mRect if necessary
public void update(long fps){

	if(BatMoving == LEFT){
		mXCoord = mXCoord - mBatSpeed / fps;
	}

	if(BatMoving == RIGHT){
		mXCoord = mXCoord + mBatSpeed / fps;
	}

	// Make sure it's not leaving screen
	if(mRect.left < 0){ mXCoord = 0; } if(mRect.right > mScreenX){
		mXCoord = mScreenX -
				// The width of the Bat
				(mRect.right - mRect.left);
	}

	// Update the Bat graphics
	mRect.left = mXCoord;
	mRect.right = mXCoord + mLength;
}

Programming the MainActivity class

Most of the action will take place in the next class that we create. We will call that class

PongView

MainActivity

PongView

PongView

PongView

In the

onCreate

Display

getWindowManager().getDefaultDisplay()

Point

Display

point

getSize

We can now call the constructor of

PongView

pongView

x

y

PongView

Bat

Ball

Finally, in

onCreate

PongView

setContentView

PongView

PongView

SurfaceView

Thread

implements onTouchListener

Canvas

Go ahead and add the variables and the new code to the

onCreate

// pongView will be the view of the game
// It will also hold the logic of the game
// and respond to screen touches as well
PongView pongView;

@Override
protected void onCreate(Bundle savedInstanceState) {
	super.onCreate(savedInstanceState);

	// Get a Display object to access screen details
	Display display = getWindowManager().getDefaultDisplay();

	// Load the resolution into a Point object
	Point size = new Point();
	display.getSize(size);

	// Initialize pongView and set it as the view
	pongView = new PongView(this, size.x, size.y);
	setContentView(pongView);

}

We are almost finished with the

MainActivity

MainActivity

onResume

onPause

resume

pause

PongView

PongView

PongView

onCreate

onResume

onPause

onResume

onPause

MainActivity

// This method executes when the player starts the game
@Override
protected void onResume() {
	super.onResume();

	// Tell the pongView resume method to execute
	pongView.resume();
}

// This method executes when the player quits the game
@Override
protected void onPause() {
	super.onPause();

	// Tell the pongView pause method to execute
	pongView.pause();
}

Now we can code the most important class of our game.

Programming the SurfaceView (PongView)

Create a new class called

PongView

extend SurfaceView

implement Runnable

• A

  Thread

  called

  mGameThread

  that we will start and stop from the

  pause

  and

  resume

  methods that we will implement soon. These methods are of course called by the

  onResume

  and

  onPause

  methods of the

  MainActivity

  class

• SurfaceHolder

  is what we need to allow us to do to our drawing

• Volatile boolean mPlaying

  will be

  true

  when the thread is running and

  false

  otherwise. It will be used to determine whether we enter a

  while

  loop that will control the whole game loop. The

  volatile

   the keyword is used because mPlaying can be accessed from outside and inside the thread.
• We have a

  boolean mPaused

  which will determine whether the game is currently paused.
• We have a

  Paint

  and an

  Canvas

  object which we will use to draw and draw on respectively.
• Next, we have a

  long

  variable

  mFPS

  which will hold the current number of frames per second that our game loop is achieving and of course, this is the value we will be passing into the

  update

  methods of

  Bat

  and

  Ball

  to allow them to move by the correct amount.
• Next, we declare

  mScreenX

  and

  mScreenY

  to hold the screen resolution which as we saw, is passed into the constructor from

  MainActivity

  when we instantiate an

  PongView

  object. We will code that constructor very soon.
• Now we get to the fun bits; a

  Ball

  object

  mBall

  and a

  Bat

  object

  mBat

  .
• Next up we have all the members that will take care of sound FX including a

  SoundPool

  and four

  int

  identifiers for sound FX.
• Finally

  mLives

  and

  mScore

  will keep track of the player’s score and how many lives they have left

Code the

PongView

class PongView extends SurfaceView implements Runnable {

    // This is our thread
    Thread mGameThread = null;

    // We need a SurfaceHolder object
    // We will see it in action in the draw method soon.
    SurfaceHolder mOurHolder;

    // A boolean which we will set and unset
    // when the game is running- or not
	// It is volatile because it is accessed from inside and outside the thread
    volatile boolean mPlaying;

    // Game is mPaused at the start
    boolean mPaused = true;

    // A Canvas and a Paint object
    Canvas mCanvas;
    Paint mPaint;

    // This variable tracks the game frame rate
    long mFPS;

    // The size of the screen in pixels
    int mScreenX;
    int mScreenY;

    // The players mBat
    Bat mBat;

    // A mBall
    Ball mBall;

    // For sound FX
    SoundPool sp;
    int beep1ID = -1;
    int beep2ID = -1;
    int beep3ID = -1;
    int loseLifeID = -1;

    // The mScore
    int mScore = 0;

    // Lives
    int mLives = 3;
}

Let’s discuss the constructor method for

PongView

We initialize

mScreenX

mScreenY

mOurHolder

getHolder

mPaint

Paint

Bat

Ball

Almost all the rest of the code sets up the sound effects ready to be played. I have gone through the trouble in this code to detect the version of Android and use the appropriate code depending upon the version. The final line of code calls the

setupAndRestart

Add the

PongView

/*
	When the we call new() on pongView
	This custom constructor runs
*/

public PongView(Context context, int x, int y) {

	/*
		The next line of code asks the
		SurfaceView class to set up our object.
	*/
	super(context);

	// Set the screen width and height
	mScreenX = x;
	mScreenY = y;

	// Initialize mOurHolder and mPaint objects
	mOurHolder = getHolder();
	mPaint = new Paint();

	// A new mBat
	mBat = new Bat(mScreenX, mScreenY);

	// Create a mBall
	mBall = new Ball(mScreenX, mScreenY);

	/*
		Instantiate our sound pool
		dependent upon which version
		of Android is present
	*/

	if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
		AudioAttributes audioAttributes = new AudioAttributes.Builder()
				.setUsage(AudioAttributes.USAGE_MEDIA)
				.setContentType(AudioAttributes.CONTENT_TYPE_SONIFICATION)
				.build();

		sp = new SoundPool.Builder()
				.setMaxStreams(5)
				.setAudioAttributes(audioAttributes)
				.build();

	} else {
		sp = new SoundPool(5, AudioManager.STREAM_MUSIC, 0);
	}

	try{
		// Create objects of the 2 required classes
		AssetManager assetManager = context.getAssets();
		AssetFileDescriptor descriptor;

		// Load our fx in memory ready for use
		descriptor = assetManager.openFd("beep1.ogg");
		beep1ID = sp.load(descriptor, 0);

		descriptor = assetManager.openFd("beep2.ogg");
		beep2ID = sp.load(descriptor, 0);

		descriptor = assetManager.openFd("beep3.ogg");
		beep3ID = sp.load(descriptor, 0);

		descriptor = assetManager.openFd("loseLife.ogg");
		loseLifeID = sp.load(descriptor, 0);

		descriptor = assetManager.openFd("explode.ogg");
		explodeID = sp.load(descriptor, 0);

	}catch(IOException e){
		// Print an error message to the console
		Log.e("error", "failed to load sound files");
	}

	setupAndRestart();

}

Here is the

setupAndRestart

reset

Ball

mScore

mLives

3

setupAndRestart

PongView

public void setupAndRestart(){

	// Put the mBall back to the start
	mBall.reset(mScreenX, mScreenY);

	// if game over reset scores and mLives
	if(mLives == 0) {
		mScore = 0;
		mLives = 3;
	}

}

Here we have the

run

while

volatile boolean

mPlaying

while

run

Inside the

while

startFrameTime

if(!mPaused)

update

update

PongView

Ball

Bat

update

Next, we call the

draw

startFrameTime

mFPS

update

Ball

Bat

if (timeThisFrame >= 1)

timeThisFrame

Code the overridden run method.
@Override
public void run() {
	while (mPlaying) {

		// Capture the current time in milliseconds in startFrameTime
		long startFrameTime = System.currentTimeMillis();

		// Update the frame
		// Update the frame
		if(!mPaused){
			update();
		}

		// Draw the frame
		draw();

		/*
			Calculate the FPS this frame
			We can then use the result to
			time animations in the update methods.
		*/
		long timeThisFrame = System.currentTimeMillis() - startFrameTime;
		if (timeThisFrame >= 1) {
			mFPS = 1000 / timeThisFrame;
		}

	}

}

Programming the update method

The

update

update

// Everything that needs to be updated goes in here
// Movement, collision detection etc.
public void update(){

}

First, the code calls the

update

Ball

Bat

// Everything that needs to be updated goes in here
// Movement, collision detection etc.
public void update() {

	// Move the mBat if required
	mBat.update(mFPS);

	mBall.update(mFPS);
}

Now the ball and the bat are in their new positions for this frame, we can run some tests to see if anything we need to respond to has happened. The first test is to see if the ball has hit the bat. Using the

getRect

Ball

Bat

static intersects

RectF

intersects

true

if

• Call

  setRandomXVelocity

  on the ball to choose a random horizontal direction for when the ball heads back up the screen
• Call

  reverseYVelocity

  to start to head back up the screen
• call

  clearObstacle

  which jumps the ball a few pixels and avoids the possibility of the ball getting stuck on the bat
• Increment

  mScore

  to increase the player’s score
• Play a beep sound from the

  SoundPool

Add the code we have just discussed to the

update

	// Check for mBall colliding with mBat
	if(RectF.intersects(mBat.getRect(), mBall.getRect())) {
		mBall.setRandomXVelocity();
		mBall.reverseYVelocity();
		mBall.clearObstacleY(mBat.getRect().top - 2);

		mScore++;
		mBall.increaseVelocity();

		sp.play(beep1ID, 1, 1, 0, 0, 1);
	}

Next, we handle what happens if the ball hits the bottom of the screen. The test to see if this has happened works by calculating the position of the underside of the ball (

mBall.getRect.bottom

mScreenY

if

• Reverse the velocity of the ball
• Jump a few pixels in case the ball gets stuck
• decrement

  mLives

• play a losing sound
• Check if that was the last life and if it is, then pause the game and call

  setupAndRestart

Add the code we have just discussed to the

update

	// Bounce the mBall back when it hits the bottom of screen
	if(mBall.getRect().bottom > mScreenY){
		mBall.reverseYVelocity();
		mBall.clearObstacleY(mScreenY - 2);

		// Lose a life
		mLives--;
		sp.play(loseLifeID, 1, 1, 0, 0, 1);

		if(mLives == 0){
			mPaused = true;
			setupAndRestart();
		}
	}

The next block of code uses the top of the ball and compares it to zero to see if it has reached the top of the screen. If it has it just reverses the ball on the vertical axis, clears any potential obstacles, and plays a beep.

Add the new code to the

update

	// Bounce the mBall back when it hits the top of screen
	if(mBall.getRect().top < 0){
		mBall.reverseYVelocity();
		mBall.clearObstacleY(12);

		sp.play(beep2ID, 1, 1, 0, 0, 1);
	}

The next block of code uses the left of the ball and compares it to zero to see if it has reached the left of the screen. If it has it reverses the ball on the horizontal axis, clears any obstacles and plays a beep.

Add the new code to the

update

	// If the mBall hits left wall bounce
	if(mBall.getRect().left < 0){
		mBall.reverseXVelocity();
		mBall.clearObstacleX(2);

		sp.play(beep3ID, 1, 1, 0, 0, 1);
	}

The next code block uses the right of the ball and compares it to

mScreenX

Add the new code we have just discussed to the

update

	// If the mBall hits right wall bounce
	if(mBall.getRect().right > mScreenX){
		mBall.reverseXVelocity();
		mBall.clearObstacleX(mScreenX - 22);

		sp.play(beep3ID, 1, 1, 0, 0, 1);
	}

}

Programming the draw method

The first thing we have to do is attempt to get a lock on the surface to draw on and check it is valid. This is achieved with the following line of code. (don’t add it just yet)

// Make sure our drawing surface is valid or we crash
	if (mOurHolder.getSurface().isValid()) {

	// Draw everything here

}

If the test returns true we are almost ready to draw. We just need this code before we start using our canvas (don’t add this yet).

// Lock the mCanvas ready to draw
mCanvas = mOurHolder.lockCanvas();

Now we can get busy and actually draw things with

mPaint

mCanvas

• Make sure the surface is valid and lock the canvas as previously discussed
• Draw a background color
• Change the brush color
• Draw the bat as a rectangle by passing in

  getRect

  as the argument
• Draw the ball as a rectangle by calling

  getRect

  as the argument
• Change the brush color again
• Change the size of the text
• Draw the score and number of lives on the screen
• Call

  mOurHolder.unlockCanvasAndPost(mCanvas)

  to finish the drawing process for this frame

Add the

draw

PongView

// Draw the newly updated scene
public void draw() {

	// Make sure our drawing surface is valid or we crash
	if (mOurHolder.getSurface().isValid()) {

		// Draw everything here

		// Lock the mCanvas ready to draw
		mCanvas = mOurHolder.lockCanvas();

		// Clear the screen with my favorite color
		mCanvas.drawColor(Color.argb(255, 120, 197, 87));

		// Choose the brush color for drawing
		mPaint.setColor(Color.argb(255, 255, 255, 255));

		// Draw the mBat
		mCanvas.drawRect(mBat.getRect(), mPaint);

		// Draw the mBall
		mCanvas.drawRect(mBall.getRect(), mPaint);

		// Change the drawing color to white
		mPaint.setColor(Color.argb(255, 255, 255, 255));

		// Draw the mScore
		mPaint.setTextSize(40);
		mCanvas.drawText("Score: " + mScore + "   Lives: " + mLives, 10, 50, mPaint);

		// Draw everything to the screen
		mOurHolder.unlockCanvasAndPost(mCanvas);
	}

}

Now we can code our

pause

resume

MainActivity

// If the Activity is paused/stopped
// shutdown our thread.
public void pause() {
	mPlaying = false;
	try {
		mGameThread.join();
	} catch (InterruptedException e) {
		Log.e("Error:", "joining thread");
	}

}

// If the Activity starts/restarts
// start our thread.
public void resume() {
	mPlaying = true;
	mGameThread = new Thread(this);
	mGameThread.start();
}

Adding touch controls

One of the last important pieces of our Pong game is handling the user’s touches. To make the controls as easy as possible we will say that holding anywhere on the right will move the Bat right and anywhere on the left will move left.

When the

onTouchEvent

MotionEvent.ACTION_DOWN

motionEvent.getX

if

if(motionEvent.getX() > mScreenX / 2){

}

This detects if the screen has been touched at a position further to the right than the width of the screen divided by two (the right-hand side). If the above is true we simply call

Bat.setMovementState(mBat.RIGHT)

Bat

update

if

Bat.setMovementState(mBat.LEFT)

We also need to remember to stop the bat if the player removes their finger from the screen. We handle this in the

MotionEvent.ACTION_UP

onTouchEvent

// The SurfaceView class implements onTouchListener
// So we can override this method and detect screen touches.
@Override
public boolean onTouchEvent(MotionEvent motionEvent) {

	switch (motionEvent.getAction() & MotionEvent.ACTION_MASK) {

		// Player has touched the screen
		case MotionEvent.ACTION_DOWN:

			mPaused = false;

			// Is the touch on the right or left?
			if(motionEvent.getX() > mScreenX / 2){
				mBat.setMovementState(mBat.RIGHT);
			}
			else{
				mBat.setMovementState(mBat.LEFT);
			}

			break;

		// Player has removed finger from screen
		case MotionEvent.ACTION_UP:

			mBat.setMovementState(mBat.STOPPED);
			break;
	}
	return true;
}

If you are wondering why we set

mPaused

false

MotionEvent.ACTION_DOWN

Adding the sound files to the project

The only assets we need for this project are some sound effects. Using your operating go to the “app/src/main” folder of the project, add a new folder, and name it “assets”. There are four sound files that we need and they are linked below.

beep1
beep2
beep3
loselife

Place these files into the “assets” directory you just made.

Lock the screen orientation and make full-screen

We can achieve this by editing the AndroidManifest.xml file as shown next.

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.gamecodeschool.pong" >

    <application android:allowBackup="true" android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:theme="@style/AppTheme" >
        <activity android:name=".MainActivity" android:theme="@android:style/Theme.NoTitleBar.Fullscreen" android:screenOrientation="landscape" android:label="@string/app_name" >
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />

                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>

</manifest>

And we’re ready to play!

Take a look at this image to see the game at the start.

One dot for the snake and one dot for Bob waiting to be eaten. Before anyone complains that snakes don’t eat Bobs, they don’t eat apples either. As the game continues and many Bobs are eaten the snake grows in length making it more likely that the player will trap or eat himself.

Let’s start coding.

Coding the Snake Activity

As usual, we will start with an Activity that will control a thread in a class that controls the game and handles input from the player. If you want a more in-depth discussion of the interaction between the Activity and the main class then take a look at the Breakout tutorial.

Create a new project in Android Studio, use the Empty Activity template, and call it Snake. Leave the rest of the settings at their defaults. Call the Activity SnakeActivity and amend its code to be the same as this.

import android.app.Activity;
import android.graphics.Point;
import android.os.Bundle;
import android.view.Display;
 
public class SnakeActivity extends Activity {
 
    // Declare an instance of SnakeEngine
	// We will code this soon
    SnakeEngine snakeEngine;
 
}

Here we declare an instance of

SnakeEngine

snakeEngine

onCreate

SnakeActivity

SnakeEngine

import android.app.Activity;
import android.graphics.Point;
import android.os.Bundle;
import android.view.Display;
 
public class SnakeActivity extends Activity {
 
    // Declare an instance of SnakeEngine
    SnakeEngine snakeEngine;
 
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
 
        // Get the pixel dimensions of the screen
        Display display = getWindowManager().getDefaultDisplay();
 
        // Initialize the result into a Point object
        Point size = new Point();
        display.getSize(size);
 
        // Create a new instance of the SnakeEngine class
        snakeEngine = new SnakeEngine(this, size);
 
        // Make snakeEngine the view of the Activity
        setContentView(snakeEngine);
    }
}

The

onCreate

Display

Point

[widgets_on_pages id=”udemy_advert_java_2″]

Now we can code the onPause and onResume methods. Add the following code. Again. for a full explanation read the Breakout tutorial but basically Android will call these

onPause

onResume

SnakeEngine

// Start the thread in snakeEngine
@Override
protected void onResume() {
	super.onResume();
	snakeEngine.resume();
}

// Stop the thread in snakeEngine
@Override
protected void onPause() {
	super.onPause();
	snakeEngine.pause();
}

Making the game fullscreen and landscape

We want to use every pixel that the device has to offer so we will make changes to the app’s AndroidManifest.xml configuration file.

• In the project explorer pane in Android Studio double click on the manifests folder, this will open up the AndroidManifest.xml file in the code editor.
• In the AndroidManifest.xml file, locate the following line of code: android:name=”.SnakeActivity”>
• Place the cursor before the closing > shown above. Tap the enter key a couple of times to move the > a couple of lines below the rest of the line shown above.
• Immediately below ParallaxActivity but BEFORE the newly positioned > type or copy and paste these two lines to make the game run full screen and lock it in the landscape orientation.

android:theme="@android:style/Theme.NoTitleBar.Fullscreen"
android:screenOrientation="landscape"

Add the sound to the project

Download the sounds by right-clicking on the files listed below. Add them to the Snake project by using your operating system’s file browser go to the app\src\main folder of the project and create a new folder called assets. Add your sound files to this folder. Here are my sound effects. Right-click and select Save link as… to download them.

Note: At the moment my Web host seems to be restricting me from uploading .ogg files. Just look at one of my other projects, download the files from them, and rename them to suit below.  You could also make your own or download the bonus content (above). Sorry will fix this as soon as I can.

snake_crash

eat_bob

We can now get rid of the errors by moving on to the SnakeEngine class.

Coding SnakeEngine

Add a new class called SnakeEngine and amend the code as shown next so we have all the required imports.

import android.content.Context;
import android.content.res.AssetFileDescriptor;
import android.graphics.Point;
import android.media.AudioManager;
import android.media.SoundPool;
import android.view.MotionEvent;
import android.view.SurfaceHolder;
import android.view.SurfaceView;
import java.io.IOException;
import java.util.Random;
import android.content.res.AssetManager;
import android.graphics.Canvas;
import android.graphics.Color;
import android.graphics.Paint;

 
class SnakeEngine extends SurfaceView implements Runnable {
     
}

When we extend

SurfaceView

setContentView

SnakeActivity

Runnable

Thread

Thread

Runnable

run

The SnakeEngine variables

Add all the member variables after the class declaration then they will be ready for use as we proceed through the rest of the code.

// Our game thread for the main game loop
private Thread thread = null;

// To hold a reference to the Activity
private Context context;

// for plaing sound effects
private SoundPool soundPool;
private int eat_bob = -1;
private int snake_crash = -1;

// For tracking movement Heading
public enum Heading {UP, RIGHT, DOWN, LEFT}
// Start by heading to the right
private Heading heading = Heading.RIGHT;

// To hold the screen size in pixels
private int screenX;
private int screenY;

// How long is the snake
private int snakeLength;

// Where is Bob hiding?
private int bobX;
private int bobY;

// The size in pixels of a snake segment
private int blockSize;

// The size in segments of the playable area
private final int NUM_BLOCKS_WIDE = 40;
private int numBlocksHigh;

// Control pausing between updates
private long nextFrameTime;
// Update the game 10 times per second
private final long FPS = 10;
// There are 1000 milliseconds in a second
private final long MILLIS_PER_SECOND = 1000;
// We will draw the frame much more often

// How many points does the player have
private int score;

// The location in the grid of all the segments
private int[] snakeXs;
private int[] snakeYs;

// Everything we need for drawing
// Is the game currently playing?
private volatile boolean isPlaying;

// A canvas for our paint
private Canvas canvas;

// Required to use canvas
private SurfaceHolder surfaceHolder;

// Some paint for our canvas
private Paint paint;

We can now code the constructor.

Coding the SnakeEngine constructor

Add this code next, be sure to add it inside the closing curly brace of the

SnakeEngine

public SnakeEngine(Context context, Point size) {
	super(context);

	context = context;

	screenX = size.x;
	screenY = size.y;

	// Work out how many pixels each block is
	blockSize = screenX / NUM_BLOCKS_WIDE;
	// How many blocks of the same size will fit into the height
	numBlocksHigh = screenY / blockSize;

	// Set the sound up
    soundPool = new SoundPool(10, AudioManager.STREAM_MUSIC, 0);
    try {
        // Create objects of the 2 required classes
        // Use m_Context because this is a reference to the Activity
        AssetManager assetManager = context.getAssets();
        AssetFileDescriptor descriptor;
 
        // Prepare the two sounds in memory
        descriptor = assetManager.openFd("get_mouse_sound.ogg");
        eat_bob = soundPool.load(descriptor, 0);
 
        descriptor = assetManager.openFd("death_sound.ogg");
        snake_crash = soundPool.load(descriptor, 0);
 
    } catch (IOException e) {
        // Error
    }


	// Initialize the drawing objects
	surfaceHolder = getHolder();
	paint = new Paint();

	// If you score 200 you are rewarded with a crash achievement!
	snakeXs = new int[200];
	snakeYs = new int[200];

	// Start the game
	newGame();
}

First, we initialize, 

context

screenX

screenY

SnakeActivity

NUM_BLOCKS_WIDE

blockSize

Next, the sound files are loaded and associated with an appropriately named identifier. They are now ready to play at will with

soundPool.playSound

What follows is we initialize

surfaceHolder

paint

[widgets_on_pages id=”udemy_advert_java_3″]

After this, we initialized the two

int

snakeXs

snakeYs

The last part of the code we call the

newGame

newGame

Making the thread run the game loop

All in the run method, including method calls from the run method, works in a separate thread to the Android UI. This will allow our game to run smoothly at the same time as listening for player input. Add the run method as well as pause and resume and then we will talk about them.

@Override
public void run() {
	
	while (isPlaying) {

		// Update 10 times a second
		if(updateRequired()) {
			update();
			draw();
		}

	}
}    

public void pause() {
	isPlaying = false;
	try {
		thread.join();
	} catch (InterruptedException e) {
		// Error
	}
}

public void resume() {
	isPlaying = true;
	thread = new Thread(this);
	thread.start();
}

The

pause

resume

SnakeActivity

onPause

onResume

resume

Thread

pause

Thread

Everything in, and called by the run method, will now happen in a separate thread.

The

run

update

draw

while

isPlaying

true

These calls are also contained within

if(updateRequired())

true

update

draw

updateRequired

Some more methods

As we saw, the

newGame

public void newGame() {
    // Start with a single snake segment
    snakeLength = 1;
    snakeXs[0] = NUM_BLOCKS_WIDE / 2;
    snakeYs[0] = numBlocksHigh / 2;
 
    // Get Bob ready for dinner
    spawnBob();
 
    // Reset the score
    score = 0;
 
    // Setup nextFrameTime so an update is triggered
    nextFrameTime = System.currentTimeMillis();
}

In the

newGame method

spawnBob

score

The final bit of code in the

newGame

nextFrameTime

update

draw

Spawning and eating Bob

The spawnBob method uses two random int values within the ranges of zero and NUM_BLOCKS_WIDE, zero and numBlocksHigh, then initializes the horizontal and vertical location of the mouse.

public void spawnBob() {
    Random random = new Random();
    bobX = random.nextInt(NUM_BLOCKS_WIDE - 1) + 1;
    bobY = random.nextInt(numBlocksHigh - 1) + 1;
}

Optimization tip: Instantiating a new instance of

Random

spawnBob

The

eatBob

The snake’s length is increased by one block, a new mouse is spawned, 1 is added to the score and a sound effect is played.

Here is the code for the

eatBob

spawnBob

private void eatBob(){
    //  Got him!
    // Increase the size of the snake
    snakeLength++;
    //replace Bob
	// This reminds me of Edge of Tomorrow. Oneday Bob will be ready!
    spawnBob();
    //add to the score
    score = score + 1;
    soundPool.play(eat_bob, 1, 1, 0, 0, 1);
}

The

moveSnake

private void moveSnake(){
    // Move the body
    for (int i = snakeLength; i > 0; i--) {
        // Start at the back and move it
        // to the position of the segment in front of it
        snakeXs[i] = snakeXs[i - 1];
        snakeYs[i] = snakeYs[i - 1];
 
        // Exclude the head because
        // the head has nothing in front of it
    }
 
    // Move the head in the appropriate heading
    switch (heading) {
        case UP:
            snakeYs[0]--;
            break;
 
        case RIGHT:
            snakeXs[0]++;
            break;
 
        case DOWN:
            snakeYs[0]++;
            break;
 
        case LEFT:
            snakeXs[0]--;
            break;
    }
}

The

for

snakeXs

snakeYs

for

Therefore, as long as we handle the head properly all the other blocks will be correctly positioned too.

To move the head we

switch

In the

detectDeath

private boolean detectDeath(){
    // Has the snake died?
    boolean dead = false;
 
    // Hit the screen edge
    if (snakeXs[0] == -1) dead = true;
    if (snakeXs[0] >= NUM_BLOCKS_WIDE) dead = true;
    if (snakeYs[0] == -1) dead = true;
    if (snakeYs[0] == numBlocksHigh) dead = true;
 
    // Eaten itself?
    for (int i = snakeLength - 1; i > 0; i--) {
        if ((i > 4) && (snakeXs[0] == snakeXs[i]) && (snakeYs[0] == snakeYs[i])) {
            dead = true;
        }
    }
 
    return dead;
}

If either of the collision possibilities happens then

detectDeath

true

update

Coding the update method

This method does three things:

1. It checks if the head has touched/eaten a mouse. If it has then the

   eatBob

   method handles things.
2. It calls the

   moveSnake

   method which was coded previously.
3. It calls the

   detectDeath

   method and if it returns

   true

   a sound is played and the game begins again.

All this happens ten times per second because of the way

updateRequired

updateRequired

public void update() {
    // Did the head of the snake eat Bob?
    if (snakeXs[0] == bobX && snakeYs[0] == bobY) {
        eatBob();
    }
 
    moveSnake();
 
    if (detectDeath()) {
        //start again
        soundPool.play(snake_crash, 1, 1, 0, 0, 1);
 
        newGame();
    }
}

Drawing the game

Add all the code for the

draw

public void draw() {
	// Get a lock on the canvas
	if (surfaceHolder.getSurface().isValid()) {
		canvas = surfaceHolder.lockCanvas();

		// Fill the screen with Game Code School blue
		canvas.drawColor(Color.argb(255, 26, 128, 182));

		// Set the color of the paint to draw the snake white
		paint.setColor(Color.argb(255, 255, 255, 255));

		// Scale the HUD text
		paint.setTextSize(90);
		canvas.drawText("Score:" + score, 10, 70, paint);

		// Draw the snake one block at a time
		for (int i = 0; i < snakeLength; i++) {
			canvas.drawRect(snakeXs[i] * blockSize,
					(snakeYs[i] * blockSize),
					(snakeXs[i] * blockSize) + blockSize,
					(snakeYs[i] * blockSize) + blockSize,
					paint);
		}

		// Set the color of the paint to draw Bob red
		paint.setColor(Color.argb(255, 255, 0, 0));

		// Draw Bob
		canvas.drawRect(bobX * blockSize,
				(bobY * blockSize),
				(bobX * blockSize) + blockSize,
				(bobY * blockSize) + blockSize,
				paint);

		// Unlock the canvas and reveal the graphics for this frame
		surfaceHolder.unlockCanvasAndPost(canvas);
	}
}

First, we lock the surface which is required by Android. If this works, we clear the screen with

drawColor

setColor

We use a

for

blockSize

Now we can draw a single block to represent Bob.

Coding updateRequired

We are almost done!

The

updateRequired

nextFrameTime

nextFrameTime

true

false

You can now add the updateRequired method.

public boolean updateRequired() {
 
    // Are we due to update the frame
    if(nextFrameTime <= System.currentTimeMillis()){
        // Tenth of a second has passed
 
        // Setup when the next update will be triggered
        nextFrameTime =System.currentTimeMillis() + MILLIS_PER_SECOND / FPS;
 
        // Return true so that the update and draw
        // functions are executed
        return true;
    }
 
    return false;
}

Handling screen touches (player input)

The final code handles the player removing their finger. Holding won’t work. The

onTouchEvent

motionEvent.getAction

If they tap on the left side of the screen then the snake moves to the next direction in the enumeration going anti-clockwise if they tap on the right then it’s clockwise.

It’s meant to be awkward, it is authentic to the original. Add this code to handle touches on the screen.

@Override
public boolean onTouchEvent(MotionEvent motionEvent) {
 
    switch (motionEvent.getAction() & MotionEvent.ACTION_MASK) {
        case MotionEvent.ACTION_UP:
            if (motionEvent.getX() >= screenX / 2) {
               switch(heading){
                   case UP:
                       heading = Heading.RIGHT;
                       break;
                   case RIGHT:
                       heading = Heading.DOWN;
                       break;
                   case DOWN:
                       heading = Heading.LEFT;
                       break;
                   case LEFT:
                       heading = Heading.UP;
                       break;
               }
            } else {
                switch(heading){
                    case UP:
                        heading = Heading.LEFT;
                        break;
                    case LEFT:
                        heading = Heading.DOWN;
                        break;
                    case DOWN:
                        heading = Heading.RIGHT;
                        break;
                    case RIGHT:
                        heading = Heading.UP;
                        break;
                }
            }
    }
    return true;
}

You can now play the game!

The first time the effect was used in a video game was Atari’s Moon Patrol. Why not take a look at the video in the previous link. Notice the foreground which is plain green with the occasional pot-hole, scrolls at a different(faster) speed to the background hills. It is also possible with more modern hardware (like our Android phones) to have transparent parts to the layers and overlap them with other layers to create a more pleasing effect. Let’s code a parallax scrolling background.

How the parallax effect is achieved in code

The first frame of the game shows the background image like this. Please note these images are not the ones to add to your project. They are shown later in the tutorial.

The way the next frame is shown is to move the image off-screen to the left. So what do we show on the last pixel on the right-hand side of the screen? We will make a reversed copy of the same image and show it to the right of the original(unreversed) image.

As the original image and the reversed image are steadily scrolled to the left, eventually, half of each image will be shown, and so on.

Eventually, we will be reaching the end of the original image and the last pixel on the right-hand-side of the reversed image will eventually be on-screen.

At the point when the reversed image is shown in full on the screen, just like the original image was at the start, we will move the original image over to the right-hand side. The two backgrounds will continuously scroll and as the right-hand image (either original or reversed) becomes the entire view that the player sees, the left-hand image (either original or reversed) will be moved to the right-hand-side ready to be scrolled into view.

Let’s start coding.

Starting the project

Start a new project in Android Studio and choose the Empty Activity template without a layout file because we don’t need loads of auto-generated code and files. All the code and images are available on this page but if you want to help me out by telling others about this page then take a look at my bonus download for this project.

Making the game a full-screen landscape

We want to use every pixel that the device has to offer so we will make changes to the app’s AndroidManifest.xml configuration file.

1. In the project explorer pane in Android Studio double click on the manifests folder, this will open up the AndroidManifest.xml file in the code editor.
2. In the AndroidManifest.xml file, locate the following line of code, 

   android:name=".ParallaxActivity">

3. Place the cursor before the closing > shown above. Tap the enter key a couple of times to move the > a couple of lines below the rest of the line shown above.
4. Immediately below ParallaxActivity but BEFORE the newly positioned > type or copy and paste these two lines to make the game run full screen and lock it in the landscape orientation.

android:theme="@android:style/Theme.NoTitleBar.Fullscreen"
android:screenOrientation="landscape"

The code structure

The code structure for this game is almost the same as the Simple Game Engine tutorial with one extra class and one extra method in the main View-based class. We will call the

Activity

ParallaxActivity

ParallaxView

ParallaxActivity

ParallaxView

onCreate

ParallaxView

Thread

update

draw

update

The class that does all the hard work will be called

Background

Background

update

Background

ParallaxView

ArrayList

ArrayList

The

draw

Coding the Parallax Activity

Add the following code for the

ParallaxActivity

ParallaxView

ParallaxView

import android.app.Activity;
import android.graphics.Point;
import android.os.Bundle;
import android.view.Display;

public class ParallaxActivity extends Activity {

    // Our object to handle the View
    private ParallaxView parallaxView;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        // Get a Display object to access screen details
        Display display = getWindowManager().getDefaultDisplay();

        // Load the resolution into a Point object
        Point resolution = new Point();
        display.getSize(resolution);

        // And finally set the view for our game
        parallaxView = new ParallaxView(this, resolution.x, resolution.y);

        // Make our parallaxView the view for the Activity
        setContentView(parallaxView);

    }

    // If the Activity is paused make sure to pause our thread
    @Override
    protected void onPause() {
        super.onPause();
        parallaxView.pause();
    }

    // If the Activity is resumed make sure to resume our thread
    @Override
    protected void onResume() {
        super.onResume();
        parallaxView.resume();
    }
}

Coding the ParallaxView class

Add a new class to the project called

ParallaxView

update

draw

Background

import android.content.Context;
import android.graphics.Canvas;
import android.graphics.Color;
import android.graphics.Paint;
import android.graphics.Rect;
import android.view.SurfaceHolder;
import android.view.SurfaceView;
import java.util.ArrayList;

public class ParallaxView extends SurfaceView implements Runnable {

    private volatile boolean running;
    private Thread gameThread = null;

    // For drawing
    private Paint paint;
    private Canvas canvas;
    private SurfaceHolder ourHolder;

    // Holds a reference to the Activity
    Context context;

    // Control the fps
    long fps =60;

    // Screen resolution
    int screenWidth;
    int screenHeight;

    ParallaxView(Context context, int screenWidth, int screenHeight) {
        super(context);

        this.context = context;

        this.screenWidth = screenWidth;
        this.screenHeight = screenHeight;

        // Initialize our drawing objects
        ourHolder = getHolder();
        paint = new Paint();

    }

    @Override
    public void run() {

        while (running) {
            long startFrameTime = System.currentTimeMillis();

            update();

            draw();

            // Calculate the fps this frame
            long timeThisFrame = System.currentTimeMillis() - startFrameTime;
            if (timeThisFrame <= 1) {
                fps = 1000 / timeThisFrame;
            }
        }
    }

    private void update() {
        // Update all the background positions

    }

    private void draw() {

        if (ourHolder.getSurface().isValid()) {
            //First we lock the area of memory we will be drawing to
            canvas = ourHolder.lockCanvas();

            //draw a background color
            canvas.drawColor(Color.argb(255, 0, 3, 70));

            // Draw the background parallax

            // Draw the rest of the game
            paint.setTextSize(60);
            paint.setColor(Color.argb(255, 255, 255, 255));
            canvas.drawText("I am a plane", 350, screenHeight / 100 * 5, paint);
            paint.setTextSize(220);
            canvas.drawText("I'm a train", 50, screenHeight / 100*80, paint);

            // Draw the foreground parallax

            // Unlock and draw the scene
            ourHolder.unlockCanvasAndPost(canvas);
        }
    }

    // Clean up our thread if the game is stopped
    public void pause() {
        running = false;
        try {
            gameThread.join();
        } catch (InterruptedException e) {
            // Error
        }
    }

    // Make a new thread and start it
    // Execution moves to our run method
    public void resume() {
        running = true;
        gameThread = new Thread(this);
        gameThread.start();
    }

}// End of ParallaxView

Coding the Background class

Now we get to see how we will implement the parallax scrolling background using the visual technique described at the start of the tutorial. The

Background

Create a new class called

Background

update

import android.content.Context;
import android.graphics.Bitmap;
import android.graphics.BitmapFactory;
import android.graphics.Matrix;

public class Background {

    Bitmap bitmap;
    Bitmap bitmapReversed;

    int width;
    int height;
    boolean reversedFirst;
    float speed;

    int xClip;
    int startY;
    int endY;

    Background(Context context, int screenWidth, int screenHeight, String bitmapName,  int sY, int eY, float s){

    }

    public void update(long fps){

    }
}

Adding the parallax image resources

As the final preparation, add the two images below to the drawable folder in Android Studio.

This image will be the back layer and be positioned at coordinates 0,0 at the top left of the screen (to start with).

Next, we will draw some text at different heights as seen in the draw method we coded previously.

Finally, we will draw this image near the bottom of the screen as the third layer.

Coding the Background class constructor

The constructor is where we get everything ready to call

update

Background(Context context, int screenWidth, int screenHeight, String bitmapName,  int sY, int eY, float s){

	// Make a resource id out of the string of the file name
	int resID = context.getResources().getIdentifier(bitmapName,
			"drawable", context.getPackageName());

	// Load the bitmap using the id
	bitmap = BitmapFactory.decodeResource(context.getResources(), resID);

	// Which version of background (reversed or regular)
	// is currently drawn first (on left)
	reversedFirst = false;

	//Initialise animation variables.

	// Where to clip the bitmaps
	// Starting at the first pixel
	xClip = 0;

	//Position the background vertically
	startY = sY * (screenHeight / 100);
	endY = eY * (screenHeight / 100);
	speed = s;

	// Create the bitmap
	bitmap = Bitmap.createScaledBitmap(bitmap, screenWidth,
			(endY - startY)
			, true);

	// Save the width and height for later use
	width = bitmap.getWidth();
	height = bitmap.getHeight();

	//Create a mirror image of the background (horizontal flip)
	Matrix matrix = new Matrix();
	matrix.setScale(-1, 1);
	bitmapReversed = Bitmap.createBitmap(bitmap, 0, 0, width, height, matrix, true);

}

First, in the constructor, we use the chained

getResources().getIdentifier()

drawable

bitmapName

bitmap

reversedFirst

false

xClip

xClip

update

Here is some code repeated from above.

//Position the background vertically
startY = sY * (screenHeight / 100);
endY = eY * (screenHeight / 100);
speed = s;

This code uses the parameters

sY

eY

s

startY

endY

speed

startY

endY

screenHeight

100

speed

The final part of the code creates a bitmap and captures its size in the

width

height

Matrix

setScale

Coding the Background update method

The

update

xClip

if

else

reversedFirst

xClip

width

ParalaxView

update

public void update(long fps){

        // Move the clipping position and reverse if necessary
        xClip -= speed/fps;
        if (xClip >= width) {
            xClip = 0;
            reversedFirst = !reversedFirst;
        } else if (xClip <= 0) {
            xClip = width;
            reversedFirst = !reversedFirst;

        }
    }

Updating the ParallaxView class

First, declare an ArrayList to hold the type of Background called backgrounds as the first line of code below shows. Note that you only need to add the first line. The rest of the code we added previously.

public class ParallaxView extends SurfaceView implements Runnable {

    ArrayList<Background>; backgrounds;

    private volatile boolean running;
    private Thread gameThread = null;

    // For drawing
    private Paint paint;
    private Canvas canvas;
    private SurfaceHolder ourHolder;

    // Holds a reference to the Activity
    Context context;

    // Control the fps
    long fps =60;

    // Screen resolution
    int screenWidth;
    int screenHeight;

Now, add this extra code in the ParallaxView constructor to initialize the ArrayList and populate it with two backgrounds using calls to the Background constructor we just coded. Note the arguments. The different starting and ending heights along with different image names and speeds.

ParallaxView(Context context, int screenWidth, int screenHeight) {
	super(context);

	this.context = context;

	this.screenWidth = screenWidth;
	this.screenHeight = screenHeight;

	// Initialize our drawing objects
	ourHolder = getHolder();
	paint = new Paint();

	// Initialize our array list
	backgrounds = new ArrayList<>();

	//load the background data into the Background objects and
	// place them in our GameObject arraylist

	backgrounds.add(new Background(
			this.context,
			screenWidth,
			screenHeight,
			"skyline",  0, 80, 50));

	backgrounds.add(new Background(
			this.context,
			screenWidth,
			screenHeight,
			"grass",  70, 110, 200));

	// Add more backgrounds here

}

As the code to draw a background is relatively long and we will use it multiple times we will make it into a method. This drawBackground method will be called from the draw method along with the position in the ArrayList of the background we want to draw. Take a close look at the code and the comments and then we can talk about it a bit.

private void drawBackground(int position) {

	// Make a copy of the relevant background
	Background bg = backgrounds.get(position);

	// define what portion of images to capture and
	// what coordinates of screen to draw them at

	// For the regular bitmap
	Rect fromRect1 = new Rect(0, 0, bg.width - bg.xClip, bg.height);
	Rect toRect1 = new Rect(bg.xClip, bg.startY, bg.width, bg.endY);

	// For the reversed background
	Rect fromRect2 = new Rect(bg.width - bg.xClip, 0, bg.width, bg.height);
	Rect toRect2 = new Rect(0, bg.startY, bg.xClip, bg.endY);

	//draw the two background bitmaps
	if (!bg.reversedFirst) {
		canvas.drawBitmap(bg.bitmap, fromRect1, toRect1, paint);
		canvas.drawBitmap(bg.bitmapReversed, fromRect2, toRect2, paint);
	} else {
		canvas.drawBitmap(bg.bitmap, fromRect2, toRect2, paint);
		canvas.drawBitmap(bg.bitmapReversed, fromRect1, toRect1, paint);
	}

}

The first thing the code does is make a reference to the current background. Actually, this unnecessarily slows the code down a little but  it makes it much more readable as we can refer to

bg.width

backgrounds.get(position).width

In the code, we create four

RectF

Finally, we draw the two images side by side using the four

RectF

if

else

reversedFirst

Updating and drawing the backgrounds

This code simply loops through any

Background

backgrounds

update

draw

drawBackground

private void update() {
	// Update all the background positions
	for (Background bg : backgrounds) {
		bg.update(fps);
	}

}

private void draw() {

	if (ourHolder.getSurface().isValid()) {
		//First we lock the area of memory we will be drawing to
		canvas = ourHolder.lockCanvas();

		//draw a background color
		canvas.drawColor(Color.argb(255, 0, 3, 70));

		// Draw the background parallax
		drawBackground(0);

		// Draw the rest of the game
		paint.setTextSize(60);
		paint.setColor(Color.argb(255, 255, 255, 255));
		canvas.drawText("I am a plane", 350, screenHeight / 100 * 5, paint);
		paint.setTextSize(220);
		canvas.drawText("I'm a train", 50, screenHeight/100*80, paint);

		drawBackground(1);
		// Draw the foreground parallax

		// Unlock and draw the scene
		ourHolder.unlockCanvasAndPost(canvas);
	}
}

We are done!

You can run the game and see the world whizzing by parallax style. Be sure to try different speeds and backgrounds.

Ideally, we should use a viewport solution so that speed and movement happen as a unit of measurement that is independent of the screen resolution. For example, a high-resolution screen will appear to be moving more slowly than a low-resolution screen. I thought I would leave out this issue to focus on the parallax solution. Furthermore, we should really scale the bitmaps relative to the size and resolution of the screen. If for example, you have a more “square” screen than mine your backgrounds might appear a little squashed. When I get around to the simple OpenGL ES series of tutorials we will see how this is solved.

I hope you enjoyed the tutorial. Please let me know either way or if you are stuck.