Geekly Articles each Day
⬆️ ⬇️

UE4 and mobile development: myths and reality



It is widely believed that the Unreal Engine 4 is too "heavy" technology for mobile games. At the same time, the number of projects released on this engine in mobile sites is growing every day.



Why do more developers choose UE4 for their projects? What difficulties can you encounter when working on a mobile game? What approaches and pipelines should be used and what should be avoided? Our Pushkin studio experience will lift the veil of secrecy over these and other issues.



This article is a text version of the report, read February 9, 2017 at the Unreal Engine Meetup event at Mail.Ru Group . Despite the date of publication of the source material, the information provided is not only the “present day” and contains actual figures, but also confirms the forecasts made by the author at the event itself.



Myth One: Nobody uses the Unreal Engine.



The last four years I have been involved in mobile games. And I am constantly confronted with the development myths on Unreal 4 circulating in the global community. One of these myths says: “There are very few games on this engine, it is difficult to work with it. Let's take Unity, there are tens and hundreds of thousands of different games on it . ” Once, that was how it was. But today it is no longer true. Here are the brightest fresh mobile games made on UE4:





This myth is very easy to debunk. Industry monsters are beginning to actively use Unreal. There are many more examples, there are already dozens of them. Recently released games began to develop a year and a half ago. So today we are seeing the result of the beginning of active use of the Unreal Engine in the mobile segment.



What is the reason? Unreal Engine 3 had a lot of limitations. First, it required a full license, which cost some money. Free UDK allowed to collect applications only for iOS. It was impossible to make many changes, the developers used only the scripting language and could not modify the engine.



After the Unreal Engine became available to everyone and everyone, with full source code, with the support of the community and developers, mobile games began to be created on this engine. Most game developers still start with their own indi-developments, gradually becoming specialists, who can then implement large projects in large companies. But if you do not have available tools and technologies, then you just can not learn this.



2017 can be called the year of big releases in the mobile segment on the Unreal Engine 4. You can type in Google “Unreal Engine mobile” and see dozens of games, ranging from indie to the largest titles.



Myth two: low productivity



“Unreal Engine is slow. It's impossible to work with him, I created a simple scene, everything slows down, it's impossible to play with this, let's take Unity, you can make millions of triangles . ” If you want to display just millions of triangles that do nothing, then you should probably take Unity. If we are talking about a real production problem, about simulated characters, landscape, scene, effects - then we begin to consider real synthetic tests, not synthetic ones.



Screenshots of some of our internal development:









In the scenes there can be more than 30 characters with their skeletal animation, all are displayed simultaneously. A large level consists of several pieces, it is loaded as the player moves from location to location. During loadings, all these units run locally on client devices, routes are calculated for them. For fun, try putting 30 character class characters on the PC and run them. Even for a powerful computer, this will not be easy.



We also have a lot of effects, fire, magic, explosions. According to our tests, there were more than 30 frames on the iPhone 5S. Today, this phone can be considered as the minimum platform. What kind of brakes are we talking about?



It's always about how you work with the engine. If you make each character 10-15 thousand polygons, then if there are more than two of them in the scene, then any mobile phone will be killed. So the engine's performance is a matter of designing the game, not the capabilities of the technology itself.



Second example:







Large card, simultaneously displays more than 15 pieces of equipment. Each tanker skating rinks in compliance with physics, correctly respond to soil irregularities. These are not idols with fixed caterpillars, which joyfully drive on a flat field. We are deeply miscalculated physics and mechanics. Each of these pieces of equipment is a separate user playing on the network. Imagine the amount of traffic that needs to be processed every second, and we are still talking about mobile devices.



On the map more than 2500 dynamic objects. They can be destroyed, moved, you can somehow interact. This is not just a prearranged scene that is rendered by certain batch files. Each of these objects takes its own draw call, memory, has its own life cycle.



Static objects - about 500.



The surface of the earth is covered with grass - foliage in the terminology of the engine. In the scene there may be about 5,000 instances of grassy bushes. The most common complaint about the foliage in the Unreal Engine is: “I have trained a lot of grass - everything is slowing down for me” . And on the desktop. And we have 5000 copies on the same engine - and nothing slows down. What am I doing wrong and where is the engine?



We use the latest version of the engine, we have fully dynamic shadows. That is, all these scenes (unfortunately, I cannot reveal some details), all objects cast dynamic shadows that repeat all the movements of objects. How it works? In fact, in each frame an additional rendering of all objects in a lower resolution is performed. That is, we are talking about doubling the load on computing devices.



