Beginning Android C++ Game Development

Bruce SutherlandBeginning Android C++ Game Development10.1007/978-1-4302-5831-5_1

© Bruce Sutherland 2013

1. An Introduction to Game Development

Bruce Sutherland¹ 

(1)

VIC, Australia

Abstract

Video games have become an important part of our culture in a relatively short period of time. The industry is also developing into a major pillar of many modern economies, with game development tax schemes being introduced into many developed countries. These are coinciding with a period of time where it has never been easier to release a game into the commercial market. For the last two decades, game development teams have required financial backing and a level of expertise to pass stringent tests by platform holders to be allowed access to their development hardware. Today, anyone with a mobile phone or a tablet and a computer, even a laptop, can build a game and have it for sale with a minimum of time and financial backing. This does not mean that every game is successful: it is still essential to have a good understanding of the technical aspects involved in making games and the considerations involved in designing games which people will want to play. Sometimes the best way to develop this knowledge is to begin at the very beginning, so we'll look at some video game history.

Video games have become an important part of our culture in a relatively short period of time. The industry is also developing into a major pillar of many modern economies, with game development tax schemes being introduced into many developed countries. These are coinciding with a period of time where it has never been easier to release a game into the commercial market. For the last two decades, game development teams have required financial backing and a level of expertise to pass stringent tests by platform holders to be allowed access to their development hardware. Today, anyone with a mobile phone or a tablet and a computer, even a laptop, can build a game and have it for sale with a minimum of time and financial backing. This does not mean that every game is successful: it is still essential to have a good understanding of the technical aspects involved in making games and the considerations involved in designing games which people will want to play. Sometimes the best way to develop this knowledge is to begin at the very beginning, so we’ll look at some video game history.

A Brief History of Video Games

One of the first video games is widely acknowledged to be Spacewar!. Spacewar! was created by Stephen Russell at MIT and released in 1962 as a demonstration of the power of the recently released PDP-1 computer system. Games such as Spacewar!, however, did not reach a mass critical appeal.

The era of commercially successful video games arguably began when a student of Russell’s at Stanford, Nolan Bushnell, along with his partner Ted Dabney, formed Atari in 1972. Atari was responsible for releasing massively popular and commercially successful games such as Pong, Asteroids, and Breakout. Atari would remain one of the biggest players in the video game business until the entry of two major competitors.

Nintendo and Sega both entered the video game business in 1983 with the Nintendo Entertainment System and Sega SG-1000 (and later the Master System). These companies would become the major players in the video game business through to the late nineties and would spawn the creation of massive gaming franchises such as Mario, Legend of Zelda, Sonic the Hedgehog, and Sega Rally.

Almost as importantly, Nintendo and Sega would popularize the concept of handheld gaming. Through their platforms such as the Game Boy, Game Gear through to the Nintendo 3DS, and current competition from Sony’s Playstation Vita, Nintendo and Sega proved that there was an appetite for people to play games on the move.

This branch of gaming has been converging with the mobile phone platforms ever since phones begun to have processors and graphics capabilities to run programs which we can recognize as games. Nokia handsets in the late nineties were released with a version of the game Snake, which was very popular. Qualcomm released the BREW (Binary Runtime Environment for Wireless) platform in 2001. Nokia tried to develop a dedicated mobile phone–based gaming platform called NGage and released this in 2003. Both of these platforms showed what a mobile phone platform could eventually be capable of.

The first breakout success in mobile phone gaming came from Apple in 2008, when they released their App Store onto the iPhone 3GS in 2008. This was followed shortly after by Google’s Android Market (currently Google Play), which launched in September 2008. These stores democratized console game development by, for the first time, allowing any company or individual to register as a developer and release games for sale directly to the public. Video game consoles up to this point required a developer to be registered and pay considerable sums to gain access to development versions of the hardware which they were targeting. Now anyone could make apps and games with their home computer and their own mobile phone.

The App Store and Google Play have gone from strength to strength as the hardware in mobile phones has improved rapidly. In the last four years, the mobile platforms have moved from single-core processors with no hardware floating point support to multi-core setups, which are arguably as capable as low-end desktop CPUs. Similarly, the GPUs available have gone from fixed-pipeline OpenGL ES 1.1–capable parts to modern chips with at least OpenGL ES 2.0 support as well as some of the most modern GPUs supporting version 3.0.

