If you need to generate some nice promotional pictures, it's good sometimes to put them into context of a real device. You can of course take a picture of your phone or tablet with your game, but I bet it won't look good enough.

Here are two tools that can help you generate the art and make it look more professional:

1. Official Google Device Art Generator - which generates the art for Nexus Devices
2. Android Asset Studio - free tool that offers few more devices

In the third part we have created an empty activity. We have set the engine to show "null" as our scene in onCreateScene method. If you check the examples, there is always a real scene created in this method. But we want to have multiple scenes and therefore we need a mechanism how to switch between them.

Also we will need a mechanism to pass important objects to each scene. We can do it when constructing scenes. Or we can use another class called ResourceManager.

Resource manager

This class will be used for our resources like textures, sounds and music. Because all of our scenes will be using it extensively, we will also put some important objects there. Loading the textures etc will be described in the next parts, I will be adding them as they will be needed. For now, create a really simple Resource Manager that looks like this:

package is.kul.squongtutorial.resources;

import is.kul.squongtutorial.GameActivity;

import org.andengine.engine.Engine;
import org.andengine.engine.camera.Camera;
import org.andengine.opengl.vbo.VertexBufferObjectManager;

public class ResourceManager {
  private static final ResourceManager INSTANCE = new ResourceManager();
  
  //common objects
  public GameActivity activity;
  public Engine engine;
  public Camera camera;
  public VertexBufferObjectManager vbom;
  
  private ResourceManager() {}
  
  public static ResourceManager getInstance() {
    return INSTANCE;
  }
  
  public void init(GameActivity activity) {
    this.activity = activity;
    this.engine = activity.getEngine();
    this.camera = engine.getCamera();
    this.vbom = engine.getVertexBufferObjectManager();
  }
}

Update the GameActivity to instantiate the ResourceManager:

  @Override
  public void onCreateResources(
      OnCreateResourcesCallback pOnCreateResourcesCallback)
      throws IOException {
    ResourceManager.getInstance().init(this);
    pOnCreateResourcesCallback.onCreateResourcesFinished();
  }

This class follows what we call Singleton pattern. It means there can be only one instance in the whole program. That's why there is the private constructor, nobody else can create a new instance. It is important to have only single resource manager because due to the limitations of the hardware, you really want to keep only one instance of assets in memory.

For now, we will only use it to have a simple reference to activity, engine, camera and vertex buffer object manager.

Vertex Buffer Object is part of OpenGL. It provides methods to render vertex data. AndEngine does great job of hiding this from you. Simply use the VBO Manager all the time, at least for your first game.

Scene is basically a set of entities that are being currently displayed. You typically want to have completely different entities in menu and in the game. And that's why you create menu scene and game scene.

Android platform suffers from variety of different screen sizes and ratios. AndEngine tries to deal with this by letting you specify one resolution and then scaling the resulting picture to any device.

You don't need to care whether the screen size of the phone is bigger than your desired resolution  (AndEngine can enlarge your scene) or smaller (AndEngine can shrink your scene). You place your sprites at coordinates in your resolution. However you still have to hint AndEngine how should the resulting picture be scaled (if at all). And that's what Resolution Policy is for.

You might want to have multiple sets of textures for let's say two or three typical resolutions. For example low-res, normal and HD textures. But that is a more advanced topic.

So here I am, a month after Giftiz featuring promotion started. The question is now, does Giftiz significantly increase you downloads? The answer is: yes, if your download numbers were very small.

I believe you can make decent money from ad supported game when you reach about 100.000 downloads in the first month based on other people's experience and my own humble beginnings. Giftiz gave me approximately 2300 downloads in a month - 2000 in the first five days.

This might be enough to generate initial interest. A spike in your downloads that will make Google Play store algorithm to notice you and show your game in the Top New Free games. Moreover 20% of these installs come from France. Giftiz is a French company after all. This will give you significant boost in French store.

But it's not good for anything else. The people coming from Giftiz might be able to generate about $10 - $20 revenue on AdMob. They install your game, play until they finish the mission and leave immediately afterwards.

Defense Line is a classic game of tower defense genre made by Sergey Semenov. It is set in near future and you are fighting both current and futuristic units.The game features very detailed graphics and a plethora of different towers. And this is probably the greatest strength of this game.

