Five problems in the development of mobile free-to-play games
It is no secret that lately, 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 and gaming cycles, prayed for SCRUM and Agile, but the article will not discuss this. Games still need to do well, you need to choose the right technology, you need to understand what to expect from the mysterious free-to-play and what you will have to face. In this article, we will look at the 5 most important technological problems encountered when creating cross-platform mobile free-to-play games.
The idea of ​​creating applications that can work on multiple platforms at once is far from new. For these purposes, a Java platform was created, Microsoft tried to solve the problem of developing for Windows, Xbox and Windows Mobile 7 using .NET and XNA. Mono was created, and .NET went beyond the limits 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 run simultaneously on iOS, Android and, quite perfectly, on Facebook.
The problem is that you can’t help Java with iOS, but you need Adobe Flash for Facebook applications. Fortunately, the designated platform combines the C ++ language (not everyone probably knows, but there is a FlasCC compiler for Flash). The idea is simple - the game is written in C ++ and the binding is done in a language specific to the platform. Thus, the code in C ++ without any changes passes from platform to platform. The difference between the platforms can be leveled by the game engine, as is done in the case of 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 executed on both iOS and Android. However, in this case, you can forget about Flash. You can still remember about HTML 5 and PhoneGap , but this platform still has a number of problems, in particular with the performance on mobile devices.
')
The use of third-party libraries and the SDK is another stumbling block in cross-platform development. Many libraries, such as the Facebook SDK , Flurry , are developed for each platform separately. And since these libraries can be closely connected with the game code, and it’s not always possible to write a common interface for them and add them to the engine, you have to create code like
In addition to code in mobile platforms, the content formats supported and the screen resolution may vary. Therefore, when developing, it is necessary to initially lay on the system for converting general content into platform-specific.
Game developers, especially those who have switched to mobile platforms from the desktop, often do not think about the size of the resulting distribution. A rare game under the PC in recent years takes less than 4GB. Does not cause a big attack of hatred and the fact that the popular MMORPG is 20GB +. The trend does not stop even the fact that the distribution of games has almost completely become digital. However, in the mobile free-to-play, everything is radically different.
The problem is that Google Play and the App Store limit the size of the distribution of the game, which can be downloaded via mobile networks. You have about 50MB. Games that are larger can only be downloaded via Wi-Fi networks. Interestingly, there are countries in which the majority of the population is sitting on 3G, and for obvious reasons, the results of the distribution of your game in these countries will be disappointing.
To overcome this obstacle, many developers go to the trick, laying out the bulk of the game content on their own servers. The game, which occupied only 10Mb in the store, at the first launch can safely download another 300Mb even over 3G. There is no need to go far for examples, almost every free-to-play game works that way right now. Needless to say that for 3G countries the situation does not change for the better. A huge audience falls off, and not waiting for the first game session.
A good solution here is to crush 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 cite the main problems that may occur in the implementation of such a functional:
RAM on mobile devices is not enough. Not only 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 fueled by great competition in the gaming market. People in the bulk are no longer ready to play games with mediocre graphics, preferring higher-quality counterparts. And textures in high resolution can take a significant amount of memory after loading into 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 in Google Play and in the App Store, but the more low-end device models are discarded, the more potential players will be lost. Before deciding whether to turn a device into an unsupported one, it is necessary to consult with statistics on the use of this device, the benefit now such information can be obtained simply.
In addition, there are other equally obvious ways. If your engine has advanced content management tools, then you can generate low quality content by reducing the texture resolution. The picture "zamolitsya", but you can play. Some developers deliberately post a low-resolution version of the game (this reduces the size of the distribution package, 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 it.
Dynamic loading and unloading of content is another way to overcome the problem. It is clear that by loading the game cycle with operations of 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 stream and a separate OpenGL ES context using the EAGLSharegroup .
The issue of optimizing the use of RAM strongly depends on the gameplay of the game, and situations in which the programmer is powerless are not excluded, and the game designer is forced to simplify the game. In the face of fierce competition in the mobile free-to-play gaming market, this may be a necessary evil.
An integral part of the free-to-play model is the interaction of the game client with the server. It is possible to discuss for a long time on which 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 from the server. And the connection (especially through mobile networks) is weak, constantly interrupted and recovering. Your players will try to play in the subway, in the elevator, on the train, just when they want to brighten up the wait.
When organizing client-server interaction, be sure to take into account 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 can be divided into 2 conditional categories according to the way they interact with the server: games that do not allow playing without an Internet connection, and those that allow you to do this. Games that provide some kind of offline gameplay, as a rule, are more difficult to do, however, this approach can work well for retaining users. The following main difficulties in the implementation of offline functionality in an online game can be highlighted:
The second difficulty in organizing client-server interaction is the potentially large response time. If the interaction with the server is done synchronously, which in principle is an error, the game will periodically hang until it receives a response from the server. At the same time, asynchronous work with the server imposes additional difficulties on the organization of the game code. One of the possible solutions to the problem may be deferred processing of commands .
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. Hardware capabilities of mobile platforms, despite significant growth, are still significantly inferior to desktop solutions.
The main methods of solution are profiling and common sense. I can’t give specific advice for mobile platforms, but classical techniques will work well too:
Perhaps, toalmost all of some, this article will seem largely obvious. Despite this, I would like to hope that you learned something new from her, or she pushed you to some important idea. Waiting for your comments, feedback, questions, and thank you for reading to the end.
[1] "Premature optimization is the root of all (or most) programming problems." Donald Knuth (orig. "Programming" )
1. Cross platform
The idea of ​​creating applications that can work on multiple platforms at once is far from new. For these purposes, a Java platform was created, Microsoft tried to solve the problem of developing for Windows, Xbox and Windows Mobile 7 using .NET and XNA. Mono was created, and .NET went beyond the limits 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 run simultaneously on iOS, Android and, quite perfectly, on Facebook.
The problem is that you can’t help Java with iOS, but you need Adobe Flash for Facebook applications. Fortunately, the designated platform combines the C ++ language (not everyone probably knows, but there is a FlasCC compiler for Flash). The idea is simple - the game is written in C ++ and the binding is done in a language specific to the platform. Thus, the code in C ++ without any changes passes from platform to platform. The difference between the platforms can be leveled by the game engine, as is done in the case of 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 executed on both iOS and Android. However, in this case, you can forget about Flash. You can still remember about HTML 5 and PhoneGap , but this platform still has a number of problems, in particular with the performance on mobile devices.
')
The use of third-party libraries and the SDK is another stumbling block in cross-platform development. Many libraries, such as the Facebook SDK , Flurry , are developed for each platform separately. And since these libraries can be closely connected with the game code, and it’s not always possible to write a common interface for them and add them to the engine, you have to create code like
#if defined(_ANDROID_PLATFORM) // put your Android code here #elif defined(_IOS_PLATFORM) // put your iOS code here #endif In addition to code in mobile platforms, the content formats supported and the screen resolution may vary. Therefore, when developing, it is necessary to initially lay on the system for converting general content into platform-specific.
2. The size of the distribution
Game developers, especially those who have switched to mobile platforms from the desktop, often do not think about the size of the resulting distribution. A rare game under the PC in recent years takes less than 4GB. Does not cause a big attack of hatred and the fact that the popular MMORPG is 20GB +. The trend does not stop even the fact that the distribution of games has almost completely become digital. However, in the mobile free-to-play, everything is radically different.
The problem is that Google Play and the App Store limit the size of the distribution of the game, which can be downloaded via mobile networks. You have about 50MB. Games that are larger can only be downloaded via Wi-Fi networks. Interestingly, there are countries in which the majority of the population is sitting on 3G, and for obvious reasons, the results of the distribution of your game in these countries will be disappointing.
To overcome this obstacle, many developers go to the trick, laying out the bulk of the game content on their own servers. The game, which occupied only 10Mb in the store, at the first launch can safely download another 300Mb even over 3G. There is no need to go far for examples, almost every free-to-play game works that way right now. Needless to say that for 3G countries the situation does not change for the better. A huge audience falls off, and not waiting for the first game session.
A good solution here is to crush 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 cite the main problems that may occur in the implementation of such a functional:
- 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. You must ensure that the version of the game and the 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 broken into portions, is a very likely place for players to leave. Therefore, in the process of downloading, the player must somehow entertain, at least not stop the gameplay. Asynchronous work with something always adds additional complexity 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 significantly. It is also necessary to make sure that there is enough space before downloading the content, and if there is not enough, then give the player meaningful recommendations on this matter.
- Place to save content . It's no secret that iOS strictly keeps track of where the user is allowed to save files. Do not save downloaded content in folders where Apple should contain caches and temporary program files. Any utility for optimizing space on the i-device can delete your files without any warning.
- Pumping . 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 manager. This means that the download can be interrupted at any time, including during the recording process on the hard disk. It is necessary to provide for the continuation of downloading content in the next gaming session and checking the resulting files for integrity.
3. RAM
RAM on mobile devices is not enough. Not only 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 fueled by great competition in the gaming market. People in the bulk are no longer ready to play games with mediocre graphics, preferring higher-quality counterparts. And textures in high resolution can take a significant amount of memory after loading into 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 in Google Play and in the App Store, but the more low-end device models are discarded, the more potential players will be lost. Before deciding whether to turn a device into an unsupported one, it is necessary to consult with statistics on the use of this device, the benefit now such information can be obtained simply.
In addition, there are other equally obvious ways. If your engine has advanced content management tools, then you can generate low quality content by reducing the texture resolution. The picture "zamolitsya", but you can play. Some developers deliberately post a low-resolution version of the game (this reduces the size of the distribution package, 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 it.
Dynamic loading and unloading of content is another way to overcome the problem. It is clear that by loading the game cycle with operations of 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 stream and a separate OpenGL ES context using the EAGLSharegroup .
The issue of optimizing the use of RAM strongly depends on the gameplay of the game, and situations in which the programmer is powerless are not excluded, and the game designer is forced to simplify the game. In the face of fierce competition in the mobile free-to-play gaming market, this may 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. It is possible to discuss for a long time on which 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 from the server. And the connection (especially through mobile networks) is weak, constantly interrupted and recovering. Your players will try to play in the subway, in the elevator, on the train, just when they want to brighten up the wait.
When organizing client-server interaction, be sure to take into account 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 can be divided into 2 conditional categories according to the way they interact with the server: games that do not allow playing without an Internet connection, and those that allow you to do this. Games that provide some kind of offline gameplay, as a rule, are more difficult to do, however, this approach can work well for retaining users. The following main difficulties in the implementation of offline functionality in an online game can be highlighted:
- Synchronize progress . Suppose you have allowed the game offline, and your game is published on iOS and Android at the same time. In an amicable way, the same player can play from different devices and continue his progress. However, offline player progress on one of the devices may be lost when you switch to another. But this is not the worst thing, when a player starts the game on the first device again, and the game sends an old offline progress to the server, a conflict will arise. To overcome this difficulty, you will need to use timestamps or other mechanisms.
- "Cheating . " When the server stops controlling the player’s actions and allows him to play without his participation, this is a great chance to get an undeserved gaming advantage, in other words, “cheat”. To do this, the game servers must include protection systems that can detect dishonest players and deprive them of an undeserved advantage, which in itself is not a trivial task.
- Interaction with other players . Suppose a mechanic is provided in the game, when one player can go into the inventory of another and upgrade his sword, having received an award for it. A player offline can break a sword or, say, replace a sword with a bow, while another player will receive outdated data from the server. The example is perhaps 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 in principle is an error, the game will periodically hang until it receives a response from the server. At the same time, asynchronous work with the server imposes additional difficulties on the organization of the game code. One of the possible solutions to the problem may be deferred 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. Hardware capabilities of mobile platforms, despite significant growth, are still significantly inferior to desktop solutions.
The main methods of solution are profiling and common sense. I can’t give specific advice for mobile platforms, but classical techniques will work well too:
- Use memory foreshadowing and minimize memory allocation within the game loop;
- Use caches for data that is time-consuming;
- Use binary data formats instead of text data, where possible;
- Do not create complex class hierarchies or use RTTI for them;
- Do not copy objects by value;
- And the most important thing is that you do not have to deal with “premature optimization” 1 .
Instead of conclusion
Perhaps, to
Notes
[1] "Premature optimization is the root of all (or most) programming problems." Donald Knuth (orig. "Programming" )
Source: https://habr.com/ru/post/192766/
All Articles