Learning Java by Building Android Games - Second Edition

Everything! The Java theory has been reworked and reorganized so if you read the first edition you might recognize a few of the words to be similar but all the games are new. Even the Snake and Pong games which made an appearance in the first edition have totally reworked code now.

This second edition goes much deeper than the previous, into crucial topics like object-oriented programming and goes even further to cover more advanced topics like Java design patterns, loading game levels from files and Java collections.

More game specific topics are covered as well. Collision detection, physics and huge scrolling game worlds using a movable camera are just some of the additions.

Also, more Android topics are covered, including handling different screen sizes/resolutions and input with multiple fingers. And as you would expect if you had read the first edition, everything is put into practice using a game.

It is hard to know which topics should be highlighted in this summary of contents as so many are covered and I urge potential readers to read ahead in this chapter to see the wide range of games we will build together and then look at the table of contents to see the full scope of the Java topics you will learn at the same time.

When Android first arrived in 2008, it was a bit drab compared to the much more stylish iOS on the Apple iPhone/iPad. But quite quickly, through diverse handset offers that struck a chord with both the practical price-conscious as well as the fashion-conscious and tech-savvy, Android user numbers exploded.

For many, myself included, developing Android games is the most rewarding pastime and business bar none.

Quickly putting together, a prototype of a game idea, refining it and then deciding to run with it and wire it up into a fully-fledged game is such an exciting and rewarding process. Any programming can be fun, and I have been programming all my life, but creating games, especially for Android is somehow extraordinarily rewarding.

Defining exactly why this is the case is quite difficult. Maybe it is the fact that the platform is free and open. You can distribute your games without needing the permission of a big controlling corporation - nobody can stop you. And at the same time, you have the well-established, corporate controlled mass markets like Amazon App Store and Google Play.

More likely, the reason developing Android games gives such a buzz is the nature of the devices themselves. They are deeply personal. You can develop games which interact with people's lives. Educate, entertain, tell a story, etc. But it is there in their pocket ready to play in the home, the workplace or on holiday.

You can certainly build something bigger for Windows or Xbox etc. but knowing that thousands (or millions) of people are carrying your work in their pockets and sharing it with friends is more than a buzz.

No longer is developing games considered geeky, nerdy or reclusive. In fact, developing Android games is considered highly skillful and the most successful are hugely admired, even revered.

If all this fluffy and spiritual stuff doesn't mean anything to you then that's fine too; developing for Android can make you a living or even, make you wealthy. With the continued growth of device ownership, the ongoing increase in CPU and GPU power and the non-stop evolution of the Android operating system itself, the need for professional game developers are only going to grow.

In short, the best Android developers – and, more importantly, the Android developers with the best ideas and most determination – are in greater demand than ever. Nobody knows who these future Android game developers are and they might not even have written their first line of Java yet.

So why isn't everybody an Android developer? Obviously, not everybody will share my enthusiasm for the thrill of creating software that can help people make their lives better, but I am guessing that because you are reading this, you might?

Let's look at some of the screen-shots and get a little bit more detail about each of the games from the book. We will go in to further detail and explanation as we start each project.

Sub' Hunter

The first game we build will allow us to introduce some key Java beginner's topics. Code comments, variables, operators, methods, loops, generating random numbers, if, else, switch and a brief introduction to object-oriented programming. We will also see how to communicate with the Android OS, detect screen touches, draw simple graphics, detect the screen resolution and handle different screen sizes. All this will be used to build a simpler variation of the classic Minesweeper type game. Here is one of the screens from that game.

This will be a tap-to-shoot game where the player has to guess the position of the sub', then refine their next shot based on the "sonar" report of the previous shot.

Pong

For the second project, we will slightly increase the complexity and move on to 60 frames per second smoothly animated Pong clone. The Java topics covered include classes, interfaces, threads, try-catch blocks, method overloading vs. overriding and a much deeper look at object-oriented programming including writing and using our own classes. This project will also leave the reader competent with understanding the game loop, simple bouncing physics, playing sound effects and detecting game object collisions. Here is a picture of the simple but still a step-up Pong game.

If the Pong game doesn't seem very busy, then the next game will not only be the exact opposite but will also giv e you the knowledge to improve the first two games.

Bullet Hell

In this project, we will meet Bob. In this Bullet Hell game, Bob will be a static image that can teleport at will anywhere on the screen to avoid the ever-growing number of bullets. In the final game we will also animate Bob, so he can run and jump around an explorable scrolling world. This short implementation will enable us to learn about Java arrays, Bitmap graphics and measuring time. We will also see how we can quite simply use Java arrays alongside what we have already learned about classes to spawn vast numbers of objects in our games.

The objective of Bullet Hell is to survive for as long as possible. If a bullet is about to hit Bob the player can teleport him by tapping the desired destination on the screen, but each teleport spawns more bullets.

Snake Clone

