Five challenges when developing mobile free-to-play games

It's no secret that recently cross-platform mobile free-to-play games have become the main focus of a large number of gaming companies. In this article, we will not talk about the reasons that led to this, nor about the prospects of this direction. Companies changed their business models, drew monetization schemes and game cycles, prayed on SCRUM and Agile, however, the article will not discuss this. Games still need to be done efficiently, you need to choose the right technology, you need to understand what to expect from the mysterious free-to-play and what you will encounter. In this article we will consider the 5 most important technological problems that arise when creating cross-platform mobile free-to-play games.

1. Cross-platform

The idea of ​​creating applications that can run on multiple platforms at once is far from new. For these purposes, the Java platform was created, Microsoft tried to solve the development problem for Windows, Xbox and Windows Mobile 7 using .NET and XNA. Mono was created, and .NET went beyond the boundaries outlined by Redmond. In general, the spears broke, cross-platform in some form appeared. However, the reality is that mobile free-to-play games must be launched simultaneously on iOS, Android and, ideally, on Facebook.

The problem is that you can’t write much for Java under iOS, and for applications for Facebook you need Adobe Flash. Fortunately, the C ++ language unites the indicated platforms (not everyone probably knows, but there is a FlasCC compiler under Flash). The idea is simple - the game is written in C ++ and the binding is done in a platform-specific language. Thus, the C ++ code without any changes goes from platform to platform. The difference between the platforms can be leveled by the game engine, as is the case with the Alawar Engine or the Marmalade SDK .

A good option is to use Unity . Despite the fact that the main language in Unity is C #, thanks to Mono, it can be run on both iOS and Android. However, in this case, you can forget about Flash . You can still remember about HTML 5 and PhoneGap However, there are still a number of problems with this platform, in particular, with performance on mobile devices.

Another stumbling block in cross-platform development is the use of third-party libraries and SDKs. Many libraries, such as the Facebook SDK , Flurry , are developed for each platform individually. And since these libraries can be closely related to the game code, and writing a common interface for them and adding to the engine is not always possible, you have to create code of the form
#if defined(_ANDROID_PLATFORM)
// put your Android code here
#elif defined(_IOS_PLATFORM)
// put your iOS code here

In addition to code on mobile platforms, the supported content formats and screen resolution may vary. Therefore, when developing, it is necessary to initially lay on a system for converting common content into platform-dependent.

2. Distribution size

Game developers, especially those who switched to mobile platforms from desktop ones, often do not think about the size of the resulting distribution. A rare game for PC in recent years takes less than 4GB. The fact that the popular MMORPG is 20GB + does not cause a big fit of hatred. The trend does not stop even the fact that the distribution of games has almost completely become digital. However, in mobile free-to-play everything is radically different.

The problem is that Google Play and the App Store limit the size of the game distribution that can be downloaded via mobile networks. You have approximately 50MB. Games that are larger are only allowed to be downloaded via Wi-Fi networks. It is interesting that there are such countries in which the bulk of the population "sits" on 3G, and the results of the distribution of your game in these countries for obvious reasons will be disappointing.

To overcome this obstacle, many developers go to the trick, laying out the bulk of the content of the game on their own servers. The game, which occupied only 10MB in the store, at the first launch can calmly download another 300MB, even over 3G. You don’t have to go far for examples, almost every free-to-play game now works like this. Needless to say, for 3G countries the situation does not change from this for the better. A huge audience falls off without waiting for the first game session.

A good solution here is to crush the content into small portions and download these portions during the game. The player on the first gaming day does not need content that is intended for 10 gaming days. But what is good and simple from the point of view of a game designer can turn into a non-trivial task for a programmer. I will give the main problems that may occur when implementing such functionality:
  • Versioning the game . A good free-to-play game is constantly updated, and the game is updated from the official store, and the content is downloaded from your servers. It is necessary to ensure that the version of the game and content are consistent. But some of your players may not update their version of the game.
  • Download speed . Downloading additional content, even if it is divided into portions, is a very likely place for players to leave. Therefore, in the download process, the player needs to somehow entertain, at least not stop the gameplay. Asynchronous work with anything always introduces additional difficulties to the organization of the code and the architecture of the game.
  • Free space on the memory card . It is clear that the size of memory cards is limited, and for many classes of devices it is essential. It is necessary even before downloading the content to make sure that there is enough space, and if not enough, then give the player meaningful recommendations in this regard.
  • A place to save content . It's no secret that iOS strictly monitors where the user is allowed to save files. Do not save downloaded content in folders where Apple intended to contain caches and temporary program files. Any utility for optimizing the space on the i-device can delete your files without any warning.
  • Bumping . A distinctive feature of iOS and Android, for example, from desktop operating systems, is that the programs here often end with the removal of the task in the dispatcher. This means that the download can be interrupted at any time, including during recording to the hard drive. It is necessary to provide for continued downloading of content to the next game session and verification of the resulting files for integrity.

3. RAM

