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 that is happy to help you with any problem you encounter, as well as offers 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.
A Brief History of 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. 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, most code-named after desserts. 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 the utmost concern.
Version 1.6 (Donut): Introduced support for different screen resolutions. We will revisit this 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 worked well on both tablets and phones.
Android 4.1 (Jelly Bean): Improved the way the UI was 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.
Android 4.4 (KitKat): Included an updated iconset and more refined font. KitKat also allowed apps to run fullscreen.
Android 5 (Lollipop): Lollipop saw a major revamping of the notification panel, and the ability to create guest user accounts.
Android 6 (Marshmallow): Included a new security model that allowed the user to approve or deny specific application security requests, whereas before the security model was all or nothing.
Android 7 (Nougat): The SDK changes included a move to OpenJDK and the ability to run multiple applications on screen at the same time (previously this capability was only built into the Samsung Note line of handsets).
Fragmentation
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, become available on more phones much faster. Five years later, this promise hasn’t been kept as well as many may have hoped. A significant portion of the market is still running older Android versions, mostly Jelly Bean. If the developers of a game want mass-market acceptance, the game will need to run on no fewer than five different versions of Android spread across 600+ device types (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 in as pronounced a way. 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.
The Role of Google
Although Android is officially the brainchild of the Open Handset Alliance, Google is the clear leader when it comes to implementing Android itself and 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
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 developers the option of pricing 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 the 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 in 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. Before Marshmallow, a user could opt to not install an application because of permissions, but a user did not have the ability to simply not allow an application to have a particular permission. However, since Android Marshmallow, users can now accept or deny specific application permissions at run time.
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 that is integrated with Google Play and Google Checkout. A separate API is available with which developers can process in-app purchase transactions.
Google I/O
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; these sessions 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 peripheralssuch as the camera, Global Positioning System (GPS) , compass, accelerometer, touchscreen, trackball, keyboard, controller, and joystick. Note that not all Android devices have all of 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
The Kernel
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 Runtime and Dalvik
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 the 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 its performance, usually at the cost of memory consumption. This is a scalable solution, though, as new devices contain more and more RAM as the standard fare.
Dalvik also has an integrated garbage collector (GC) that 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. Since Android 2.3, Dalvik has employed 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 16MB 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 it in mind as you juggle your image and audio resources.
System Libraries
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) that 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. OpenGL ES 3.0 was introduced in KitKat. Finally, OpenGL ES 3.1 was introduced in Marshmallow. For your purposes, stick with OpenGL ES 2.0 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 is 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
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 areas such 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.
The Software Development Kit
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 will discuss in Chapter 2.
Command-line utilities to communicate with devices.
Build scripts and tools with which to package and deploy applications.
The SDK can be integrated with Android Studio, a popular and feature-rich integrated development environment (IDE) . Android Studio version 2 includes many new features, including the much anticipated Instant Run feature that allows code changes to be pushed to your emulator much quicker.
Note
Chapter 2 covers how to set up Android Studio.
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 of 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.
The Developer Community
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 in which 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.)
Devices, Devices, Devices!
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, wearables, auto, and television 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.
Hardware
Google originally issued the following minimum hardware specifications. Virtually all available Android devices fulfill, and often significantly surpass, these recommendations:
128MB RAM: This specification is a minimum. Current high-end devices already include 1GB RAM, and if Moore’s law has its way the upward trend won’t end any time soon.
256MB flash memory: This is the minimum amount of memory required for storing the system image and applications. For a long time, the 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 Android 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.
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 them 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.
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 and support OpenGL ES 2.0, OpenGL ES 3.0, and OpenGL ES 3.1. 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, smart watches, and set-top boxes ranging from devices with 2.5" QVGA screens running only a software renderer on a 500MHz ARM CPU all the way up to machines with quad 2+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.
The Minimum Practical Target
As of mid-2016, less than 4 percent of all Android devices are running a version of Android older than Jelly Bean. This is important because it means that the game you start now will only have to support a minimum API level of 16 (4.1), and it will still reach 96 percent 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 4.1. Current data is available via Google at http://developer.android.com/resources/dashboard/platform-versions.html , and a chart collected in June 2016 is shown in Figure 1-3.
Figure 1-3. Android version distributions on June 6, 2016
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 4K. On the lowest-end, first-gen device, you’ve got a paltry 500MHz ARM5 CPU and a very limited GPU without much memory. On the other end, you’ve got a high-bandwidth, multicore 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 426 × 320)
Minimum screen density (currently 120 dpi)
Acceptable aspect ratios (currently 4:3 to 16:9)
3D Graphics Acceleration (OpenGL ES 1.0 and OpenGL 2.0 are required)
Input devices
Even if you can’t make sense of some of the items listed, 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 in order 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.
Mobile Gaming Is Different
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-scale game developers making a fortune in 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.
Since hardware prices are constantly dropping and new devices have ever-increasing computational power, mobile devices are 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, download it, 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.
Always Connected
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.
Casual and Hardcore
The overwhelming user adoption of mobile devices also means that people who have never even touched an 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!
Big Market, Small Developers
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 quite a while 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 and 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 that 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!