If you started developing mobile games six months or a year ago, you should be guided by the following system requirements:



iOS 9/10 (Metal 1.1)





The minimum target devices are iPad Air, iPad Mini retina (second and higher), iPhone 6 and iPhone 5S. "Minimality" is determined by the size of the RAM. There is no point in looking at older devices. All Apple hardware that does not support Metal is not your target market. Moreover, you can safely release in the App Store applications that require iOS 9 or a 64-bit system, and then automatically get these devices as minimally necessary. This is already supported at the platform level, and not the first day. You should not try to optimize the game for very ancient devices.



Moreover, if you started developing the game today, you should forget about these devices already. In a year they will almost not be. For example, the iPhone 5S got to the list simply by tradition, in fact it is necessary to consider the iPhone 6 as a minimal device. Target gadgets of tomorrow:



iOS 10 (Metal 1.2+)





How do they differ from the previous generation? The processor is not particularly important, the main thing is RAM. This is a bottleneck of mobile development. Everyone is accustomed to working with unlimited memory on desktops. But when you make a mobile game, you must remember that a gamer may not have 2-3 GB of available memory.



I specifically do not give examples of Android-devices, there are some pitfalls. In particular, for Unreal, it does not matter how many cores you have. It is important which one is the fastest. Therefore, all these "iPhones", including the seven, which has two cores, work, oddly enough, faster. Although Android has its advantages.



Myth three: high system requirements



In the group of the official community, every week the topic is raised two or three times: "To work in the Unreal Engine, you need a very powerful computer . " Manuals are being written on this topic, themes are constantly being created on the Epic Games forum: “Do I have so much money, tell me what to buy?”



The working configuration of my computer looks like this, there is a lot of stuff there.





My second working configuration looks like this - this is a box with an integrated video card, in my opinion, Intel 3000.





You can easily create mobile games on it. Even some desktop projects are pulling. But everything connected with the calculation on the CPU takes a lot of time. In particular, if you cheat lighting or shaders.



But if you are developing for mobile devices, when you know what you want to do and do not experiment with giant shaders, that's enough. Therefore, there are no exorbitant computer requirements and there have not been any. On the contrary, the requirements are gradually reduced.



Of course, if you are developing virtual reality projects, or creating an AAA project with a bunch of graphics, then you will need powerful hardware. But not for mobile phones.



Myth Four: Unreal is more inhibited than Unity



The myth originated at the time of the UDK. The projects created on it were inferior to those on Unity. I myself have come across this. This was due to the limitations of the UDK itself, and each time it was necessary to prove that you were not a camel.



By what parameters can you compare the performance of engines?







They are close, but Unreal wins more often if we are talking about a large number of similar objects, because it knows how to instantiate them very well. If we are talking about different objects, then the difference is 1-2 frames.



Therefore, choose a tool depending on the project.



Unity game weighs much less than Unreal



If you make a little game, it will be like this. If we put together an empty project, then on Unreal it will weigh 70-80 MB, and on Unity 10 MB. But what does the build size consist of? In the first place of assets, which are present in the game. If the game has 80 different characters, each with 20 types of swords and 10 cards, then the size of the build on any of the engines will be calculated in gigabytes. What is the difference, what size binaries lie side by side? Yes, on Unity 10-15 MB, and on Unreal 60 MB. But with gigabyte asses, it doesn't matter. And if you make small casual games, or games with 2D graphics, then you don’t need Unreal.



Both engines have their own characteristics. With Unity, you can cut everything off and leave 2D graphics. Unreal Engine is not a 2D graphics engine at all. It is designed for 3D games with good graphics quality. Yes, 2D support is available, but as an added bonus. I repeat: choose a tool depending on the project . The build size is not critical if you are doing a 3D game. Again, the difference of 200 MB does not matter: it is already more than 100 permissible on Google Play to download over 3G.



Iteration duration



How long is the project building on Unreal? It all depends on how you work with the asset. In general, the duration of the iteration is several times longer than on Unity. However, the Unreal Engine has an excellent mobile preview mode. What is he good at? Unlike many other solutions, including those from Unity, it provides an identical image on the desktop with Android and iOS. With exactly the same settings, colors and quality as it will be on mobile devices.





If you take a top mobile device, the pictures will be identical. This is a huge advantage. You can iterate much faster. You do not need to collect the game on your device each time to see how it will look. Playability is another matter; it may take time. But how it will look, work with graphics - this can be found on the desktop in a matter of seconds. In the 15 version coming out soon they added a preview for Metal: you can appreciate the features that are not found in OpenGL 2.0.



