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.

Any application that qualifies as a game must fulfill the following criteria:

The application life cycle applies to any game made on the same platform. But a game has more to the cycle, as you can see in the following diagram:

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.

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.

Feature requirement depends completely on the game design. When we talk about games on Android, the major focus is on mobile and tablet platforms. Mostly, Android games are made for these devices.

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.

A game developer should focus on the following points to increase the portability of a game:

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.

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.

This is a very obvious point for creating a good Android game. A game must support as many resolutions as possible. Android, in particular has many different screen sizes available in the market.

Android has a series of different resolution sets:

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.

A few tasks in a game may run in the background while the main thread is running. These are called asynchronous tasks, mostly used for loading a large file or fetching something from the Internet.

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:

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.