This game is a remake of the classic that has been enraging gamers for decades. Guide your snake around the screen and gaining points by eating apples. Each time you eat an apple your snake gets longer and harder to keep alive. In this project we learn about Java ArrayList, enhanced for loop, the Stack, the Heap and the Garbage collector (seriously- it's a thing) and we will also see how to make our games multilingual. Hola!

The game ends when the snake bumps into the edge of the screen or ends up eating part of his own body.

Scrolling Shooter

This project, technically speaking, is a big step up from Snake. We will learn how to handle multiple different alien types with unique behaviour, appearance and properties. Other features of the game include rapid fire lasers, scrolling background, persistent high score and a cool star-burst particle system explosion effect.

In this project we are introduced to Java and game programming patterns which are key to writing complex games with manageable code. We will learn about and use the Entity-Component pattern, Strategy pattern, Factory pattern and Observer pattern.

The techniques learned in this project are vital if you want to design your own games while structuring your Java code in a way that allows your games to become more complex and yet keep the code manageable.

Open-World Platformer

In this project Bob makes a second appearance. The game will be a time trial where the player must get from the start point to the exit in the fastest time possible. There will be deadly jumps, moving platforms to navigate, fire pits and collectible coins. Every coin the player fails to collect will add a time penalty.

In this project we learn about the concept of a moveable camera that tracks the part of the game-world that needs to be shown to the player at any given moment. We will also learn some new Java patterns and reinforce the vital knowledge from the previous chapter. Furthermore, we will see how we can design levels as text layouts and then load them in code as playable levels.

There are three levels and the player will choose the level they want to play from a home-screen which will also show the fastest times for each level.

Let's learn a little about how Java and Android work.

After we write a game in Java for Android, we click on a button in Android Studio to change our code into another form, a form that is understood by Android devices. We call this "other form" Dalvik EXecutable (DEX) code, and the transformation process is called compiling.

Compiling takes place on the development machine after we click on that button. We will see this work right after we set up our development environment in a minute.

Android is a complex system, but you do not need to understand it in depth, in fact, it is designed to hide the complexity, all operating systems are, and Android does this better than most.

The part of the Android system that executes (runs) our compiled DEX code is called the Dalvik Virtual Machine (DVM). The DVM itself is a piece of software that runs on a specially adapted version of the Linux operating system. So, what the user sees of Android, is, Android just as an app running on yet another operating system. Therefore the apps and games that we write are apps running on top of the app which is Android itself.

The purpose of the DVM is to hide the complexity and diversity of the hardware and software that Android runs on but, at the same time, its purpose is to expose all its useful features. This exposing of features works in two ways.

The DVM itself must have access to the hardware, which it does, but this access must be programmer friendly and easy to use. The way the DVM allows us access is indeed easy to use because of the Android Application Programming Interface (API).

This API is primarily designed to use with Java. In fact, most of the Android API, is itself, Java code. As I may have mentioned already, this makes Android games the most fun and thorough way to learn Android, Java and game development.

If you want to see the relationship between The Android API, DEX code, DVM and an Android device, look at this picture.

Let's set up Android Studio.

Setting up Android Studio is quite straightforward if a little lengthy. Grab some refreshment and get started with the following steps.

Now we can get started on the first game. I will go into a lot more detail about what exactly Sub' Hunter does and how it is played but for now, let's just build something and see our first Android game start to take shape. Then we can run it on an emulator and a real device.

Follow these steps to start the project:

At this stage you might be ready to proceed but depending on the install process you might need to click a couple of extra buttons. This is why I mentioned that we are "probably" finished installing and setting up. Look in the bottom window of Android Studio and see if you have the following message.

Extra step 1

If you do, click Install missing platform(s) and sync project, accept the license agreement and click Next followed by Finish.

Extra step 2

If you get another message like this:

Click Install Build tools…. Then click Finish.

Note

You can tidy up a bit and close this bottom horizontal window by clicking the Messages tab on the very bottom of Android Studio, but this isn't required.

I won't go into all the dozens of different windows and menu options because we will cover them as we need them but here are a few details to help begin getting familiar with Android Studio.

Have a look at the screen below and you will notice two major sections. One on the left and a larger window on the right:

Let's have a look at the panel on the left

The Project panel

The panel on the left can be changed to various different views. We will need it just as it is for virtually the whole book. This is the Project panel/window. Let's take a closer look.

As you can see there are a few folders and sub-folders. For around 90% of every project, we will only need one folder. The folder I am referring to is the Java | com.gamecodeschool.subhunter folder. It is the one with the SubHunter file in it. The little blue C icon to the left of SubHunter indicates that this file is a class and we will explore classes throughout the entirety of this book. The extension of all class files is .java. The extension for class files is not shown in the Project panel. All we need to know for now is that a class file is a file with code in it.

Notice that below the com.gamecodeschool.subhunter folder (with the SubHunter class file in it) there are two more folders with the same name. These folders, however, are postfixed with the words (androidTest) and (test), respectively. Whenever we add new code files it will always be to the top folder, the one without any prefix, that contains the SubHunter class/file.

Feel free to explore the other folders. We will also be using the res folder in later projects to add sound files and graphics. We will be making brief adjustments to the file in the manifests folder in a moment as well.

The important points to take away from this section is that this is the Project panel and all our code will go in the top com.gamecodeschool.subhunter folder. If you entered a different company domain back in the Starting the first project – Sub Hunter section, then the name of the folders in your Project panel will be different but the exact same principle applies – use the top one.

Let's explore the place where the real action happens – the Editor window.

The Editor window

This is where, as the name suggests, we will edit our code. Typically, we will add multiple code files to the com.gamecodeschool.subhunter folder and add code to them through the editor window. We can have multiple code files ready for editing at once. Have a look at the next image of the code editor as it stands now.

Now, in preparation for the next section, open the manifests folder at the top of the Project panel. You do this by left-clicking on the little triangle to the left of the folder. I have highlighted this in the next image.

Inside the manifests folder, there is a single file, AndroidManifest.xml. Double-click the file and notice that it has been opened in the editor window and that we now have two tabs so that we can quickly switch between AndroidManifest.xml and SubHunter.java. This next image makes this clear.

Also, note that you can now see the .java extension of SubHunter. Now that we know where our code files will go, how to get to them and how to edit them we can move on to the Sub Hunter project.

We want to use every pixel that the player's Android device has to offer so we will make changes to the AndroidManifest.xml file which allows us to make configuration changes.

Make sure the AndroidManifest.xml file is open in the editor window. If you followed along with the previous section it will be already.

In the AndroidManifest.xml file, locate the following line of code:

android:name=".SubHunter">

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 ".SubHunter" 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"

This is a fiddly set of steps and it is the first code we have edited in the book so here I am showing you a bigger range of this file with the code we just added highlighted amongst it.

…
<activity android:name=".SubHunter"
   android:theme="@android:style/Theme.NoTitleBar.Fullscreen"
   android:screenOrientation="landscape"
   >
   <intent-filter>
      <action android:name="android.intent.action.MAIN" />

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

Now our game will use all the screen space the device makes available and the screen has been locked in landscape mode even if the player holds their device in portrait orientation.

Before we explore any of the code and learn our first bit of Java, you might be surprised to learn that we can already run our project. It will just be a blank screen but as we will be running the game as often as possible to check our progress, let's see how to do that now. You have three options:

The first option is the easiest to set up because we did it as part of setting up Android Studio. If you have a powerful PC you will hardly see the difference between the emulator and a real device. However, screen touches are emulated by mouse clicks and proper testing of the player's experience is not possible.

The second option using a real device has a couple more steps but once set up, is as good as option one and the screen touches are for real.

The final option takes a few minutes (at least) to prepare and then you need to manually put the created package onto a real device and install it.

Probably the best way is to use the emulator to quickly test minor increments in your code and then fairly regularly use USB debugging mode on a real device to make sure things are still as expected. Only occasionally will you want to export an actual deployable package.

For these reasons, I will now go through how to run the game using the emulator and USB debugging on a real device.

Running the game on an Android emulator

Follow these simple steps to run the game on the default Android emulator.

1. On the Android Studio menu bar select Tools | Android AVD Manager. AVD stands for Android Virtual Device (an emulator). You will see the following window.

   

2. Notice there is an emulator in the list. In my case, it is Pixel API 25 if you are following this sometime in the future it will probably be a different emulator that was installed by default. It won't matter. Click the green play icon shown in the next image and wait while the emulator boots up.

   

3. Now you can see the emulator as shown in the next image. Note also in the next image I have highlighted one of the icons in the control panel to the right of the emulator. Click that icon to rotate the phone into landscape mode ready to run the game.

   

4. Now you can click the play icon on the Android Studio quick-launch bar as shown in the next image and when prompted choose Pixel API 25 (or whatever your emulator is called) and the game will launch on the emulator.

   

You're done. Here is what the running game looks like so far:

Clearly, we have more work to do but it is a good start. Let's see how to do the same on a real device and then we can go about building Sub' Hunter further.

We have covered a lot of ground in this first chapter. We learned why games, Android and Java are a good and potentially profitable way to learn to program. We discovered how Android and Java work together and had a look at the six games that we will build throughout this book. Finally, we got started on the first game, Sub' Hunter and deployed the blank project to the emulator and a real device.

In the next chapter, we will learn the first set of basics for Java and coding in general as well as scratch the surface of some more advanced Java topics that we will keep coming back to throughout the book. These topics include object-oriented programming, classes, objects, and methods as well as how these topics are intimately related.

We can then make sense of the code that Android Studio generated for us (in SubHunter.java) and start to add our own code.