Some of those terms still sound daunting for a complete newcomer to the game development scene, and this can create a barrier to entry. Many people can be put off at this point, so it’s important to dispel these feelings and take a look at who can and should make games.

Who Makes Games?

As I touched on in the previous section, with the modern app platforms on mobile phones, the traditional model of well-established companies signing publishing deals with massive game publishing houses is no longer the most common method for releasing video games.

There are currently all manner of developers on these mobile platforms. Some of the biggest remain the traditional companies such as Electronic Arts, who make very popular and successful games. However, there is a growing community of independent developers who are creating meaningful game experiences which are also hitting some very large numbers of downloads and creating substantial revenues. A great example of this is Temple Run. Temple Run is developed by Imangi Studios, a husband-and-wife team who added an extra member to create the art for their game.

I think Jesse Schell put it best in his book, The Art of Game Design, when discussing who can be a games designer. In his very first chapter he addresses how to become a game designer by asking the question:

How do you become a game designer?

His response is:

Design games. Start now! Don’t wait! Don’t even finish this conversation! Just start designing! Go! Now!

By the time you finish this book, you’ll have made a game from scratch and will be ready to move on to developing your own games from your own designs.

It’s also worth noting that games don’t always have to be video games. Many of the most popular games throughout history have been board games, and examples such as chess and Monopoly spring instantly to mind. So what is it that makes video games different?

The Difference between Computer Games and Board Games

Traditional games have been around for thousands of years, yet there is an appeal to modern video games which sets them apart from those games. Traditional games have a formal structure. They usually have a set of rules, an element of randomness, a conflicting goal for players to achieve, and a win condition.

An example would be Monopoly. The goal of the game for each player is to be the last with money remaining. You can reduce the amount of money others have by developing property squares which you own, and the rules of the game dictate how and when you can carry out this development. There is an element of randomness added to the game by way of having dice to roll, which determine which property squares your piece lands on.

Despite the endless variations which can occur when playing a game such as Monopoly, the rules and actions are still fairly limited in scope. These games still rely on the players to remember how to play the game for it to be successful. Video games have an advantage in the sense that the computer can simulate a game without the need for the player to remember the state of the game.

Video games can therefore be much more complicated systems than traditional games. Today’s console and PC games are perfect examples of this complexity. Games such as Microsoft’s Halo 4 have an enormous set of rules which are all executed in real time. Each weapon has different characteristics; there are vehicles and enemies which each have a unique tuning in their AI to represent differing personalities. To many on the surface, it might seem much like many other first-person shooter games, but the interplay among the different game rules is what separates video games from traditional games and also separates the good games from the great ones. Great games almost seamlessly blend complicated rules, AI, and player interaction into a believable world and story.

Now that we’ve looked at the differences between board games and console games, we’ll take a look at what makes games designed for mobile devices different from games designed for a home console.

Comparing Mobile Phones to Game Consoles

This may come as a surprise, but there is actually very little difference between current Android mobile phones and the traditional game platforms such as the Microsoft Xbox 360, the Sony Playstation 3, and Nintendo’s Wii U.

Each system has its own trade-offs and potentially unique controller interfaces, but under the surface each system conforms to a few set standards.

They all have a CPU which executes the game code.

Each has a GPU which renders the game geometry.

Each has a display of varying resolution and aspect ratio.

They all output sound.

They all take user input.

The major differentiating factor from a user’s perspective is the aspect of input. Traditionally, PC games have been played with a keyboard and mouse, console games with a controller, and modern mobile games with a touch screen. This requires that the games be designed differently to best suit the input device of the system being targeted.

From a development perspective, mobile phones are currently weaker than the consoles and much weaker than PCs. Despite supporting modern features such as vertex and fragment shaders, the number of vertices which can be processed and the number of pixels which can be drawn is limited on a phone compared to a PC or console. There are also stricter limits to the memory bandwidth between the phone’s memory and the GPU, making it important to send only relevant information which the GPU can use to render the current frame.