Engine extensibility and upgrade



In Unity, you can easily write plugins that somehow extend the editor. In this case, you can not edit the engine. In Unreal, you can also write plugins, but this requires more knowledge and data organization. In this case, you can edit anything in the engine.



Mobile development issues: Slate and processor





In the Unreal Engine, the interface is implemented using Slate technology. It is deeply embedded in the engine, it can not just be turned off at some point. Slate handles input devices, including through the operating system. She has her own problems. It is optimized primarily for work on desktop devices. Secondarily - for mobile.



Do not use Slate for the HUD - interface, in which the main actions of the game take place, where performance is critical. Suppose 10 soldiers on one side are fighting with 10 soldiers on the other. Everything has to fly. At this point, do not use Slate. It is better to switch to Canvas - manual mode. The grandfather method that has been around for decades, but it works faster in terms of CPU consumption.



Coarse optimization at the engine level is also optimization . If you have already grown to optimize, then do not be afraid of it - take and edit the engine. Usually such interventions are situational and depend on the project. For example, we took the code associated with Slate and threw our connections there. Although not a single screen with Slate was displayed, the default was still a lot of processing. Then we just turned it off. True, if there is at least one widget, then processing is present. And if there are no widgets, a very simple function is called that does nothing. It is crooked, it is not universal, but it works. When you make a project for users, first of all it should work fine, and not be a universal solution.



Mobile development issues: RAM



This applies to any 3D-application - you need more memory. How to be?





I'll start with the simplest - the resolution and the number of textures . If you have a huge number of different textures, and all of them are of high resolution, then this may look cool. But you make a game for mobile devices, so you need to keep a balance. Make atlases, reuse some textures. Organize your work so as to use them to a minimum. For example, on a huge map for half a kilometer we use only five textural atlases, color and normal. That is only 10 textures cover a huge map with static objects. And thanks to the skill of the artist you will not find two identical places on this map.



Use texture atlases . Now there are two open technologies - VaTexAtlas and Paper2D (the entire Paper2D module is required). If you do not use any of the features of the latter, do not work with 2D graphics, then it is easier to disable it for the sake of reducing the build. Paper2D eats about 40 MB.



Few people know that the models themselves eat a lot of memory. Today, mobile games use characters and environments with lots of polygons. And all this actively consumes memory.



Use Merge Actors carefully . This functionality helps a lot to optimize a draw call: 20 houses are far away, you have combined them and got one model, say, for 10 thousand polygons. These 10 thousand. Verteks are loaded into memory and hang there. Therefore, it is very easy to optimize the map from the point of view of a draw call, and get a huge memory consumption. Balance is important, do not forget.



And first of all: control the number of shader permutations . What is material instance? A set of parameters that is used in the material. That is, the material already in memory is used, and the parameters change in it. After applying them, the same area of ​​memory is sent further to the drawing. In terms of memory, everything would be fine. You have basic material, say, after compilation weighs 10 MB; You have 20 material instance, each for your character, they weigh 5-10 KB, in memory, they take as much. Suppose you used a master material in which the switches are applied. They allow you to have one great material for all occasions, but here you have to be very careful. If you turn on some kind of switch, any boolean type parameter that makes the compilation flow of a material differently work, then after packing this material instance becomes a material. Not just a set of parameters, but also a set of shader instructions. Let's say you created the material for the right and left hand. The right hand is drawn in gold, the left hand - in silver. Material one, in the hands of the switches. And at the same time for each character a material instance is made, and in each there is a tick - this is for the left hand, this is for the right. Welcome to the world of shaders: you immediately consume 200 MB of memory, just because you forgot about this situation.



It is best to create two material instances already from the base material, and in each to put this tick. And then these material instance change only the numeric parameters. This approach reduces memory consumption and disk space, because shaders are loaded into memory entirely. If a lot of things are generated, then the build can grow to 1.5 GB, although you have only one level. I myself came across this: once a game card with several characters took up more than 1 GB. On Apple, more than 1 GB, on Android - 300 MB.



Mobile development issues: CPU consumption



On iOS devices, be sure to use Metal, squeeze everything out of it. On Android, such a thing as Vulkan will save you. On both platforms, there is OpenGL 3, but for Android, CPU consumption will be higher.





Transfer your calculations to the GPU , because the graphics chip is often idle. First of all - visual effects. They have a part that is rendered, and a part that generates and processes. Fewer particles - more visualization. And do not forget about the balance.



