Developing games has become a very popular profession through the last decade. Previously, it was limited to PCs, consoles, and a few embedded gaming devices. Today's world is fully equipped with modern gadgets with better technology, better portability, better flexibility, and better quality. This has opened up the doors for developers to create games with better quality and fewer limitations.
Android is a modern age operating system, and is being used widely for many hardware platforms. Hence, the world of Android has become a target for game developers. The most efficient and useful targets are Android smartphones and tablets. According to surveys of the global market share for mobile OS, Android tops it with a 78-80% share in 2015. Android is now not only a mobile OS, it is being used in TVs and smart watches also. Hence, the popularity of Android is touching the sky among game developers.
This book will be helpful for those who already have a background in Android game development. Let's start with the following topics:
Android game development
A game is not just an application
Choosing target device configuration for your game
Best practices while making a game on Android
Android is a mobile operating system based on the Linux kernel. Currently, it is being developed by Google. The OS has released many versions since 2008 to date. But after the release of Android 2.2 (Froyo) and Android 2.3 (Gingerbread), this OS caught the attention of many game developers. Android uses what is called the Dalvik Virtual Machine (DVM), which is an open source implementation of a Java Virtual Machine (JVM). There are several differences between Dalvik and a standard JVM, some subtle, some not so subtle. The DVM is also not aligned to either Java SE or Java ME, but to an Apache implementation called Apache Harmony Java. All of this makes for a slight learning curve if you happen to be transitioning from Java ME. Google introduced an alternative to DVM called Android RunTime (ART) from Android 4.4 (KitKat), and ART replaced DVM from Android 5.0 (Lollipop). ART mainly features Ahead-of-time (AOT) compilation, and an improved garbage collection process, and it provides a smaller memory footprint in order to optimize memory operations. However, most game developers use DVM to support older versions of Android devices.
Android game development started extensively when this OS was adapted by many hardware platforms. Android is mostly being used on the mobile and tablet platforms. When the mobile game industry started migrating from Symbian or Java to Android or other smart mobile OSes, Android game development started to boom.
Smooth user interface
Better look and feel
Better hardware platform
More design flexibility
It is always easier to use a common operating system than an embedded real-time operating system (RTOS). The user need not spend time on different hardware to learn its usability. Android is one such easy-to-use operating system.
The visual user interface is very attractive in Android, as it always runs on better hardware configuration than Symbian, Java, or an embedded OS. It enhances user experience, which is one of the reasons why it got adapted by so many organizations. As the user base of Android increased, many more game developers started targeting this platform.
From the perspective of game design, the enhanced Android features list gave flexibility to explore more in mobile games. Thus, the game design style was enhanced.
The current world has various types of hardware that run on Android. Apart from mobile phones, Android is being used on tablets, televisions, wristwatches, consoles, digital cameras, PCs, and other devices. Nowadays, game developers are targeting almost every Android platform.
Direct manipulation interface is the top feature of Android. It interacts with the user through a continuous representation of objects of interest, dynamic real-time action, and dynamic feedback. Android mainly uses a touch interface with real-time action such as swiping, dragging, tapping, and multi-touch, which are widely used in game development for Android.
Android application development is mainly based on Java (SDK) and C++ (NDK), which are the most common programming languages in the world. Hence, developing a game has become much easier.
Since version 2.2 (Froyo), Google has developed an integrated service called Google Play Services. It is a closed system-level API service provider, which has proved to be very useful in game development.
A large number of third-party tools available for Android development have also eased the job of game developers. Some of the tools we can mention are Android Studio, App Inventor, Corona, Delphi, Testdroid, Sample Directmedia Layer, Visual Studio, Eclipse IDE, and RubyMotions.
Android device hardware configuration has to follow a minimum configuration list, so it becomes very easy for the developers to identify the configuration. Moreover, it has to maintain a minimum standard to run applications easily.
There are plenty of sensors associated with Android devices (mostly on mobiles or tablets), which are a very good option for designing the controls of a game.
Android supports awesome connectivity through Bluetooth, Wi-Fi, GSM/CDMA/EDGE, LTE, NFC, IDEN, and the like. These help game developers to create multiplayer games easily.
These are the features that a game developer should keep in mind. The rest of the features are less important for game development. However, there is always a chance to explore more, and create a few specific-feature oriented games.
The range of Android device configurations is wide. So, designing a game targeting most of them is a big challenge.
Many of the Android game developers design and build games for specific hardware configurations, like Tegra, or Snapdragon, or a particular device like Xperia Play. Nvidia's Tegra is the most commonly used chip in these situations; the THD branding often indicates that a game was built for Tegra only. Nvidia has a lot of experience working with developers on the desktop side, and has brought that expertise to mobiles. Android game developers are encouraged to make use of Tegra-specific APIs to build their games. The problem with this scenario is that most users don't have Tegra in their phones. In fact, many LTE handsets that might have otherwise had that gaming-friendly chip are being moved over to Snapdragon S4. Now, for a developer, it is very difficult to maintain performance across different graphic processors.
Game controls can use the accelerometer or gravity sensor for a physics-based mechanism (if supported by the hardware), which is always an added advantage for real-time interactivity.
On-touch screen devices, and dynamic controls like swiping, dragging, pinching, and multi-touch, can be experienced through Android.
Android supports OpenGL for better graphic rendering, which enhances the visual quality of the game.
Miracast in Android is another feature which enables games to use multiple displays and screen sharing for a better experience.
Development of any game requires a design Android is not an exception. The design of Android games requires a lot of knowledge about the target hardware. There are thousands of varieties available for Android. Designers have to choose their target very carefully, and then design the game scope.
As previously stated, it is a challenge not only for the programmers but for the designers as well. Different Android devices have different configurations, but it is very important for a designer that the common features should be targeted.
It is a very common practice for an application developer to switch to game development and vice versa. Many do not change their style, and approach game development accordingly. Every developer of games should keep in mind that a game is not just an application.
A game can be termed an interactive entertainment system, in brief. The main objective of games is to provide fun, be it a software or physical exercise. On the other hand, the main objective of an application is to make life easier with a mechanical job. So the development approaches for these two are completely different. However, this still remains a point of discussion, as every game is an application. Any application can adapt the features of games in order to provide a better user experience.
It is difficult to differentiate between the complexities of development of a game versus an application. However, game development has an edge. Most of the application developers do not have to focus much on speed performance, whereas all game developers have to focus on speed and the frame rate of the game.
Every game is an application for sure, but every application is not a game. This statement itself conveys the message that on a single reference scale, game development has more parameters than applications, yet it has to have all the features of an application.
Application development is technology-oriented, whereas game development is fun-oriented. This increases the difficulties in game development. Fun is an emotion, there is no parameter to calculate that. So, while making games, a developer can never know what exactly the game is going to achieve in terms of fun. On the other hand, an application developer is very much certain that the application target can be achieved if all the specifications meet the requirement.
Game development very rigorously needs mathematics to work on the physics or graphics side; even AI needs a lot of mathematics for the low-level stuff. Applications are more technology driven, with limited use of graphics.
It must entertain a set of users in terms of fun
There must be a set of milestones to achieve for the users of the application
It should reward the users for achieving a milestone
It should have a more dynamic user interface
There must be better visual impact
It should be performance driven rather than feature driven
The application life cycle is simpler a game life cycle. The game cycle runs within the running phase of the application life cycle. This is typically termed the game loop. This will be discussed later in detail.
This game loop runs on game states. The application may have only one running state, but there are multiple game update states. In a typical system of game development, there are a minimum of two update states. One depends on the game loop execution, and the other depends on the time interval. The second one actually controls the frame rate.
There are noticeable differences between the performance management systems for games and applications. Performance is one of the biggest requirements in game development, whereas it is only a recommended feature for an application, as the frame rate does not affect the quality.
It is an accepted truth that games are heavier than applications on the same scale. A game runs on repetitive frames—one set of tasks runs on one frame. This increases the instruction traffic for the processor. In an application, there are generally no loops; the state of the application depends on user action. In this case, the processor gets plenty of time to execute the instruction as no instructions are being sent repetitively.
Applications which are not games have different memory management than games. In case of games, multimedia assets are the main objects, which occupy a larger portion of the heap than class objects. But in the case of applications, it is just the opposite. Applications need to load only the object they require for the state, that is, class objects.
For any game developer, memory optimization is a must. Because of the extensive use of memory, a developer cannot afford to have unused objects loaded in memory, or any memory leakage caused by mishandled memory pointers. This has a direct effect on running games. For an application, memory optimization is obviously a good practice, but most of the time it has no direct or indirect effect on running the application. However, a good programmer should always have knowledge about memory optimization.
As mentioned earlier, Android has a variety of device configurations. So, it is very important for an Android game developer to choose the target very carefully. The general approach should have these parameters:
Scope for portability
This is basically the scale on which the game is being made. The larger the scale, the better the configuration that it'll need. This includes mainly the game size, which means the amount of memory it will consume on a device. Many Android devices are configured with very low RAM and internal memory storage. If the targeted device does not have the required configuration, the game will not run. Even if the game is fully optimized, it can fail depending on the hardware platform it is running on.
Every game requires a set of processes to be executed recursively, which requires processor speed. If a game is process-heavy, and the targeted device has a slow processor, the game will experience some horrible frame rate issue, or crash.
Every Android game developer must be aware of the requirements of memory, processor, and other constraints when choosing the target device.
Let's take the example of an Android game which requires at least 120 MB of disk space to install, 512 MB of RAM to run, and a 1.2 GHz processor speed to achieve a decent frame rate. Now consider a mobile device which matches these specifications exactly, but being a developer, one must not assume that the device will not have any other application installed or running in parallel. So, in this case, there is a fair assumption that the game will not have the required support even if the device meets its requirement. Hence, for this example game, the target device must have a higher configuration than the minimum requirement.
Now, let's take a look at the opposite scenario. Assuming the same game requirements, consider a device having 8 GB of available storage, 2 GB of RAM, and a 2 GHz multicore processor. There is no doubt that the game will run on that device with maximum performance, but the device could have supported a larger-scale game. So the resource utilization is not efficient in this scenario. This is where porting comes in. A game developer should upscale the game quality, and create a different build for those high-end configuration devices.
It is a very common practice in the industry to exclude a few devices from the targeted device list to make the game run properly. In a few cases, the game developer creates separate game builds to support most of the devices and maintain the game quality.
The target audience is the particular group for which the game is made. It is assumed that a particular set of people will have most fun from the game, or that they will play the game more than other people.
Every game design has its target audience. The set of target devices are the direct consequence of the set of target audience. For example, if the target audience is working professionals between the ages of 25 to 40, it makes no sense to create the game for an Android TV no matter what the game scale is. This is because this specific audience will mostly use mobile devices, as they have less time to sit in front of a television set. So, the list of target devices should contain mobile devices for this target audience.
We can see a lot of difference between devices in the same category. For now, let's take the example of Android mobile phones, as this is the most-used Android category. We can see a range of Android devices available in the market. Most of the Android phones are comparatively cheaper, and have fewer features. A major section of the target audience that uses such phones belongs in particular to Asia or the third world countries. So while making a game for this target audience, the developer should consider the minimum configuration target.
If we consider other platforms like watches, TVs, or consoles, the feature set varies. Televisions provide a bigger display with less user control, watches have limited display area and minimum configuration, consoles have better graphic quality with dedicated controls, and so on. It is very important to identify the feature list which is required to recognize the hardware devices.
There might be a scenario where an accelerometer, Bluetooth, Wi-Fi, or some other special feature is being used in a game, so the selected hardware platform must have those features. However, common mobile and tablet devices have almost the same set of features that a game developer might generally use. This feature dependency becomes very specific when Android games are made for some particular hardware platform like consoles or VR devices.
While choosing the target hardware device, every game developer must consider the scope for portability of games. The more portable a game becomes, lesser the effort required to select or choose the target hardware.
The portability of games always depends on the vision of the game developer. Porting can take two different approaches: platform porting and hardware porting. We will only focus on hardware porting here, as we have already fixed the platform to be Android.
Creating different sets of assets
Designing different sets of controls
Finding and listing alternatives for a feature
Controlling memory usage
Controlling the frame rate
A good portable game is a balanced combination of all of these preceding points. Most of the time, the target hardware is chosen first depending on the other parameters, and only then does the developer work on the portability of the game.
Making an Android game is not a big deal. But making the game in the right way through which the game looks great, and performs well across as many devices as possible, is very important. The best practices should focus on the following points:
Maintaining game quality
Minimalistic user interface
Supporting maximum resolutions
Supporting maximum devices
Maintaining battery usage
Extended support for multiple visual qualities
Introducing social networking and multiplayer
Let's discuss these in brief here. We will elaborate on this in detail later as the book progresses.
There are millions of games available in the market, and thousands being introduced every week. So, just making a good game is not enough nowadays. Every developer should maintain their game periodically to cope with the quality of other improved games.
The developer should keep a constant eye on the reviews and complaints from the users. The game quality can be improved a lot based on this feedback. No one can predict the exact user reaction to the game before it is out in the market. So, in most cases, it is noticed that the game goes through a drastic change in design, or other means, to keep the consumer happy.
There are a few other ways to track the behavior of consumers/players. There are several tools available to do this job efficiently, such as Google Analytics, Game Analytics, Flurry, and so on. Besides these internal integrations, user comments on stores or blogs are helpful to maintain the quality of a game.
Fixing bugs in a game is another major factor in increasing the quality of the game. It is not possible to get rid of all the bugs inside the game during development. The App Store bug report tool is useful for tracking major crashes and ANRs when the game is out in the market. Besides this, the developer can use Android error reporting to track errors and bugs from real users. Android provides this feature in Android versions 2.2 and later.
Two more parameters that improve the quality of the game are stable gameplay, and consistent frame rate.
This is a typical design practice for Android games. A common mistake that many developers make is that they design a long and hectic user interface to take the user to the gameplay. This section should be as short as possible. The player should experience the game with minimum effort the very first time. Most users leave games because of the heavy UI interface.
Technically, a developer should take care of the device UI options like Menu, Back, and Home. These are the most common options for the Android mobile and tablet platforms. The behavior of all these options should be controlled within the game, as the user might press/touch them accidentally while playing the game. Also, there should be a quick interface to quit the game.
Basically, having a minimum user interface and fewer screen transactions saves a lot of time, which has a direct impact on gameplay sessions.
Android has a series of different resolution sets:
LDPI (approximately 120 dpi)
MDPI (approximately 160 dpi)
HDPI (approximately 240 dpi)
XHDPI (approximately 320 dpi)
XXHDI (approximately 480 dpi)
XXXHDPI (approximately 640 dpi)
If they do not follow multiple resolution specifications, the developer can also opt for the screen compatibility option available as a last resort. However, it is recommended not to use this feature of Android, because it can reduce the visual quality significantly. This option is, by default, disabled from Android API version 11.
Other than the different screen sizes, Android has a variety of device configurations. Most developers filter the device list only by screen resolution, which is a bad practice. An Android game developer should always consider the target device configuration along with the resolution.
When building their applications, developers should remember not to make assumptions about specific keyboard layouts, the touch interface, or other interactive systems unless, of course, the game is restricted so that it can only be used on those devices.
Optimizing the application in terms of memory and performance is also helpful in supporting more devices. The developer should not restrict them to only a few sets of devices. Optimal use of disk space and the processor opens up the opportunity to increase the support range.
A single game application build can support more devices with some simple tricks. On Android activity launch, the developer should detect hardware information, and use that to create some sort of rules by which the entire game quality and processing speed can be controlled.
Another type of background task is called services, which works even when the main application thread is not running. This is a very useful feature for communicating with the device on which the game is installed.
It is a good practice for any game developer to use these features in the game properly. A large chunk of data usually takes longer time, but it should not pause the game loop. In another scenario, asynchronous tasks are used when the game communicates with the Internet or other connectivity. This feature helps to keep the main thread running, and provides dynamic feedback.
Background services are useful for increasing the communication between the developer and user. They can provide user activity information to improve the game as well as notifying users about the latest update or information.
Interruption handling is one of the trickiest parts of game development. As we discussed earlier about the game loop, the loop pauses or, sometimes, terminates on any external interruption. In an ongoing game cycle, the interruption should not harm the gaming experience. It is a very common problem for developers that the game restarts after being interrupted. Android is most likely to kill the game activity if it remains in an idle state for a long time, or if some other activity needs provision to run. In these cases, most of the time, the player loses his/her progress.
It is good practice to save the user progress periodically to avoid any loss of data or progression. But saving data may cause lags in the game loop, and can drop the frame rate significantly. The game developer should identify the states where the data can be saved without affecting the gaming experience.
The way to handle this issue in a multi-activity application is to detect and pause/resume all the running threads. Many times, the game developer keeps running the thread, as the primary objective is just to pause/resume the game loop properly on interruption. In most cases, all of the background processes do not pause, causing unusual behavior by the game.
One of the reasons for the success of an Android game is power efficiency. Most likely, the Android hardware platform will be a mobile device, which has a limited source of power. So power-saving applications are always preferred.
A major chunk of the battery is consumed by rendering and network connectivity. From the gaming perspective, rendering and connectivity are both necessary. So, there is a fair chance that the game uses up a lot of power.
Most game developers focus a lot on visual appearance. It increases the graphic quality as well as battery consumption. So it is a very good practice for the developer to always focus more on the technical quality of the graphical assets. Assets should not boost up processing or rendering, as, developers often use non-optimized assets.
Another process which consumes a lot of battery is background services. These are used widely for better connectivity with consumers or for some web-based services. Technically this process pings frequently to stay connected with the desired network. Developers can control this frequency. Another way to avoid this is by killing a service which is not connected for a long time or was disconnected from the network, with the help of Android PackageManager.
In many cases, it is seen that a game becomes popular, or has a better user count than another, better-quality game, just because of lower battery consumption.
If the developers can determine that connectivity is lost, then all of the receivers except the connectivity-change receiver can be disabled using native APIs. Conversely, once the developers are connected, then they can stop listening for connectivity changes, and simply check to see if the application is online immediately before performing an update; they can then reschedule a recurring update alarm.
Developers can use the same technique to delay a download that requires higher bandwidth to complete simply by enabling a broadcast receiver, which will listen for connectivity changes, and initiate the download only after the application is connected to Wi-Fi. This significantly reduces battery use.
This section actually starts with supporting multiple resolutions. We have already discussed multiple-size screens with different dpi. The following list is another standard that Android devices follow:
QVGA (low PPI)
WQVGA (medium-low PPI)
HVGA (medium-high PPI)
WVGA (medium-high PPI)
SVGA (high PPI)
VGA (very high PPI)
Creating graphics using this standard is always beneficial in order to achieve the best possible visual quality across devices. This notation mainly depends on the screen size, irrespective of the resolution. It is very common for Android devices to have the same resolution running on different screen sizes. Creating assets specially optimized for targeted devices will always help to increase the visual quality.
The gaming industry's style and standards are changing rapidly. Now gaming is being used for social connectivity, which is, connecting more than one real user on a single platform. Very careful use of this social element can increase the user base and retention rate significantly.
In many games, there is the possibility of more than one user being able to experience the same game state together, and to improve the game play by real-time interaction. A few board games such as Chess, Ludo, and Snakes and Ladders, are examples of such a possibility. Beside those, some real-time online multiplayer games are also at their peak.
Google has its own multiplayer features through Google Play Services. Besides popular turn-based and real-time multiplayer support, Google has also introduced a feature to connect players in close proximity on a single platform through Wi-Fi, called Google Nearby. There are many other third-party platforms that support multiplayer.
Making an Android game is not difficult, making a successful game is. From a technical point of view, a successful game must provide smooth gameplay to provide users with an excellent, swift gaming experience. Great visual quality with better graphics always attracts users and other potential players nearby, while fewer bugs removes the irritation of users during gameplay, and the game can perform according to plan. A wide range of device support can increase the number of users and gameplay sessions, optimal use of resources ensures the minimum possible application package size, and finally, a good relationship between the developer and users, through excellent communication skills, can eliminate the few doubts and confusions of the users.
We have covered all of these points in brief to give you an idea about how to make a successful Android game. Making an Android game is no different to making any software. However, a game must follow some practices in order to achieve its fun element. You will learn in detail about making an efficient Android game later in this book. You will also eventually learn about several aspects of game development for the Android platform. You will recognize and realize the current state of available Android devices made by various manufacturers. There are many types of devices, which we will have a look into.
We will try to explore a better and efficient approach for Android game development ,with many development procedures, styles, and standards for different hardware platforms. We will further dig deep, with game-specific development standards for 2D, 3D, and virtual reality games. We will further discuss native development, with shaders and various optimization techniques.
Then, finally, we will explore various ways to make a successful game, which is good enough from the monetization point of view. Since developers must know about each and every user behavior to make the game better, you can realize the power of data collected from users through this book.