These restrictions can impact a game at the lowest level of its implementation, and game programmers have become adept at designing their technology to accommodate these differences. Many of the challenges will be common to all mobile games, and sharing the advances made from one project will only help to benefit games which follow. To that end, game engines have become a fundamental part of developing games on console and ever more increasingly on mobile platforms also.

An Overview of Game Engines

In the 1980s, it was not uncommon for every individual game to be written from scratch, with very little code reuse between projects. This began to change with the emergence of game engines in the early to mid-1990s. With the advent of 3D accelerators, the complexity of game code was increasing rapidly. It was quickly becoming necessary to understand a large number of topics related to game development, such as audio, physics, AI, and graphics programming. As the complexity increased, so did the sizes of teams necessary to create games and also the money required. It wasn’t long before there was a dual track developing within game development. There were technical teams writing the systems which games run upon and there were the game programming teams developing the games themselves.

From this was born the concept of a game engine. The low-level systems were written in an abstract manner so that games could be developed over the top. A key player in the engine market at this time was Id Software, which licensed its Id Tech engines to other developers. A notable franchise which was born on Id’s game engines was Half-Life, which was created using the Quake engine. Id’s own Quake 3, released in 1999, was their largest release at the time and was developed on their Id Tech 3 engine. This engine was also licensed, and the most notable example was the use of the engine by Infinity Ward to create Call of Duty.

Since then, Unreal has become a massively successful engine licensed by many game teams from the United States, Europe, and Japan to create some of the largest console games of the current generation, and the Unity engine is currently used in a wide range of titles on both Android and iOS.

From an individual perspective, it’s important to realize the core concept of what makes a game engine an attractive prospect, whether it’s through licensing another developer’s technology or writing your own code in an engine-like manner. Using this technique allows you to reuse large sections of code between projects. This reduces the financial cost of developing titles as you move forward and increases your productivity by allowing you to spend more and more time on game features and less time on the engine. In reality, it’s never quite that simple, but it is important to try to separate engine code from game logic code as much and as often as possible. This is something which we will be trying to achieve as we move through this book: from the beginning to the end, we’ll be sure to look at the separation of reusable engine code and game logic which is specific to an individual app.

Summary

That concludes a whirlwind introduction to video game development, from its roots all the way through to the current state of modern development. Each of these topics could be covered in depth in volumes of their own, but the grounding we have established here should stand us in good stead for the rest of this book.

We’re going to walk through the development of a game, from setting up a game project in Eclipse, designing a small game, and implementing a game engine, all the way through to publishing our first title in Google Play.

Let’s get started.

Bruce SutherlandBeginning Android C++ Game Development10.1007/978-1-4302-5831-5_2

© Bruce Sutherland 2013

2. An Introduction to the Android Game Development Ecosystem

Bruce Sutherland¹ 

(1)

VIC, Australia

Abstract

After our brief introduction to the history of video games, we'll look at taking our first steps into defining their future. The Android platform provides us with easier access to cross-platform development tools and 3D graphics hardware than has ever been available before. This makes it an ideal candidate platform for an introduction to game development. All you need is a computer, so let’s get started.

After our brief introduction to the history of video games, we’ll look at taking our first steps into defining their future. The Android platform provides us with easier access to cross-platform development tools and 3D graphics hardware than has ever been available before. This makes it an ideal candidate platform for an introduction to game development. All you need is a computer, so let’s get started.

Java and the Dalvik Virtual Machine

The Java programming language was released in 1995 by Sun Microsystems and is currently maintained by Oracle. The syntax for the language was based on C and was therefore familiar to many programmers who were already well practiced in C and C++. The major differences between C++ and Java are that Java is a managed language and the code is executed on the Java Virtual Machine.

Java was the only language option available for app developers when Android was launched. The Android developers did not use the Java Virtual Machine and wrote their own implementation, which they named Dalvik. Dalvik originally did not have many of the features which were associated with other mature Java Virtual Machines. One particularly notable omission was just-in-time (JIT) compilation. As Java is a managed language which runs in a virtual machine, the code is not compiled directly into native CPU instructions but rather into bytecode which can be consumed by the virtual machine. With JIT, the virtual machine can compile blocks of bytecode into machine code ahead of it being needed by the program and therefore can provide a speed boost to the running program. These compiled units can also be cached for future speed improvements. Android did not have this feature until version 2.2.

