As kids of the eighties and nineties, we naturally grew up with our trusty Nintendo Game Boys and Sega Game Gears. We spent countless hours helping Mario rescue the princess, getting the highest score in Tetris, and racing our friends in Super RC Pro-Am via Link Cable. We took these awesome pieces of hardware with us everywhere we could. Our passion for games made us want to create our own worlds and share them with our friends. We started programming on the PC, but soon realized that we couldn’t transfer our little masterpieces to the available portable game consoles. As we continued being enthusiastic programmers, over time our interest in actually playing video games faded. Besides, our Game Boys eventually broke . . .
Fast forward to today. Smartphones and tablets have become the new mobile gaming platforms of this era, competing with classic, dedicated handheld systems such as the Nintendo 3DS and the PlayStation Vita. This development renewed our interest, and we started investigating which mobile platforms would be suitable for our development needs. Apple’s iOS seemed like a good candidate for our game coding skills. However, we quickly realized that the system was not open, that we’d be able to share our work with others only if Apple allowed it, and that we’d need a Mac in order to develop for the iOS. And then we found Android.
We both immediately fell in love with Android. Its development environment works on all the major platforms—no strings attached. It has a vibrant developer community, happy to help you with any problem you encounter, as well as offering comprehensive documentation. You can share your games with anyone without having to pay a fee to do so, and if you want to monetize your work, you can easily publish your latest and greatest innovation to a global market with millions of users in a matter of minutes.
The only thing left was to figure out how to write games for Android, and how to transfer our PC game development knowledge to this new system. In the following chapters, we want to share our experience with you and get you started with Android game development. Of course, this is partly a selfish plan: we want to have more games to play on the go!
Let’s start by getting to know our new friend, Android.
Android was first seen publicly in 2005, when Google acquired a small startup called Android Inc. This fueled speculation that Google was interested in entering the mobile device space. In 2008, the release of version 1.0 of Android put an end to all speculation, and Android went on to become the new challenger on the mobile market. Since then, Android has been battling it out with already-established platforms, such as iOS (then called iPhone OS), BlackBerry OS, and Windows Phone 7. Android’s growth has been phenomenal, as it has captured more and more market share every year. While the future of mobile technology is always changing, one thing is certain: Android is here to stay.
Because Android is open source, there is a low barrier of entry for handset manufacturers using the new platform. They can produce devices for all price segments, modifying Android itself to accommodate the processing power of a specific device. Android is therefore not limited to high-end devices, but can also be deployed in low-cost devices, thus reaching a wider audience.
A crucial ingredient for Android’s success was the formation of the Open Handset Alliance (OHA) in late 2007. The OHA includes companies such as HTC, Qualcomm, Motorola, and NVIDIA, which all collaborate to develop open standards for mobile devices. Although Android’s code is developed primarily by Google, all the OHA members contribute to its source code in one form or another.
Android itself is a mobile operating system and platform based on the Linux kernel versions 2.6 and 3.x, and it is freely available for commercial and noncommercial use. Many members of the OHA build custom versions of Android with modified user interfaces (UIs) for their devices, such as HTC’s Sense and Motorola’s MOTOBLUR. The open source nature of Android also enables hobbyists to create and distribute their own versions. These are usually called mods, firmware, or roms. The most prominent rom at the time of this writing is developed by Steve Kondik, also known as Cyanogen, and many contributors. It aims to bring the newest and best improvements to all sorts of Android devices and breathe fresh air into otherwise abandoned or old devices.
Since its release in 2008, Android has received many major version updates, all code-named after desserts (with the exception of Android 1.1, which is irrelevant nowadays). Most versions of the Android platform have added new functionality, usually in the form of application programming interfaces (APIs) or new development tools, that is relevant, in one way or another, for game developers:
- Version 1.5 (Cupcake): Added support for including native libraries in Android applications, which were previously restricted to being written in pure Java. Native code can be very beneficial in situations where performance is of utmost concern.
- Version 1.6 (Donut): Introduced support for different screen resolutions. We will revisit that development a couple of times in this book because it has some impact on how we approach writing games for Android.
- Version 2.0 (Éclair): Added support for multitouch screens.
- Version 2.2 (Froyo): Added just-in-time (JIT) compilation to the Dalvik virtual machine (VM), the software that powers all the Java applications on Android. JIT speeds up the execution of Android applications considerably—depending on the scenario, up to a factor of five.
- Version 2.3 (Gingerbread): Added a new concurrent garbage collector to the Dalvik VM.
- Version 3.0 (Honeycomb): Created a tablet version of Android. Introduced in early 2011, Honeycomb contained more significant API changes than any other single Android version released to date. By version 3.1, Honeycomb added extensive support for splitting up and managing a large, high-resolution tablet screen. It added more PC-like features, such as USB host support and support for USB peripherals, including keyboards, mice, and joysticks. The only problem with this release was that it was only targeted at tablets. The small-screen/smartphone version of Android was stuck with 2.3.
- Android 4.0 (Ice Cream Sandwich [ICS]): Merged Honeycomb (3.1) and Gingerbread (2.3) into a common set of features that works well on both tablets and phones.
- Android 4.1 (Jelly Bean): Improved the way the UI is composited, and rendering in general. The effort is known as “Project Butter”; the first device to feature Jelly Bean was Google’s own Nexus 7 tablet.
ICS is a huge boost for end users, adding a number of improvements to the Android UI and built-in applications such as the browser, email clients, and photo services. Among other things for developers, ICS merges in Honeycomb UI APIs that bring large-screen features to phones. ICS also merges in Honeycomb’s USB periphery support, which gives manufacturers the option of supporting keyboards and joysticks. As for new APIs, ICS adds a few, such as the Social API, which provides a unified store for contacts, profile data, status updates, and photos. Fortunately for Android game developers, ICS at its core maintains good backward compatibility, ensuring that a properly constructed game will remain well compatible with older versions like Cupcake and Eclair.
Note We are both often asked which new features new versions of Android bring to the table for games. The answer often surprises people: effectively no new game-specific features outside of the native development kit (NDK) have been added to Android since version 2.1. Since that version, Android has included everything you need to build just about any kind of game you want. Most new features are added to the UI API, so just focus on 2.1 and you’ll be good to go.
The great flexibility of Android comes at a price: companies that opt to develop their own UIs have to play catch-up with the fast pace at which new versions of Android are released. This can lead to handsets no more than a few months old becoming outdated, as carriers and handset manufacturers refuse to create updates that incorporate the improvements of new Android versions. A result of this process is the big bogeyman called fragmentation.
Fragmentation has many faces. To the end user, it means being unable to install and use certain applications and features due to being stuck with an old Android version. For developers, it means that some care has to be taken when creating applications that are meant to work on all versions of Android. While applications written for earlier versions of Android usually run fine on newer ones, the reverse is not true. Some features added to newer Android versions are, of course, not available on older versions, such as multitouch support. Developers are thus forced to create separate code paths for different versions of Android.
In 2011, many prominent Android device manufacturers agreed to support the latest Android OS for a device lifetime of 18 months. This may not seem like a long time, but it’s a big step in helping to cut down on fragmentation. It also means that new features of Android, such as the new APIs in Ice Cream Sandwich, become available on more phones, much faster. A year later, this promise hasn’t been kept, it seems. A significant portion of the market is still running older Android versions, mostly Gingerbread. If the developers of a game want mass-market acceptance, the game will need to run on no fewer than six different versions of Android, spread across 600+ devices (and counting!).
But fear not. Although this sounds terrifying, it turns out that the measures that have to be taken to accommodate multiple versions of Android are minimal. Most often, you can even forget about the issue and pretend there’s only a single version of Android. As game developers, we’re less concerned with differences in APIs and more concerned with hardware capabilities. This is a different form of fragmentation, which is also a problem for platforms such as iOS, albeit not as pronounced. Throughout this book, we will cover the relevant fragmentation issues that might get in your way while you’re developing your next game for Android.
Although Android is officially the brainchild of the Open Handset Alliance, Google is the clear leader when it comes to implementing Android itself, as well as providing the necessary ecosystem for it to grow.
The Android Open Source Project
Google’s efforts are summarized in the Android Open Source Project. Most of the code is licensed under Apache License 2, which is very open and nonrestrictive compared to other open source licenses, such as the GNU General Public License (GPL). Everyone is free to use this source code to build their own systems. However, systems that are proclaimed Android compatible first have to pass the Android Compatibility Program, a process that ensures baseline compatibility with third-party applications written by developers. Compatible systems are allowed to participate in the Android ecosystem, which also includes Google Play.
Google Play (formerly known as Android Market) was opened to the public by Google in October 2008. It’s an online store that enables users to purchase music, videos, books and third-party applications, or apps, to be consumed on their device. Google Play is primarily available on Android devices, but also has a web front end where users can search, rate, download, and install apps. It isn’t required, but the majority of Android devices have the Google Play app installed by default.
Google Play allows third-party developers to publish their programs either for free or as paid applications. Paid applications are available for purchase in many countries, and the integrated purchasing system handles exchange rates using Google Checkout. Google Play also gives the option to price an app manually on a per-country basis.
A user gets access to the store after setting up a Google account. Applications can be purchased via credit card through Google Checkout or by using carrier billing. Buyers can decide to return an application within 15 minutes of the time of purchase for a full refund. Previously, the refund window was 24 hours, but it was shortened to curtail exploitation of the system.
Developers need to register an Android developer account with Google, for a one-time fee of $25, in order to be able to publish applications on the store. After successful registration, a developer can start publishing new applications in a matter of minutes.
Google Play has no approval process, instead relying on a permission system. Before installing an application, the user is presented with a set of required permissions, which handle access to phone services, networking, Secure Digital (SD) cards, and so on. A user may opt not to install an application because of permissions, but a user doesn’t currently have the ability to simply not allow an application to have a particular permission. It is “take it or leave it” as a whole. This approach aims to keep apps honest about what they will do with the device, while giving users the information they need to decide which apps to trust.
In order to sell applications, a developer additionally has to register a Google Checkout merchant account, which is free of charge. All financial transactions are handled through this account. Google also has an in-app purchase system, which is integrated with the Android Market and Google Checkout. A separate API is available for developers to process in-app purchase transactions.
The annual Google I/O conference is an event that every Android developer looks forward to each year. At Google I/O, the latest and greatest Google technologies and projects are revealed, among which Android has gained a special place in recent years. Google I/O usually features multiple sessions on Android-related topics, which are also available as videos on YouTube’s Google Developers channel. At Google I/O 2011, Samsung and Google handed out Galaxy Tab 10.1 devices to all regular attendees. This really marked the start of the big push by Google to gain market share on the tablet side.
Android’s Features and Architecture
Android is not just another Linux distribution for mobile devices. While developing for Android, you’re not all that likely to meet the Linux kernel itself. The developer-facing side of Android is a platform that abstracts away the underlying Linux kernel and is programmed via Java. From a high-level view, Android possesses several nice features:
- An application framework that provides a rich set of APIs for creating various types of applications. It also allows the reuse and replacement of components provided by the platform and third-party applications.
- The Dalvik virtual machine, which is responsible for running applications on Android.
- A set of graphics libraries for 2D and 3D programming.
- Media support for common audio, video, and image formats, such as Ogg Vorbis, MP3, MPEG-4, H.264, and PNG. There’s even a specialized API for playing back sound effects, which will come in handy in your game development adventures.
- APIs for accessing peripherals such as the camera, Global Positioning System (GPS), compass, accelerometer, touchscreen, trackball, keyboard, controller, and joystick. Note that not all Android devices have all these peripherals—hardware fragmentation in action.
Of course, there’s a lot more to Android than the few features just mentioned. But, for your game development needs, these features are the most relevant.
Android’s architecture is composed of stacked groups of components, and each layer builds on the components in the layer below it. Figure 1-1 gives an overview of Android’s major components.
Figure 1-1. Android architecture overview
Starting at the bottom of the stack, you can see that the Linux kernel provides the basic drivers for the hardware components. Additionally, the kernel is responsible for such mundane things as memory and process management, networking, and so on.
The Android runtime is built on top of the kernel, and it is responsible for spawning and running Android applications. Each Android application is run in its own process with its own Dalvik VM.
Dalvik runs programs in the Dalvik Executable (DEX) bytecode format. Usually, you transform common Java .class files into DEX format using a special tool called dx, which is provided by the software development kit (SDK). The DEX format is designed to have a smaller memory footprint compared to classic Java .class files. This is achieved through heavy compression, tables, and merging of multiple .class files.
The Dalvik VM interfaces with the core libraries, which provide the basic functionality that is exposed to Java programs. The core libraries provide some, but not all, of the classes available in Java Standard Edition (SE) through the use of a subset of the Apache Harmony Java implementation. This also means that there’s no Swing or Abstract Window Toolkit (AWT) available, nor any classes that can be found in Java Micro Edition (ME). However, with some care, you can still use many of the third-party libraries available for Java SE on Dalvik.
Before Android 2.2 (Froyo), all bytecode was interpreted. Froyo introduced a tracing JIT compiler, which compiles parts of the bytecode to machine code on the fly. This considerably increases the performance of computationally intensive applications. The JIT compiler can use CPU features specifically tailored for special computations, such as a dedicated Floating Point Unit (FPU). Nearly every new version of Android improves upon the JIT compiler and enhances performance, usually at the cost of memory consumption. This is a scalable solution, though, as new devices contain more and more RAM as standard fare.
Dalvik also has an integrated garbage collector (GC), which, in earlier versions, has had the tendency to drive developers a little crazy at times. With some attention to detail, though, you can peacefully coexist with the GC in your day-to-day game development. Starting from Android 2.3, Dalvik employs an improved concurrent GC, which relieves some of the pain. You’ll get to investigate GC issues in more detail later in the book.
Each application running in an instance of the Dalvik VM has a total of at least 16 MB of heap memory available. Newer devices, specifically tablets, have much higher heap limits to facilitate higher-resolution graphics. Still, with games it is easy to use up all of that memory, so you have to keep that in mind as you juggle your image and audio resources.
Besides the core libraries, which provide some Java SE functionality, there’s also a set of native C/C++ libraries (second layer in Figure 1-1), which build the basis for the application framework (third layer in Figure 1-1). These system libraries are mostly responsible for the computationally heavy tasks that would not be as well suited to the Dalvik VM, such as graphics rendering, audio playback, and database access. The APIs are wrapped by Java classes in the application framework, which you’ll exploit when you start writing your games. You’ll use the following libraries in one form or another:
- Skia Graphics Library (Skia): This 2D graphics software is used for rendering the UI of Android applications. You’ll use it to draw your first 2D game.
- OpenGL for Embedded Systems (OpenGL ES): This is the industry standard for hardware-accelerated graphics rendering. OpenGL ES 1.0 and 1.1 are exposed to Java on all versions of Android. OpenGL ES 2.0, which brings shaders to the table, is only supported from Android 2.2 (Froyo) onward. It should be mentioned that the Java bindings for OpenGL ES 2.0 in Froyo are incomplete and lack a few vital methods. Fortunately, these methods were added in version 2.3. Also, many older emulator images and devices, which still make up a small share of the market, do not support OpenGL ES 2.0. For your purposes, stick with OpenGL ES 1.0 and 1.1, to maximize compatibility and allow you to ease into the world of Android 3D programming.
- OpenCore: This is a media playback and recording library for audio and video. It supports a good mix of formats such as Ogg Vorbis, MP3, H.264, MPEG-4, and so on. You’ll mostly deal with the audio portion, which is not directly exposed to the Java side, but rather wrapped in a couple of classes and services.
- FreeType: This is a library used to load and render bitmap and vector fonts, most notably the TrueType format. FreeType supports the Unicode standard, including right-to-left glyph rendering for Arabic and similar special text. As with OpenCore, FreeType is not directly exposed to the Java side, but is wrapped in a couple of convenient classes.
These system libraries cover a lot of ground for game developers and perform most of the heavy lifting. They are the reason why you can write your games in plain old Java.
Note Although the capabilities of Dalvik are usually more than sufficient for your purposes, at times you might need more performance. This can be the case for very complex physics simulations or heavy 3D calculations, for which you would usually resort to writing native code. We’ll look into this in a later chapter of the book. A couple of open source libraries for Android already exist that can help you stay on the Java side of things. See http://code.google.com/p/libgdx/ for an example.
The application framework ties together the system libraries and the runtime, creating the user side of Android. The framework manages applications and provides an elaborate structure within which applications operate. Developers create applications for this framework via a set of Java APIs that cover such areas as UI programming, background services, notifications, resource management, peripheral access, and so on. All out-of-the-box core applications provided by Android, such as the mail client, are written with these APIs.
Applications, whether they are UIs or background services, can communicate their capabilities to other applications. This communication enables an application to reuse components of other applications. A simple example is an application that needs to take a photo and then perform some operations on it. The application queries the system for a component of another application that provides this service. The first application can then reuse the component (for example, a built-in camera application or photo gallery). This significantly lowers the burden on programmers and also enables you to customize myriad aspects of Android’s behavior.
As a game developer, you will create UI applications within this framework. As such, you will be interested in an application’s architecture and life cycle, as well as its interactions with the user. Background services usually play a small role in game development, which is why they will not be discussed in detail.
To develop applications for Android, you will use the Android software development kit (SDK). The SDK is composed of a comprehensive set of tools, documentation, tutorials, and samples that will help you get started in no time. Also included are the Java libraries needed to create applications for Android. These contain the APIs of the application framework. All major desktop operating systems are supported as development environments.
Prominent features of the SDK are as follows:
- The debugger, capable of debugging applications running on a device or in the emulator.
- A memory and performance profile to help you find memory leaks and identify slow code.
- The device emulator, accurate though a bit slow at times, is based on QEMU (an open source virtual machine for simulating different hardware platforms). There are some options available to accelerate the emulator, such as Intel Hardware Accelerated Execution Manager (HAXM), which we discuss in Chapter 2.
- Command-line utilities to communicate with devices.
- Build scripts and tools to package and deploy applications.
The SDK can be integrated with Eclipse, a popular and feature-rich open source Java integrated development environment (IDE). The integration is achieved through the Android Development Tools (ADT) plug-in, which adds a set of new capabilities to Eclipse for the following purposes: to create Android projects; to execute, profile, and debug applications in the emulator or on a device; and to package Android applications for their deployment to Google Play. Note that the SDK can also be integrated into other IDEs, such as NetBeans. There is, however, no official support for this.
Note Chapter 2 covers how to set up the IDE with the SDK and Eclipse.
The SDK and the ADT plug-in for Eclipse receive constant updates that add new features and capabilities. It’s therefore a good idea to keep them updated.
Along with any good SDK comes extensive documentation. Android’s SDK does not fall short in this area, and it includes a lot of sample applications. You can also find a developer guide and a full API reference for all the modules of the application framework at http://developer.android.com/guide/index.html.
In addition to the Android SDK, game developers using OpenGL may want to install and use the various profilers by Qualcomm, PowerVR, Intel, and NVIDIA. These profilers give significantly more data about the demands of the game on a device than anything in the Android SDK. We’ll discuss these profilers in greater detail in Chapter 2.
Part of the success of Android is its developer community, which gathers in various places around the Web. The most frequented site for developer exchange is the Android Developers group at http://groups.google.com/group/android-developers. This is the number one place to ask questions or seek help when you stumble across a seemingly unsolvable problem. The group is visited by all sorts of Android developers, from system programmers, to application developers, to game programmers. Occasionally, the Google engineers responsible for parts of Android also help out by offering valuable insights. Registration is free, and we highly recommend that you join this group now! Apart from providing a place for you to ask questions, it’s also a great place to search for previously answered questions and solutions to problems. So, before asking a question, check whether it has been answered already.
Another source for information and help is Stack Overflow at http://www.stackoverflow.com. You can search by keywords or browse the latest Android questions by tag.
Every developer community worth its salt has a mascot. Linux has Tux the penguin, GNU has its . . . well, gnu, and Mozilla Firefox has its trendy Web 2.0 fox. Android is no different, and has selected a little green robot as its mascot. Figure 1-2 shows you that little devil.
Figure 1-2. Android Robot
The Android Robot has already starred in a few popular Android games. Its most notable appearance was in Replica Island, a free, open source platform created by former Google developer advocate Chris Pruett as a 20 percent project. (The term 20 percent project stands for the one day a week that Google employees get to spend on a project of their own choosing.)
Android is not locked into a single hardware ecosystem. Many prominent handset manufacturers, such as HTC, Motorola, Samsung, and LG, have jumped onto the Android bandwagon, and they offer a wide range of devices running Android. In addition to handsets, there are a slew of available tablet devices that build upon Android. Some key concepts are shared by all devices, though, which will make your life as game developer a little easier.
Google originally issued the following minimum hardware specifications. Virtually all available Android devices fulfill, and often significantly surpass, these recommendations:
- 128 MB RAM: This specification is a minimum. Current high-end devices already include 1 GB RAM and, if Moore’s law has its way, the upward trend won’t end any time soon.
- 256 MB flash memory: This is the minimum amount of memory required for storing the system image and applications. For a long time, lack of sufficient memory was the biggest gripe among Android users, as third-party applications could only be installed to flash memory. This changed with the release of Froyo.
- Mini or Micro SD card storage: Most devices come with a few gigabytes of SD card storage, which can be replaced with higher-capacity SD cards by the user. Some devices, such as the Samsung Galaxy Nexus, have eliminated extensible SD card slots and have only integrated flash memory.
- 16-bit color Quarter Video Graphics Array (QVGA) thin-film transistor liquid crystal display (TFT-LCD): Before Android version 1.6, only Half-size VGA (HVGA) screens (480 × 320 pixels) were supported by the operating system. Since version 1.6, lower- and higher-resolution screens have been supported. The current high-end handsets have Wide VGA (WVGA) screens (800 × 480, 848 × 480, or 852 × 480 pixels), and some low-end devices support QVGA screens (320 × 280 pixels). Tablet screens come in various sizes, typically about 1280 × 800 pixels, and Google TV brings support for HDTV’s 1920 × 1080 resolution! While many developers like to think that every device has a touchscreen, that is not the case. Android is pushing its way into set-top boxes and PC-like devices with traditional monitors. Neither of these device types has the same touchscreen input as a phone or tablet.
- Dedicated hardware keys: These keys are used for navigation. Devices will always provide buttons, either as softkeys or as hardware buttons, specifically mapped to standard navigation commands, such as home and back, usually set apart from onscreen touch commands. With Android the hardware range is huge, so make no assumptions!
Of course, most Android devices come with a lot more hardware than is required for the minimum specifications. Almost all handsets have GPS, an accelerometer, and a compass. Many also feature proximity and light sensors. These peripherals offer game developers new ways to let the user interact with games; we’ll make use of a few of these later in the book. A few devices even have a full QWERTY keyboard and a trackball. The latter is most often found in HTC devices. Cameras are also available on almost all current portable devices. Some handsets and tablets have two cameras: one on the back and one on the front, for video chat.
Dedicated graphics processing units (GPUs) are especially crucial for game development. The earliest handset to run Android already had an OpenGL ES 1.0–compliant GPU. Newer portable devices have GPUs comparable in performance to the older Xbox or PlayStation 2, supporting OpenGL ES 2.0. If no graphics processor is available, the platform provides a fallback in the form of a software renderer called PixelFlinger. Many low-budget handsets rely on the software renderer, which is fast enough for most low-resolution screens.
Along with the graphics processor, any currently available Android device also has dedicated audio hardware. Many hardware platforms include special circuitry to decode different media formats, such as H.264. Connectivity is provided via hardware components for mobile telephony, Wi-Fi, and Bluetooth. All the hardware modules in an Android device are usually integrated in a single system on chip (SoC), a system design also found in embedded hardware.
The Range of Devices
In the beginning, there was the G1. Developers eagerly awaited more devices, and several phones, with minute differences, soon followed, and these were considered “first generation.” Over the years, hardware has become more and more powerful, and now there are phones, tablets, and set-top boxes ranging from devices with 2.5" QVGA screens, running only a software renderer on a 500 MHz ARM CPU, all the way up to machines with dual 1 GHz CPUs, with very powerful GPUs that can support HDTV.
We’ve already discussed fragmentation issues, but developers will also need to cope with this vast range of screen sizes, capabilities, and performance. The best way to do that is to understand the minimum hardware and make it the lowest common denominator for game design and performance testing.
As of mid 2012, less than 3% of all Android devices are running a version of Android older than 2.1. This is important because it means that the game you start now will only have to support a minimum API level of 7 (2.1), and it will still reach 97% of all Android devices (by version) by the time it’s completed. This isn’t to say that you can’t use the latest new features! You certainly can, and we’ll show you how. You’ll simply need to design your game with some fallback mechanisms to bring compatibility down to version 2.1. Current data is available via Google at http://developer.android.com/resources/dashboard/platform-versions.html, and a chart collected in August 2012 is shown in Figure 1-3.
Figure 1-3. Android version distributions on August 1, 2012
So, what’s a good baseline device to use as a minimum target? Go back to the first Android 2.1 device released: the original Motorola Droid, shown in Figure 1-4. While it has since been updated to Android 2.2, the Droid is still a widely used device that is reasonably capable in terms of both CPU and GPU performance.
Figure 1-4. Motorola Droid
The original Droid was coined the first “second generation” device, and it was released about a year after the first set of Qualcomm MSM7201A-based models, which included the G1, Hero, MyTouch, Eris, and many others. The Droid was the first phone to have a screen with a higher resolution than 480 × 320 and a discrete PowerVR GPU, and it was the first natively multitouch Android device (though it had a few multitouch issues, but more on that later).
Supporting the Droid means you’re supporting devices that have the following set of specifications:
- A CPU speed between 550 MHz and 1 GHz with hardware floating-point support
- A programmable GPU supporting OpenGL ES 1.x and 2.0
- A WVGA screen
- Multitouch support
- Android version 2.1 or 2.2+
The Droid is an excellent minimum target because it runs Android 2.2 and supports OpenGL ES 2.0. It also has a screen resolution similar to most phone-based handsets at 854 × 480. If a game works well on a Droid, it’s likely to work well on 90 % of all Android handsets. There are still going to be some old, and even some newer, devices that have a screen size of 480 × 320, so it’s good to plan for it and at least test on them, but performance-wise, you’re unlikely to need to support much less than the Droid to capture the vast majority of the Android audience.
The Droid is also an excellent test device to simulate the capabilities of many of the cheaper Chinese handsets that flood the Asian markets, and also reach some Western markets due to their low price point.
Honeycomb introduced very solid tablet support, and it’s become apparent that tablets are a choice gaming platform. With the introduction of the NVIDIA Tegra 2 chip in early 2011 devices, both handsets and tablets started to receive fast, dual-core CPUs, and even more powerful GPUs have become the norm. It’s difficult, when writing a book, to discuss what’s modern because it changes so quickly, but at the time of this writing, it’s becoming very common for devices to have ultra-fast processors all around, tons of storage, lots of RAM, high-resolution screens, ten-point multitouch support, and even 3D stereoscopic display in a few models.
The most common GPUs in Android devices are the PowerVR series, by Imagination Technologies, Snapdragon with integrated Adreno GPUs, by Qualcomm, the Tegra series, by NVIDIA, and the Mali line built into many Samsung chips. The PowerVR currently comes in a few flavors: 530, 535, 540, and 543. Don’t be fooled by the small increments between model numbers; the 540 is an absolutely blazing-fast GPU compared to its predecessors, and it’s shipped in the Samsung Galaxy S series, as well as the Google Galaxy Nexus. The 543 is currently equipped in the newest iPad and PlayStation Vita and is several times faster than the 540! While it isn’t currently installed in any major Android devices, we have to assume that the 543 will arrive in new tablets soon. The older 530 is in the Droid, and the 535 is scattered across a few models. Perhaps the most commonly used GPU is Qualcomm’s, found in nearly every HTC device. The Tegra GPU is aimed at tablets, but it is also in several handsets. The Mali GPU is being used by many of the newer handsets by Samsung, replacing the formerly used PowerVR chips. All four of these competing chip architectures are very comparable and very capable.
Samsung’s Galaxy Tab 2 10.1 (see Figure 1-5) is a good representative of the latest Android tablet offerings. It sports the following features:
Figure 1-5. Samsung Galaxy Tab 2 10.1
- Dual-core 1 GHz CPU/GPU
- A programmable GPU supporting OpenGL ES 1.x and 2.0
- A 1280 × 800 pixel screen
- Ten-point multitouch support
- Android Ice Cream Sandwich 4.0
Supporting Galaxy Tab 2 10.1–class tablets is very important to sustain the growing number of users embracing this technology. Technically, supporting it is no different from supporting any other device. A tablet-sized screen is another aspect that may require a little extra consideration during the design phase, but you’ll find out more about that later in the book.
Device manufacturers try to keep their latest handsets a secret for as long as possible, but some of the specifications always get leaked.
General trends for all future devices are toward more cores, more RAM, better GPUs, and higher screen resolutions and pixels per inch. Competing chips are constantly coming out, boasting bigger numbers all the time, while Android itself grows and matures, both by improving performance and by gaining features in almost every subsequent release. The hardware market has been extremely competitive, and it doesn’t show any signs of slowing down.
While Android started on a single phone, it has quickly evolved to work well on different types of devices, including e-book readers, set-top boxes, tablets, navigation systems, and hybrid handsets that plug into docks to become PCs. To create an Android game that works everywhere, developers need to take into account the very nature of Android; that is, a ubiquitous OS that can run embedded on almost anything. One shouldn’t assume that Android will simply stay on the current types of devices. Its growth has been so great since 2008, and its reach so vast, that, for Android, it is clear that the sky’s the limit.
Whatever the future brings, Android is here to stay!
Compatibility Across All Devices
After all of this discussion about phones, tablets, chipsets, peripherals, and so forth, it should be obvious that supporting the Android device market is not unlike supporting a PC market. Screen sizes range from a tiny 320 × 240 pixels all the way up to 1920 × 1080 (and potentially higher on PC monitors!). On the lowest-end, first-gen device, you’ve got a paltry 500 MHz ARM5 CPU and a very limited GPU without much memory. On the other end, you’ve got a high-bandwidth, multicore 1–2 GHz CPU with a massively parallelized GPU and tons of memory. First-gen handsets have an uncertain multitouch system that can’t detect discrete touch points. New tablets can support ten discrete touch points. Set-top boxes don’t support any touching at all! What’s a developer to do?
First of all, there is some sanity in all of this. Android itself has a compatibility program that dictates minimum specifications and ranges of values for various parts of an Android-compatible device. If a device fails to meet the standards, it is not allowed to bundle the Google Play app. Phew, that’s a relief! The compatibility program is available at http://source.android.com/compatibility/overview.html.
The Android compatibility program is outlined in a document called the Compatibility Definition Document (CDD), which is available on the compatibility program site. This document is updated for each release of the Android platform, and hardware manufacturers must update and retest their devices to stay compliant.
A few of the items that the CDD dictates as relevant to game developers are as follows:
- Minimum audio latency (varies)
- Minimum screen size (currently 2.5 inches)
- Minimum screen density (currently 100 dpi)
- Acceptable aspect ratios (currently 4:3 to 16:9)
- 3D Graphics Acceleration (OpenGL ES 1.0 is required)
- Input devices
Even if you can’t make sense of some of the items listed above, fear not. You’ll get to take a look at many of these topics in greater detail later in the book. The takeaway from this list is that there is a way to design a game so that it will work on the vast majority of Android devices. By planning things such as the user interface and the general views in the game so that they work on the different screen sizes and aspect ratios, and by understanding that you want not only touch capability but also keyboard or additional input methods, you can successfully develop a very compatible game. Different games call for different techniques to achieve good user experiences on varying hardware, so unfortunately there is no silver bullet for solving these issues. But, rest assured: with time and a little proper planning, you’ll be able to get good results.
Gaming was a huge market segment long before the likes of iPhone and Android appeared on the scene. However, with these new forms of hybrid devices, the landscape has started to change. Gaming is no longer something just for nerdy kids. Serious business people have been seen playing the latest trendy game on their mobile phones in public, newspapers pick up stories of successful small game developers making a fortune on mobile phone application markets, and established game publishers have a hard time keeping up with the developments in the mobile space. Game developers must recognize this change and adjust accordingly. Let’s see what this new ecosystem has to offer.
A Gaming Machine in Every Pocket
Mobile devices are everywhere. That’s probably the key statement to take away from this section. From this, you can easily derive all the other facts about mobile gaming.
As hardware prices are constantly dropping and new devices have ever-increasing computational power, they also become ideal for gaming. Mobile phones are a must-have nowadays, so market penetration is huge. Many people are exchanging their old, classic mobile phones for newer-generation smartphones and discovering the new options available to them in the form of an incredibly wide range of applications.
Previously, if you wanted to play video games, you had to make the conscious decision to buy a video game system or a gaming PC. Now you get that functionality for free on mobile phones, tablets, and other devices. There’s no additional cost involved (at least if you don’t count the data plan you’ll likely need), and your new gaming device is available to you at any time. Just grab it from your pocket or purse and you are ready to go—no need to carry a separate, dedicated system with you, because everything’s integrated in one package.
Apart from the benefit of only having to carry a single device for your telephone, Internet, and gaming needs, another factor makes gaming on mobile phones easily accessible to a much larger audience: you can fire up a dedicated market application on your device, pick a game that looks interesting, and immediately start to play. There’s no need to go to a store or download something via your PC, only to find out, for example, that you don’t have the USB cable you need to transfer that game to your phone.
The increased processing power of current-generation devices also has an impact on what’s possible for you as a game developer. Even the middle class of devices is capable of generating gaming experiences similar to titles found on the older Xbox and PlayStation 2 systems. Given these capable hardware platforms, you can also start to explore elaborate games with physics simulations, an area offering great potential for innovation.
With new devices come new input methods, which have already been touched upon. A couple of games already take advantage of the GPS and/or compass available in most Android devices. The use of the accelerometer is already a mandatory feature of many games, and multitouch screens offer new ways for the user to interact with the game world. A lot of ground has been covered already, but there are still new ways to use all of this functionality in an innovative way.
Android devices are usually sold with data plans. This is driving an increasing amount of traffic on the Web. A smartphone user is very likely to be connected to the Web at any given time (disregarding poor reception caused by hardware design failures).
Permanent connectivity opens up a completely new world for mobile gaming. A user can challenge an opponent on the other side of the planet to a quick game of chess, explore virtual worlds populated with real people, or try fragging a best friend from another city in a gentlemen’s death match. Moreover, all of this occurs on the go—on the bus, on the train, or in a most beloved corner of the local park.
Apart from multiplayer functionality, social networks have also started to influence mobile gaming. Games provide functionality to automatically tweet your latest high score directly to your Twitter account, or to inform a friend of the latest achievement you earned in that racing game you both love. Although growing social networks exist in the classical gaming world (for example, Xbox Live or PlayStation Network), the market penetration of services such as Facebook and Twitter is a lot higher, so the user is relieved of the burden of managing multiple networks at once.
The overwhelming user adoption of mobile devices also means that people who have never even touched a NES controller have suddenly discovered the world of gaming. Their idea of a good game often deviates quite a bit from that of the hardcore gamer.
According to the use cases for mobile phones, typical users tend to lean toward the more casual sort of game that they can fire up for a couple of minutes while on the bus or waiting in line at a fast food restaurant. These games are the equivalent of those addictive little flash games on the PC that force many people in the workplace to Alt + Tab frantically every time they sense the presence of someone behind them. Ask yourself this: How much time each day would you be willing to spend playing games on your mobile phone? Can you imagine playing a “quick” game of Civilization on such a device?
Sure, there are probably serious gamers who would offer up their firstborn child if they could play their beloved Advanced Dungeons & Dragons variant on a mobile phone. But this group is a small minority, as evidenced by the top-selling games in the iPhone App Store and Google Play. The top-selling games are usually extremely casual in nature, but they have a neat trick up their sleeves: the average time it takes to play a round is in the range of minutes, but the games keep you coming back by employing various evil schemes. One game might provide an elaborate online achievement system that lets you virtually brag about your skills. Another could actually be a hardcore game in disguise. Offer users an easy way to save their progress and you are selling an epic RPG as a cute puzzle game!
The low entry barrier to the mobile games market is a main attractor for many hobbyists and independent developers. In the case of Android, this barrier is especially low: just get yourself the SDK and program away. You don’t even need a device; just use the emulator (although having at least one development device is recommended). The open nature of Android also leads to a lot of activity on the Web. Information on all aspects of programming for the system can be found online for free. There’s no need to sign a Non-Disclosure Agreement or wait for some authority to grant you access to their holy ecosystem.
Initially, many of the most successful games on the market were developed by one-person companies and small teams. Major publishers did not set foot in this market for a long time, at least not successfully. Gameloft serves as a prime example. Although big on the iPhone, Gameloft couldn’t get a foothold on Android for a long time and decided instead to sell their games on their own website. Gameloft might not have been happy with the absence of a Digital Rights Management scheme (which is available on Android now). Ultimately, Gameloft started publishing on Google Play again, along with other big companies like Zynga or Glu Mobile.
The Android environment also allows for a lot of experimentation and innovation, as bored people surfing Google Play are searching for little gems, including new ideas and game play mechanics. Experimentation on classic gaming platforms, such as the PC or consoles, often meets with failure. However, Google Play enables you to reach a large audience that is willing to try experimental new ideas, and to reach them with a lot less effort.
This doesn’t mean, of course, that you don’t have to market your game. One way to do so is to inform various blogs and dedicated sites on the Web about your latest game. Many Android users are enthusiasts and regularly frequent such sites, checking in on the next big hit.
Another way to reach a large audience is to get featured in Google Play. Once featured, your application will appear to users in a list that shows up when they start the Google Play application. Many developers have reported a tremendous increase in downloads, which is directly correlated to getting featured in Google Play. How to get featured is a bit of a mystery, though. Having an awesome idea and executing it in the most polished way possible is your best bet, whether you are a big publisher or a small, one-person shop.
Finally, social networks can boost the downloads and sales of your app considerably, just by simple word of mouth. Viral games often make this process even easier for the player by integrating Facebook or Twitter directly. Making a game go viral is one of those black arts that usually has more to do with being at the right place at the right time than planning.
Summary
Android is an exciting beast. You have seen what it’s made of and gotten to know a little about its developer ecosystem. From a development standpoint, it offers you a very interesting system in terms of software and hardware, and the barrier of entry is extremely low, given the freely available SDK. The devices themselves are pretty powerful for handhelds, and they will enable you to present visually rich gaming worlds to your users. The use of sensors, such as the accelerometer, lets you create innovative game ideas with new user interactions. And after you have finished developing your games, you can deploy them to millions of potential gamers in a matter of minutes. Sound exciting? Time to get your hands dirty with some code!