Combining different towers here is very challenging but a lot of fun. There are many towers that simply cause damage to enemy units, but there are also towers that cause splash damage, area damage or have special abilities.

 Moreover the basic strategy here is spiced by the need of using towers against both ground and ait units. And air units of course follow straight path to the target. Building both your ground and air defense on the limited space you have available can be tough!

Defense line contains two modes: Campaign and Survival. The former is pretty much a standard progression from one map to another. In survival you play a single map as long as you can. This mode is my favourite. Especial the first level which doesn't have any roads or any limitation for the enemy units - you have to build everything using your towers.

My first app (as in "not a game") that will be soon published to the Google Play Store. A simple tool to toggle auto-rotate screen and in case the screen is locked, shake to rotate the screen to desired orientation.

I created the app to learn more about programming for Android. My intention was to learn about the accelerometer, notofications and background services and this is an app that combines all three.


It's still in beta test phase but if you want, you can help testing it.

Many Android 4 phones nowadays have only software buttons (back, home, menu). Unlike hardware buttons they take up space on screen and also don't look very good in games. You might have noticed that it's not possible to hide the button bar completely.

You can hide the system bar using the following:

1. Root the phone and force the system bar to hide - obviously you can't do this for every one of your players
2. Hide buttons temporarily - they show again as soon as you touch the screen
3. Dim buttons - this is called low profile mode

Low profile mode is very useful for games. It looks like this; left picture normal mode, right picture low profile:


This is how to safely implement it. We make sure that the method will be executed only on ICS and higher:

  @SuppressLint("NewApi")
  private void dimSoftButtonsIfPossible() {
    int currentapiVersion = android.os.Build.VERSION.SDK_INT;
    if (currentapiVersion >= android.os.Build.VERSION_CODES.ICE_CREAM_SANDWICH) {
      getWindow().getDecorView().setSystemUiVisibility(View.SYSTEM_UI_FLAG_LOW_PROFILE);
    } 
  }

Note: I am not sure what it does on phones with hardware buttons. If anyone could try and leave a comment - highly appreciated :)

And this is a good way how to use it in AndEngine:

  @Override
  public boolean onKeyDown(int keyCode, KeyEvent event) {
    if (keyCode == KeyEvent.KEYCODE_BACK) {
      // do whatever you need here
      
      dimSoftButtonsIfPossible();
    }
    return false;
  }
  
  @Override
  public void onPopulateScene(Scene pScene,
      OnPopulateSceneCallback pOnPopulateSceneCallback)
      throws IOException {
    // do whatever you need here
    
    runOnUiThread(new Runnable() {
      
      @Override
      public void run() {
        dimSoftButtonsIfPossible();
      }
    });
    pOnPopulateSceneCallback.onPopulateSceneFinished();
  }
  
  @Override
  public synchronized void onResumeGame() {
    super.onResumeGame();
    // do whatever you need here
        
    runOnUiThread(new Runnable() {
      
      @Override
      public void run() {
        dimSoftButtonsIfPossible();
      }
    });

  }
  

From now on, the coding starts. At the end of each part, you should have an app that you can run on your phone.

First, you need to setup your environment. For the purpose of this tutorial I expect you already have Eclipse and AndEngine libraries. If not, you can check my Getting Started with AndEngine tutorial.

It doesn't matter if you download zipped versions or use the GitHub tutorial to get the AndEngine sources.

Note: I use GLES2-AnchorCenter branch of AndEngine for this tutorial.

In this part I will show you the basic activity that I am going to use. The activity class should take care of initializing the game engine and managers. You can see plenty of examples where the activity takes care of the game too. But try to separate functionality - rule of thumb: You should be able to describe the class responsibility by one sentence. If you need to use more than one, it's time to split the class.

Now go ahead and create new Android Application Project (Eclipse -> New).

Pirates Vs. Zombies is another game in a nowadays very popular genre that could be defined as an off-shoot of artillery games - the slingshot games. It all started long time ago and people will argue with what game, but everyone agrees that the most popular game of the genre is Angry Birds.