RAM on mobile devices is not enough. Not enough for programs and the operating system (although this happens, especially on Android), not enough for computer games. The quality of content in mobile games continues to grow steadily, which is facilitated by greater competition in the gaming market. The bulk of people are no longer ready to play games with mediocre graphics, preferring higher-quality counterparts. And textures in high resolution can occupy a significant amount after loading in RAM.

What to do? The easiest and most frequent way is to limit the fleet of devices on which you can run the game. This is easy to do both on Google Play and the App Store, however, the more budget device models are dropped, the more potential players will be lost. Before deciding to turn a device into an unsupported one, you should always consult the statistics on the use of this device, since now such information can be obtained quite simply.

In addition, there are other equally obvious methods. If your engine has advanced content management tools, then you can generate low quality content by reducing the resolution of textures. The picture will be “washed out”, but it will be possible to play. Some developers deliberately upload a low-resolution version of the game (this also reduces the size of the distribution, among other things), offering the player to download high-resolution content if the hardware capabilities of his device allow it, and even offer in-game rewards for this.

Dynamic loading and unloading of content is another way to overcome the problem. It is clear that loading the game cycle with operations for loading and unloading content from memory, we inevitably increase the frame time. However, there are options, in particular the use of resource loading in a separate thread and in a separate OpenGL ES context using EAGLSharegroup .

The issue of optimizing the use of RAM also greatly depends on the gameplay of the game, and situations in which the programmer is powerless and the game designer are forced to simplify the game are not ruled out. In the face of fierce competition in the market of mobile free-to-play games, this can be a necessary evil.

4. Client-server interaction

An integral part of the free-to-play model is the interaction of the game client with the server. You can discuss for a long time on what technologies to create servers for free-to-play games, how to make them flexibly configurable, easily scalable and portable. You can make the best server in the world, but if the network connection is weak, then there will be little use from the server. And the connection (especially via mobile networks) is weak, constantly interrupted and restored. Your players will try to play in the subway, in the elevator, in the train, exactly when they want to brighten up the wait.

When organizing client-server interaction, be sure to consider possible interruptions in communication, implement checks for the integrity of commands and data. And where it comes to buying game objects for real money, be especially careful.

Mobile free-to-play games by the method of interaction with the server can be divided into 2 conditional categories: games that do not allow playing without an Internet connection, and those that allow it to be done. Games that provide some kind of offline gameplay are generally more difficult to make, however, this approach can work well to retain users. The following main difficulties can be distinguished when implementing offline functionality in an online game:
  • Synchronization of progress . Let's say you have allowed offline play, and your game is published on iOS and Android at the same time. In a good way, the same player can play from different devices and continue their progress. However, the player’s offline progress on one of the devices may be lost when you switch to another. But this is not the worst thing, when the player starts the game on the first device again, and the game sends the old offline progress to the server, a conflict arises. To overcome this difficulty, it will be necessary to use timestamps or other mechanisms.
  • "Cheating .
  • " When the server ceases to control the player’s actions and allows you to play without your participation, then this is a great chance to get an undeserved gaming advantage, in other words, “cheat”. To do this, it is necessary to provide protection systems on game servers that are capable of detecting dishonest players and depriving them of an undeserved advantage, which in itself is not a trivial task.
  • Interaction with other players . Let's say the game provides for mechanics when one player can go into another’s inventory and upgrade his sword, receiving a reward for this. A player offline can break a sword or, say, replace a sword with a bow, while another player will receive stale data from the server. The example may have been somewhat exaggerated, but interactions of this kind exist and this must be taken into account.

The second difficulty in organizing client-server interaction is the potentially large response time. If the interaction with the server is done synchronously, which is basically an error, the game will hang periodically until it receives a response from the server. At the same time, asynchronous operation with the server imposes additional difficulties on the organization of the game code. One of the possible solutions to the problem may be delayed processing of commands .

5. Performance

Perhaps the most obvious point. Needless to say, the game should not slow down on any of the devices for which it is intended. This is true not only for mobile development, but for game development in general. The hardware capabilities of mobile platforms, despite significant growth, are still significantly inferior to desktop solutions.

The main solution methods are profiling and common sense. I can’t give specific tips for mobile platforms, but classic techniques will work well too:
  • Use memory allocation and minimize memory allocation inside the game loop;
  • Use caches for data that is difficult to compute;
  • Use binary data formats instead of text, where possible;
  • Do not create complex class hierarchies and do not use RTTI for them;
  • Do not copy objects by value;
  • And most importantly - do not engage in "premature optimization" 1 .

Instead of a conclusion

Perhaps, almost all some of this article will seem in many ways obvious. Despite this, I want to hope that you learned something new from her, or she pushed you to some important idea. I look forward to your comments, feedback, questions, and thank you for reading to the end.


[1] «Преждевременная оптимизация — корень всех (или большинства) проблем в программировании». Дональд Кнут (ориг. «Premature optimization is the root of all evil (or at least most of it) in programming.» )