Many of the low-level APIs relevant to game programming are also still implemented in C on the Android platform, such as Open GL. Java on Android supports these APIs by using the Java Native Interface (JNI). The JNI provides a mechanism to support the passing of parameters to function calls of native libraries from the Java Virtual Machine and also for the native libraries to return values to the Java Virtual Machine.

This creates suboptimal conditions for game developers. The managed nature of the Java language means that the developer is not responsible for the game’s memory management during its lifetime. While there are many arguments for why this may be a good thing for normal apps, games which require execution in real time cannot afford to hand control of memory allocation and garbage collection exclusively to an external system, which also adds hidden costs to calling certain functions in Java.

A good example of a hidden cost is found when using iterators on collections. As with many other Java objects, iterators are immutable. This means that once you have an iterator, it cannot be changed. When moving from the current iterator to the next position in a collection, Java allocates a new iterator and returns it in the new position to the caller while marking the old iterator for deletion. Eventually, Dalvik will call the garbage collector to free all of the orphaned iterators, and this will cause a noticeable drop in framerate and even cause your game to stall. This leads us to C++ and the NDK.

C++ and the NDK

Google released the Android Native Development Kit (NDK) to provide developers with another option for developing their apps on Android. The first version was released for Android 1.5 but did not contain essential support for SDKs such as OpenGL ES. The Revision 5 release of the NDK is the version which I would consider to be the first viable version of the NDK for game programming. This revision added the ability to support NativeActivity and the native app glue library, which allows developers to write Android apps entirely in C++ without any need for Java. This is possible because this revision of the NDK also added support for audio through OpenGL ES, native audio support, native access to the system’s sensors such as the accelerometers and gyroscope, and also native access to files stores within the app APK package.

There are a number of benefits to being able to write Android apps in C++. Existing developers can add support for the platform to their existing C++ codebases without requiring the expense of maintaining Java code as well as C++ code for the system, and new developers can begin writing apps for Android, which can then be ported to other platforms or developed for multiple platforms simultaneously.

Developing games in C++ doesn’t come without challenges. As C++ is compiled to native code and Android supports multiple CPU instruction sets, it becomes important to ensure that the code written compiles and executes without error and as expected on all of these. Android to date supports the following:

ARM

ARM v7a

MIPS

x86

There are devices on the market which support each of these instruction sets. As Java compiles to bytecode and runs on a virtual machine, this is transparent to the Java developer. The NDK toolset at the time of writing is also not as mature as the Java toolset, and the integration with the Eclipse IDE is a little more complicated and troublesome, especially with regard to code completion, building, and debugging functionality.

Despite the troubles and drawbacks, the performance benefits to developing on Android in C++ still outweigh the downsides to working with the NDK toolsets, and hopefully the maturity and functionality of these tools will only improve over time. Now that you can see the advantages of C++ over Java for game development, it’s important to take a look at some of the issues which are common to both languages in the Android ecosystem. These sets of problems are not entirely new and have been encountered, tackled, and solved for many years in PC development in both the OpenGL and DirectX space; however, these considerations are new to many mobile phone developers. These problems have been grouped together, and the term fragmentation has been coined to encompass them all.

Fragmentation and the Android Ecosystem

There are many opinions and varying definitions of what fragmentation on the Android platform means to different people. I will look at the problem purely from a game development perspective.

Android Versions

The first issue from a development perspective is to choose a version of Android which we would like to target as the minimum. As I discussed in the previous section, many essential features of the NDK were added only with Revision 5. NDK r5 supports Android API level 9 and, at the time of writing, the Android Developers Dashboard shows that 86.6% of Android devices which accessed Google Play in the proceeding 14 days supported this version; 13.4% may be a considerable chunk of the market which you may not be willing to forego from your potential customer base. For ease of development, I have decided that it is acceptable to not support this ever-decreasing percentage of Android versions. So, to be clear, this book will target Android API level 9.

Screen Resolution and Aspect Ratio

The next often discussed aspect of fragmentation is screen resolution and aspect ratio. This is one aspect of the argument which I have never fully understood. Games have been written for the last couple of decades to support multiple resolutions and aspect ratios. This is a common requirement on PC, Xbox 360, and PS3 as