So what does this game bring new to the genre? First of all it changes the scenery to a tropical region where pirates are looking for burried treasure only to find the islands infested with zombies. Everybody seems to like pirates, zombies and shooting stuff, and that's a good reason to put them in one game together!

But Pirates Vs. Zombies has more to offer. While the gameplay is pretty much standard in this genre, the range of weapons at your disposal is quite innovative. Apart from traditional and advanced projectiles shot from a cannon on a ballistic trajecory, you can use a remote controlled parrot or shoot the zombies from a rifle or shotgun by commanding one of the pirates on the ship. It of course depends on what weapons you have in each level.

Before you start coding, you have to already know how is your game going to look like. Not in all details, but at least a high level view - a concept. It sounds like an obvious fact, but a lot of people will start making a game only to find later that their idea won't work.

You don't need any special tools to create a concept. For a simple game, you can simply think it through. But at least put your thoughts on paper or create a short document.

Creating a concept will help you figure out the basic requirements for your game and having requirements can help you estimate the time and resources needed to finish your game. To be less theoretical, let's look at example.

Squong Game Concept

First, I had an idea to create a pong game for this tutorial. But then I wanted to make the game a bit more complex and I was thinking what can I add or change. First I just thought of making the pong game with more freedom of movement - like a pong where you can move you paddle not just left/right but also up/down. I already thought of using Box2D physics - it is not really neccessary, but good for the purpose of the tutorial. And there was the idea - paddles could collide if they are both on one side of the court. Like in Squash.

If you can figure a name for your game at this stage, good. But don't spend too much time thinking about a cool title. Simply call your game "First Game".

Second, I came up with basic entities in the game. Entity is any object that you will add to the game.

• A paddle - one player, one opponent
• Ball
• Court - and the court consists of
• Walls

Next I tried to think of all possible situations that can happen in Squong. Players must change possession of the ball. That can happen when the ball hits the top wall. But then player could go close to the wall, hit the ball and disallow the opponent to play. So I had to change the possession a little bit further from the top wall. Also the bottom wall should actually be the same as in pong - when the ball exits the court there, player loses:

• Court - and the court consists of
• Walls - top, left and right
• Center line
• Bottom line

And that's it. There's not going to be anything else in the game. Few more thoughts:

• When ball stops, player in possession loses
• When paddle crosses the center line, the owner of the paddle loses

Now I have pretty much what I need to make a game.

Squong Game Requirements

I've already decided that I will use AndEngine. Now let's give a quick thought to the architecture of the game. We are going to need:

• Graphics - paddles, ball - this should be pretty straightforward
• Sounds - ball hits paddle, wall, sound for score or foul. Maybe for change of possession.
• Music - not really needed, but could be nice to have background music in menu (at least for the purpose of a tutorial)
• Physics - paddle, ball, line and wall collisions
•  

This gives us basic idea of what are we going to use from AndEngine.

At this point you can start drawing your entities or thinking where you get them. But don't get stuck. If you don't have them, simply use some mock pictures. A paddle can simply be a rectangle, ball is a circle. You can start looking for sounds and music, but that is a very low priority now.

Scenes

A scene is exactly what the words means. If you look at games, they usually consist of some initial loading scene, that we call Splash. Then you go to Menu scene (a Tap-To-ontinue scene is sometimes present). There can be a Settings scene if you can't fit everything in Menu scene. Then a one of more Game Scenes. Maybe a Credits Scene, Achievments Scene etc. In Squong we are going to use the following. See the flow diagram to understand how the scenes change.


The Info scene will simply be a link to this tutorial. Note that concept of "Exit Game" is a bit complicated in Android, we will get to it later.

This all might seem like a waste of time. You want to be coding already! But trust me. Having these will be very useful later especially in bigger games.

Next part

In the next chapter, we finally start coding!

Further reading

Here's my book about AndEngine and you can see the list of books about Android Game Development for further reading, not just about AndEngine but game development in general.

Note: I had to take a break from writing this tutorial. The game is published in Google Play store now. You can still get the full source code of the final game for 99¢. Available on Sellfy, pay by PayPal:
buy

Also here's one Box2D physics problem that is directly related to the Squong game. If you find a solution, let me know!