Do not handle what the player does not see . The engine does not always have optimization for mobile devices. If your character is somewhere behind the player’s back, you don’t need to play an animation with him, you don’t need to track his movements, movements of bones. Enough to see where his capsule is. Turn off everything to him, including physics. Moreover, if he is behind you, count him once in 10 ticks, for example.



Cut off the excess . In many games, the abilities laid down in Character are not needed. This is a rather “fat” class, in which there is a lot of logic designed for shooters, for desktop games with a huge number of possibilities, where you can run on the ceiling, jump, make routes, move through physics. Most often we are talking about a character who goes from point A to point B. Write your movement controller, make a steering behavior. This is a task for a high school student, there are a lot of technologies. If you only need movement - just use it and do not need to drag everything else along. This is also one of the things that scares those who come with Unity.



Physics is not easy . Any physical calculations work in a particular thread. If you have 300 different cubes running around the stage - you will have a low FPS. Step two - limit them to groups, and so on.



And one of the most important decisions is Blueprint Nativization . This is a huge breakthrough in engine optimization. If blueprints themselves are 10-30 times slower than the source code. The task of creating blueprints is very extensive, it’s impossible to just turn on the checkbox in the settings. This is a topic for another conversation. But at the very beginning, at least start using nativization, it will give acceleration of blueprints speed by an order of magnitude.



Mobile development issues: rendering



The simplest thing we have already said: use a vertex scan instead of a pixel one. Consider your UV on nodes as Custom UV. No UV modifications on the pixel channel. You can easily make the oceans: 200 with some instructions, and plays well on all projects.



If you transfer all this into pixel shaders, you will have problems. If you take the UV scale, let's say: the ground scale is close with one scale, the scale of the landscape with another is blurred further. Do this on a pixel shader and immediately get a problem. On the vertex too, but not the fact that the player will notice. Because when viewed from the first person, this transition can be hidden by a ladder. Games are fake skills. Never try to get a clean shader, a clean image in each pixel. Use strengths, hide weaknesses.



Control the number of draws, draw calls, calculate visibility in advance . To do this, you need to know your scene, set up groups of objects.



The less skeletal mesh and animation, the faster it all counts. Again, there are distance optimizations that skip frames, they should be used. We wrote our even more rough cutoff, but for mobile games this is justified. Who is interested in a character of 15 pixels? The fact that he has missed three frames of animation and drawing once a second - you need to try to notice this. When you have hot battles, what difference does it have, how many frames per second does this Christmas tree have, 1 or 30?



VFX can be killed by effects , control this moment.



Prototype!



My main advice in mobile development is to make prototypes first.











If you want to make a game with hundreds of characters, create at least a synthetic test . Do not make them unique. Take one model and make one hundred copies. Once we had a hell of a job: we made a hundred different characters. They looked the same, but formally, and most importantly, in terms of memory and rendering, they were different. 20 classes and 100 characters. We tested and understood - does not work. I had to reduce and optimize.



Laying the route and movement: they took 10 character - they slow down. Rewrote the movement, looked, does not slow down - great. Physics, too, check on prototypes. Are you satisfied with how it works? Are you satisfied with the performance? Do not make graphics, paint the ENT, do not need to program everything. Highlight critical parts and prototype them.



What is the future of mobile development?



Today, iOS, thanks to the development of Metal, is the preferred platform for loaded 3D games. This technology greatly optimizes the load on the processor. There is no huge benefit in the frames, mainly reduces energy consumption. By the way, other things being equal, the Unreal Engine loads the processor less than Unity. This is due to the fact that on many devices calculations are transferred to a more energy-efficient GPU.



The future of mobile development is Vulkan. I'm still waiting for him to appear on iOS. On Android, it practically provides desktop graphics capabilities. That only costs screenspace reflexion in real time.





Vulkan is faster, even more optimized, gives more features, allows you to implement on mobile devices a picture at the level of large computers. For example, the last year and a half, artists almost every day ask me: let's add dynamic ambient occlusion. Today this task is not solved in the mobile segment. I hope that with the advent of such technologies, with the advent of new hardware, we will be able to afford, including ambient occlusion.



AFTERWARD



Due to the time elapsed since the compilation of this text, some of the “planned” things managed to become “realized”. So, Lineage 2: Revolution came out into the world, and the Unreal Engine 4.18 introduced the functionality of deskopnogo rendering on iOS (very cool!). Nevertheless, the approaches described do not lose their relevance.



The future is now.



')

Source: https://habr.com/ru/post/345522/

More articles:



All Articles