Before we begin entering the details about making games with the Android SDK, let's first take a step back and consider why are we doing this and what the other alternatives are for making a game that runs on Android.
People tend to reinvent the wheel quite often and developers use to do it ever more, especially in the case of video games. While creating a complete engine from scratch is a great learning experience, it also takes a lot of time. So, if you want to just make a game, it may be more cost-efficient for you to use one of the existing engines instead.
We are in a golden age of tools for creating video games. Not only are there lots of them, but most of them are free as well. This makes choosing the right one a little bit more complicated.
Let's take a look at several questions to help us decide which tool to use to suit the needs of a specific game. Since you are already reading this book, I consider that multiplatform is not high on your list of priorities and that reusing your existing Java and Android knowledge is a plus.
If the answer is yes; I would definitely recommend you to use an already existing engine. There are some well-known tasks you'll need to implement to build even the simplest 3D engine such as loading models, loading and applying textures, handling transformations, and dealing with cameras. On top of this, you'd need to be writing OpenGL. All this is a lot of work.
Writing an OpenGL engine is the very definition of reinventing the wheel. It is fine if what you want is to learn the internals of a 3D engine, but if you go this road you'll spend a few months before you can even start with the game. If you want to go straight into making the game, you'd better start with an existing 3D engine.
The second question on this road is: do you prefer to work with code or are you more comfortable with a complete editor? For code, you can use jPCT-AE and libGDX, while, on the editor side, the most common alternative is Unity.
An affirmative answer to this question should point you straight to an existing engine.
Physics simulation is a very well-known area where there is a lot of documentation, and you should be able to implement your own physics engine. Again, this is a great learning experience, but if you want to go straight into making the game it is much more convenient to use an existing engine that supports physics. The most used physics engine around is Box2D, which is written in C++ and it has been ported to Android using the NDK.
While we are going to talk about collision detection later in the book, physics is out beyond the scope of this book. Anything more complex than two spheres colliding can become quite complex to handle.
Once again, it depends whether you prefer to work with code or if you want a complete editor. To work with code, AndEngine should be your weapon of choice. In the case of an editor, Corona and Unity are among the most popular choices.
Most of the feature-rich environments we are mentioning have their own environment, including a specific IDE. It takes effort to learn them and some of them use a different language (for example Unity has its own environment and uses JavaScript or C#).
On the other hand, the frameworks are simpler. You just have to include them and you'll still be writing an Android game. This is an interesting middle ground, where you still can reuse your Android and Java knowledge and make use of features such as physics or 3D models. In this section, we can mention AndEngine for 2D and physics and jPCT-AE for 3D as good options.
Of course, not everything is awesome. There are some serious disadvantages, most of them already mentioned, such as:
The code is not portable to other platforms (namely iOS).
Performance can be an issue. If the game gets to a certain complexity, you may need to use OpenGL.
It lacks a physics engine; you'd need to write it yourself.
The support for OpenGL is just primitives; you need to build everything (or use a library).