Unreal vs. Unity: what is the best way to develop mobile games?
Hello, dear readers!
We have translated and are preparing for the release of the book of John Hawking about programming in Unity, which we have already written .
And not so long ago an interesting article about the development of mobile games using Unity (dated August 12, 2015) caught our eye; However, the key advantage of the article is that in it this tool is compared with the main competitor: Unreal Engine.
')
It is with this wonderful study that we invite you to meet on Friday evening. In the comments we will be happy to see recommendations on publishing books about UE, and we also hope for a fruitful discussion.
Article translated with minor abbreviations.
We (the company OnlineFussballManager GmbH) are now starting to develop a new project for mobile devices. We are going to create an exciting and unique combination of turn-based strategy and a game like a football manager.
Players will be able to plan and create their own club grounds and sports complexes, train the team and work on its tactics. Team players will be not just units in numbered T-shirts, but realistic personalities with their own features and even facial expressions. Everything will take place in an isometric view of the various premises and venues of the club, where the animated buildings will be located in a specially defined grid.
So, the moment of truth came when we set about developing a visual presentation.
Considering the requirements set for us and the fact that we have to develop this game for both iOS and Android - how to implement this project technically?
One of the first questions that had to be solved was whether to create our own engine or use the existing one. Of course, the first option is optimal if you want to fully control everything that happens in your source code, toolchain, and also fully understand what your income from this game will be. The disadvantage of this approach is that such development will require considerable effort - because of which the time of the entire project will increase, and it will significantly increase in price. We quickly abandoned this idea because we wanted to keep the cost and timing of the project within a reasonable framework.
Next, it was necessary to decide which engine we would use. There were many options: from Stencyl, GameMaker to Cocos2d and Marmalade and, finally, Unreal and Unity.
Of course, you can bring a lot of arguments about which engine is better and for what purposes. How many people - so many opinions. We have to admit at some point and we have experienced such subjectivity. The team actively supported the Unreal Engine. However, no matter how much we looked at the UE, no one could characterize it objectively, without appealing to personal opinion.
So, we decided not to be distracted from the facts and began to explore other, more well-known tools.
GameMaker was soon rejected because it is more focused on newbies just starting to develop games. Thus, it is quite easy to study it, but GameMaker’s capabilities clearly did not reach what we wanted to do.
Then came the turn of Cocos2D, which at first glance seemed promising. As the name implies, Cocos2D is optimized for the development of two-dimensional games. Therefore, the question arose: do we want to create our isometric grid of buildings in true 2D or in actual 3D with a fixed point of view. After some additional research, we chose the implementation in 3D. In this case, Cocos2D obviously did not suit us.
We turned to Marmalade. After all, with the help of Marmalade such famous games were created as "Plants vs. Zombies "and" Godus ". But, although we found many advantages in this engine, there were problems that forced us to turn to other options. One of the most significant drawbacks was that the Marmalade community was rather small.
So, only Unreal and Unity remained from large alternatives. But even at this point we could not confidently choose one of the two without help.
Fortunately, the GDC gaming conference in San Francisco was approaching, so we took the chance to fly there and consult with colleagues.
We met Epic guys there, got acquainted with Unreal Engine, tried Paper 2D, their tool for viewing mobile apps previews and asked if we could use them: their engine or Unity?
The guys got along with us, saying something like: “Unreal is awesome, but Unity is not bad either. Try both. ”
Then we went to the developers of Unity and looked at Unity 5 - how it improves performance in iOS. In the end, they were asked the same question and received a similar answer.
At this stage, we decided on a thorough technical study. We designed a prototype, quite reminiscent of our project, to test on different mobile devices, how the assembly process will proceed and what the performance will be. At the same time, we also wanted to find out which pitfalls and problems might lie in wait for us when developing on the first and second engines.
Since all our programmers were busy on current projects, we entrusted the work on the prototype to the specialists from Bit Baron.
Research engine, performed in the company Bit Baron
The company "Online Fußball Manager" (OFM) planned to create a mobile game. We were asked for help in order to more confidently decide which engine is best suited for their project. Until then, we were engaged exclusively in the development of browser games, but decided that we would cope with the task. It was proposed to compare two options: Unity and Unreal. Currently, these are two “locomotives” in the world of game programming. There are many reports illustrating in detail the smallest differences between them. But the peculiarity of our work was that we wrote two practically identical test applications for comparison and characterized their indicators in accordance with the system of control points (reference testing).
Having written two similar applications, we were able to test both on a level playing field, tell OFM which version works better and highlight additional problems.
Test case
We wanted to create such a benchmark that would provide OFM with information directly related to the type of game they are creating. Customers indicated that the prototype should have several animated buildings and trees. Therefore, we created a 3D scene where the user was asked to arrange these objects on the map independently. The size of the grid was 11x16; it contained up to 176 buildings. Each grid square supported up to 6 trees, so there could be over 1000 trees in the scene. We added a simple user interface where you could add a specified number of trees and buildings to the scene. Also added the function of adding buildings in specific places - for this you had to click on the map at the desired point. As for the organization of the program, we built a grid on a plane, and the scene viewing was done through a camera located “above the head” of the user. We also added special camera features to allow the user to zoom in and pan the scene. Since this prototype was created to determine the engine for development, we did our best to make the scene look almost the same in both versions. Otherwise it would be impossible to compare the visual quality of the first and second options. For this it was necessary to tinker, since some things are handled in Unreal and in Unity differently. As a result, we have two very similar scenes.
To unify performance testing, we wanted to use identical models of trees and buildings in both systems. For the trees, the mobile model SpeedTree was used, which included just about 1000 polygons and made it possible to well assess how small increments in the displayed triangles affect the frame frequency. As for animated buildings, we could not find a model for them that would work with both engines, so we used two different models. Both were calculated for just over 16,000 polygons each, they had almost identical material settings. We have completely turned off the levels of detail (LOD) so that in both cases the same number of triangles are displayed at any distance from the camera. The test was designed not only to reflect the differences in performance between the two engines, but also to show the difference in rendering quality. In addition, it was necessary to closely monitor the standard shaders Unreal Engine. Noticing that Unreal looks clearly better, we found that the camera has a number of shaders, costly in terms of performance. After they were turned off, the scene was visually almost unchanged. Lighting was a completely different problem, so it took us some time to bring it to mind.
Customers were interested not only in rendering tests, but also in what impressions of the development on the first and second engines. In the end, what's the point of performance, if you do not have time to write a game in a timely manner. To delineate these impressions, we compared factors such as the duration of the assembly, the documentation available, the complexity of deployment in a mobile environment, and the complexity of code iterations. We figured that it was for these indicators that Unity would be stronger (as a flagship in the development of mobile games).
Unity project
Prototype in Unity. There are 200 trees on the map
Good
The bad
This is a picture from the Unity editor. We were very lucky that we were able to supplement it with our own scripts.
Terrible
The frame rates of 37 vs. 32. In the Unity statistics panel, we see estimated data for a stand-alone application that does not match the real ones.
Unreal project
This is how the project looks in Unreal editor. There are many specialized nested editors here, some of which are comparable in functionality to entire programs.
The UE made the same screen shot, QC and Unity (see above), with mobile settings left by default, without lighting trees
When the settings were adjusted, the trees turned out better, but still not as good as in Unity
Good
Drawings are excellent at solving simple problems, their integration with C ++ is fantastic. But if more complex logic is involved, then they quickly get into a mess, and it becomes difficult to deal with them.
The bad
Terrible
The results of benchmarking. Frame rate
Surprisingly, when testing the frame rate (FPS) on different devices, we got very different results. On some devices, Unity won in any configuration. In other cases, Unreal decorated Unity in those tests where there were many buildings. In principle, Unreal won, but at a high price. Image quality and consistency in Unity were significantly better. Unreal textures on some devices looked vague, the trees were much worse. The difference in quality was due in part to what is displayed on the one hand in the Unreal editor and the mobile preview, and on the other on the real mobile phone. This problem was especially obvious when it comes to stage lighting. It was very difficult to choose the settings to properly adjust the light, the whole setting on mobile devices often looked dark. In this regard, Unity was much more consistent, the image on any smartphones was the same as in the preview in the editor.
The results for both engines turned out to be much better than we expected (as you remember, in our test models there were about 10 times more triangles than in normal mobile games).
In iOS, both engines displayed animated models with about the same success. However, tests with trees on this device were unsuccessful, because Unreal did not display any textures on tree models. We tried to find the cause of this model, but could not solve it. In addition, it should be noted that when deploying using these engines, you should have an Apple computer at your fingertips. This is very inconvenient, but Apple itself is to blame for this situation. Customers also asked us to perform benchmarking on Windows Phone. Unfortunately, Unreal does not yet support deployments on a Windows phone, so here Unity won by definition. Since while Windows Phone occupies a very small market share, the development of Unreal in this direction is not considered a priority.
Ultimately, benchmarking only showed that the two engines are almost equal in strength. Therefore, it is especially important to pay attention to the specific advantages and disadvantages of each of them. In the end, if the performance is so close, then the convenience and speed of development for each of these engines comes to the fore.
Other control parameters
Here are some interesting results that we managed to figure out during our tests:
findings
According to the study, we liked a lot in both engines. In addition, we found many areas where these tools can be improved to make it easier for the programmer to work. None of the engines had a significant advantage over the other, given how quickly their capabilities and support are changing. The testing of rendering showed that both products squeeze the maximum out of the device and, in principle, are quite comparable. Again, in this situation, usability and intuitive development are at the forefront. Considering everything that we learned about these engines, and what problems we encountered during development, we were faced with a difficult choice, but in the end we preferred Unity.
Despite the fact that initially we were betting on the Unreal Engine win, at the present time Unity is still a better option, at least, if we talk about the development of mobile games.
Here are the main reasons for our decision:
We would like to emphasize that our results should be regarded in the context of the prototype made. What is suitable for one company is not suitable for another. In addition, there are many more game engines, some of which may better fit your specific task. In some companies with sufficient time and resources, it will be better to even write your own engine. There is no universal solution to game development. Do yourself a favor and experiment as it should. Moreover, many of them are cheaper or even become conditionally free as Unreal. We would not be surprised if Unity also follows the example of Unreal and liberalizes the pricing model.
Conclusion
It is interesting to note that the guys from Bit Barons, before creating the prototype, advised us to take the Unreal Engine for our project. Considering that we, at OFM, initially preferred the Unreal Engine, it is possible that the final solution turned out to be suboptimal.
Of course, it is not easy to design, write and test a prototype, especially if you just need to decide on the engine for the project. But the question of such a choice is crucial.
Finally, we took into account some more factors that could change our opinion. Namely: how easy is it to find experienced specialists for each engine at present, and what are the available business models?
On the personnel issue, we consulted with experienced recruiters to find out more or less real numbers. Currently, there are about four Unity professionals for each Unreal specialist. As for the business model, Unreal does not provide for an initial fixed contribution, but requires license fees. In Unity, everything is exactly the opposite. Both of these factors were important to us, and as a result, we still stopped at Unity.
We have translated and are preparing for the release of the book of John Hawking about programming in Unity, which we have already written .
And not so long ago an interesting article about the development of mobile games using Unity (dated August 12, 2015) caught our eye; However, the key advantage of the article is that in it this tool is compared with the main competitor: Unreal Engine.
')
It is with this wonderful study that we invite you to meet on Friday evening. In the comments we will be happy to see recommendations on publishing books about UE, and we also hope for a fruitful discussion.
Article translated with minor abbreviations.
We (the company OnlineFussballManager GmbH) are now starting to develop a new project for mobile devices. We are going to create an exciting and unique combination of turn-based strategy and a game like a football manager.
Players will be able to plan and create their own club grounds and sports complexes, train the team and work on its tactics. Team players will be not just units in numbered T-shirts, but realistic personalities with their own features and even facial expressions. Everything will take place in an isometric view of the various premises and venues of the club, where the animated buildings will be located in a specially defined grid.
So, the moment of truth came when we set about developing a visual presentation.
Considering the requirements set for us and the fact that we have to develop this game for both iOS and Android - how to implement this project technically?
One of the first questions that had to be solved was whether to create our own engine or use the existing one. Of course, the first option is optimal if you want to fully control everything that happens in your source code, toolchain, and also fully understand what your income from this game will be. The disadvantage of this approach is that such development will require considerable effort - because of which the time of the entire project will increase, and it will significantly increase in price. We quickly abandoned this idea because we wanted to keep the cost and timing of the project within a reasonable framework.
Next, it was necessary to decide which engine we would use. There were many options: from Stencyl, GameMaker to Cocos2d and Marmalade and, finally, Unreal and Unity.
Of course, you can bring a lot of arguments about which engine is better and for what purposes. How many people - so many opinions. We have to admit at some point and we have experienced such subjectivity. The team actively supported the Unreal Engine. However, no matter how much we looked at the UE, no one could characterize it objectively, without appealing to personal opinion.
So, we decided not to be distracted from the facts and began to explore other, more well-known tools.
GameMaker was soon rejected because it is more focused on newbies just starting to develop games. Thus, it is quite easy to study it, but GameMaker’s capabilities clearly did not reach what we wanted to do.
Then came the turn of Cocos2D, which at first glance seemed promising. As the name implies, Cocos2D is optimized for the development of two-dimensional games. Therefore, the question arose: do we want to create our isometric grid of buildings in true 2D or in actual 3D with a fixed point of view. After some additional research, we chose the implementation in 3D. In this case, Cocos2D obviously did not suit us.
We turned to Marmalade. After all, with the help of Marmalade such famous games were created as "Plants vs. Zombies "and" Godus ". But, although we found many advantages in this engine, there were problems that forced us to turn to other options. One of the most significant drawbacks was that the Marmalade community was rather small.
So, only Unreal and Unity remained from large alternatives. But even at this point we could not confidently choose one of the two without help.
Fortunately, the GDC gaming conference in San Francisco was approaching, so we took the chance to fly there and consult with colleagues.
We met Epic guys there, got acquainted with Unreal Engine, tried Paper 2D, their tool for viewing mobile apps previews and asked if we could use them: their engine or Unity?
The guys got along with us, saying something like: “Unreal is awesome, but Unity is not bad either. Try both. ”
Then we went to the developers of Unity and looked at Unity 5 - how it improves performance in iOS. In the end, they were asked the same question and received a similar answer.
At this stage, we decided on a thorough technical study. We designed a prototype, quite reminiscent of our project, to test on different mobile devices, how the assembly process will proceed and what the performance will be. At the same time, we also wanted to find out which pitfalls and problems might lie in wait for us when developing on the first and second engines.
Since all our programmers were busy on current projects, we entrusted the work on the prototype to the specialists from Bit Baron.
Research engine, performed in the company Bit Baron
The company "Online Fußball Manager" (OFM) planned to create a mobile game. We were asked for help in order to more confidently decide which engine is best suited for their project. Until then, we were engaged exclusively in the development of browser games, but decided that we would cope with the task. It was proposed to compare two options: Unity and Unreal. Currently, these are two “locomotives” in the world of game programming. There are many reports illustrating in detail the smallest differences between them. But the peculiarity of our work was that we wrote two practically identical test applications for comparison and characterized their indicators in accordance with the system of control points (reference testing).
Having written two similar applications, we were able to test both on a level playing field, tell OFM which version works better and highlight additional problems.
Test case
We wanted to create such a benchmark that would provide OFM with information directly related to the type of game they are creating. Customers indicated that the prototype should have several animated buildings and trees. Therefore, we created a 3D scene where the user was asked to arrange these objects on the map independently. The size of the grid was 11x16; it contained up to 176 buildings. Each grid square supported up to 6 trees, so there could be over 1000 trees in the scene. We added a simple user interface where you could add a specified number of trees and buildings to the scene. Also added the function of adding buildings in specific places - for this you had to click on the map at the desired point. As for the organization of the program, we built a grid on a plane, and the scene viewing was done through a camera located “above the head” of the user. We also added special camera features to allow the user to zoom in and pan the scene. Since this prototype was created to determine the engine for development, we did our best to make the scene look almost the same in both versions. Otherwise it would be impossible to compare the visual quality of the first and second options. For this it was necessary to tinker, since some things are handled in Unreal and in Unity differently. As a result, we have two very similar scenes.
To unify performance testing, we wanted to use identical models of trees and buildings in both systems. For the trees, the mobile model SpeedTree was used, which included just about 1000 polygons and made it possible to well assess how small increments in the displayed triangles affect the frame frequency. As for animated buildings, we could not find a model for them that would work with both engines, so we used two different models. Both were calculated for just over 16,000 polygons each, they had almost identical material settings. We have completely turned off the levels of detail (LOD) so that in both cases the same number of triangles are displayed at any distance from the camera. The test was designed not only to reflect the differences in performance between the two engines, but also to show the difference in rendering quality. In addition, it was necessary to closely monitor the standard shaders Unreal Engine. Noticing that Unreal looks clearly better, we found that the camera has a number of shaders, costly in terms of performance. After they were turned off, the scene was visually almost unchanged. Lighting was a completely different problem, so it took us some time to bring it to mind.
Customers were interested not only in rendering tests, but also in what impressions of the development on the first and second engines. In the end, what's the point of performance, if you do not have time to write a game in a timely manner. To delineate these impressions, we compared factors such as the duration of the assembly, the documentation available, the complexity of deployment in a mobile environment, and the complexity of code iterations. We figured that it was for these indicators that Unity would be stronger (as a flagship in the development of mobile games).
Unity project
Prototype in Unity. There are 200 trees on the map
Good
- The main elements of Unity are objects ("GameObject") and components ("MonoBehaviour"). Having mastered this concept, you can already work with Unity. If properly used this system, it can significantly improve the organization of the project.
- Unity includes many components that provide you with everything you need to create a game - except for game logic itself. As mentioned above, the component can be as small as Plane (not in Unreal), which we used to create the grid. The latest additions to the engine are the “UI” and “Layout” components, which provide powerful and scalable graphical user interfaces.
- The editor can be extended with your own scripts, in addition, the Asset Store has plenty of resources available for all occasions. The Asset Store also contains a lot of useful scenarios, material models, etc. They will be especially useful when prototyping - you can simply load everything you need in the form of temporary resources and use this as improvised imitation models.
- Unity was one of the first publicly available engines to support mobile development. Therefore, it is very convenient when deployed in a mobile environment, it looks and acts there almost the same way as in the editor. The system is constantly being improved, and deployment is very smooth. This was a significant factor due to which we decided to make a mobile prototype.
- Perhaps, Unity boasts the widest community of experts among all game engines, so if you have a question - most likely, there will be an answer to it. Let Unity support many scripting languages, the documentation for each one is very solid. Moreover, even if you find an answer for another language, the logic of this answer will nevertheless be clear to you, and you can adapt it to solve your problem.
- In Unity, a lot of work has been done on optimizing rendering for a variety of objects of the same type. To achieve comparable performance in Unreal, Instanced Rendering would have to be used, and this mechanism is usually less flexible than rendering in Unity.
The bad
- The source code of the engine is closed. If you discuss the price of source code with Unity, then you will have to accept it. Therefore, problems are possible if one or another opportunity on which you rely fails - you will have to wait for the update.
- The new UI system is quite good. There is no special editor in it, all changes are made right in the scene - and the scene is very big. When you open the scene and want to edit the UI, you first have to considerably increase the scale of the area of ​​interest.
This is a picture from the Unity editor. We were very lucky that we were able to supplement it with our own scripts.
Terrible
- There are two problems with the new UI system in Unity. When you tap your finger on the touch screen, you cannot determine whether a particular graphic element was pressed. Suppose a user wants to pan the screen with a slider. But if we inherit the GraphicsRaycaster class, then we can open any desired data that can be made publicly available. If you replace the GraphicsRaycaster in the canvas object, then you can check whether the UI element was pressed.
- The second problem with the Unity user interface is related to scaling for displays of various sizes. In principle, the canvas object has scaling options with some parameters. But it was very difficult to organize their preview, we had to deploy the application several times on the device until we picked up the normal configuration.
- In addition, we are very puzzled statistical panel Unity. Having implemented the in-game frame rate counter, we compared its value with what was displayed on the statistical panel of the Unity editor. These values ​​differed. Looking on the Internet for other implementations, we found the answer: the statistical panel gives an estimate of how many frames the game would have spent working autonomously, and not in the editor. Therefore, the logic of our frame counter was absolutely correct.
The frame rates of 37 vs. 32. In the Unity statistics panel, we see estimated data for a stand-alone application that does not match the real ones.
Unreal project
This is how the project looks in Unreal editor. There are many specialized nested editors here, some of which are comparable in functionality to entire programs.
The UE made the same screen shot, QC and Unity (see above), with mobile settings left by default, without lighting trees
When the settings were adjusted, the trees turned out better, but still not as good as in Unity
Good
- The trial version of Unreal is completely free. In it, you get a full-featured editor. Unity also has a free version, but switching to Pro will cost you a tidy sum.
- In Unreal, there is a powerful editor that contains several highly specialized editors. If you are familiar with these “nested” editors, they will greatly assist you in the development, and often provide such information that you will not see in Unity. There are editors who can even serve as a full replacement for some programs. The interaction of all these subsystems is simply a masterpiece.
- The engine comes with all the source code. Therefore, it is possible to delve into it and understand how individual parts function. Moreover, you can even fix bugs in the engine or independently supplement its functionality.
- Visualization in the editor is great. It’s just the eyes that run away from the abundance of rendering options (associated, for example, with lighting or with the complexity of the shaders). Here you will find a lot of ultramodern shaders, which also come with the engine. In principle, Unreal offers the best rendering engine on the market. You can create amazingly beautiful scenes.
- Blueprints are convenient to quickly create something simple and implement the basic game logic. They are perfectly integrated with C ++, and this decision was not accidental: it not only opens up tremendous opportunities for both beginners and experienced developers, but also allows them to interact with each other.
- The overall integration with C ++ is great. Like a hot reboot.
Drawings are excellent at solving simple problems, their integration with C ++ is fantastic. But if more complex logic is involved, then they quickly get into a mess, and it becomes difficult to deal with them.
The bad
- When developing on the Unreal Engine is difficult to pick up the pace. Even if you know C ++ well, it will take a lot of time to learn the various macros and functions of UE4. This can be very difficult for those who are simultaneously studying C ++.
- In the drawings you can get confused very quickly. When the logic includes dozens of nodes, each of which contains a drawing, it can sometimes be simplified to a couple of lines of code written in ordinary C ++. This is usually not a problem, since it is quite possible to work with C ++, but with some things, for example, “UMG” (UI system), it is necessary to use drawings, therefore confusion is possible.
- Mobile simulator was very inconsistent. He issued warnings when we tried to use shader functions that were not used in a mobile environment, but even if the shader was validated, it could not work. In principle, this simulator is a good thing, but its visual qualities leave much to be desired.
- Although Unreal has a large developer community, we rarely got answers to questions there. In addition, almost all support provided to us concerned the drawings. Unreal Engine 4 is actively building up the community, this is already working out well, it seems that specialists are striving to develop and help. But the Unity community is still better.
Terrible
- There is a serious lack of C ++ documentation. Online C ++ reference material is inconvenient. In addition, due to constant updates, many features quickly become obsolete. Be careful when viewing reference videos, as there may be described an irrelevant version of the engine and functions that are no longer used.
- Working with the GUI, we used the innovative system "UMG". It is based on drawings and can be very useful. Having worked a bit, we managed to inherit the C ++ class and put things in order with the drawings a little. However, the system is still raw, it lacks some controls, for example, push buttons. In addition, the corresponding C ++ documentation is almost non-existent. The editor fell off several times while we were developing the UI. Unexpected failures can cost entire working hours, they are pretty unnerving. The development of this system continues, but so far it is far from perfect.
- Mobile development with Unreal is slow. The program is deployed on the device for a very long time. In Android, there were some visual problems - for example, there were vague outlines and unlit trees. In iOS, the problems were much more serious. UE4 only supports assembly for an iOS device, provided that your application consists only of drawings. It’s Apple’s fault, but we’ve come all the way through importing development keys (you can imagine) before we ran into this problem. In iOS, the textures of trees built on the basis of SpeedTree were not displayed, the trees were gray and bare, without leaves. So, support of mobile development in Unity essentially wins in comparison with Unreal.
The results of benchmarking. Frame rate
Surprisingly, when testing the frame rate (FPS) on different devices, we got very different results. On some devices, Unity won in any configuration. In other cases, Unreal decorated Unity in those tests where there were many buildings. In principle, Unreal won, but at a high price. Image quality and consistency in Unity were significantly better. Unreal textures on some devices looked vague, the trees were much worse. The difference in quality was due in part to what is displayed on the one hand in the Unreal editor and the mobile preview, and on the other on the real mobile phone. This problem was especially obvious when it comes to stage lighting. It was very difficult to choose the settings to properly adjust the light, the whole setting on mobile devices often looked dark. In this regard, Unity was much more consistent, the image on any smartphones was the same as in the preview in the editor.
The results for both engines turned out to be much better than we expected (as you remember, in our test models there were about 10 times more triangles than in normal mobile games).
In iOS, both engines displayed animated models with about the same success. However, tests with trees on this device were unsuccessful, because Unreal did not display any textures on tree models. We tried to find the cause of this model, but could not solve it. In addition, it should be noted that when deploying using these engines, you should have an Apple computer at your fingertips. This is very inconvenient, but Apple itself is to blame for this situation. Customers also asked us to perform benchmarking on Windows Phone. Unfortunately, Unreal does not yet support deployments on a Windows phone, so here Unity won by definition. Since while Windows Phone occupies a very small market share, the development of Unreal in this direction is not considered a priority.
Ultimately, benchmarking only showed that the two engines are almost equal in strength. Therefore, it is especially important to pay attention to the specific advantages and disadvantages of each of them. In the end, if the performance is so close, then the convenience and speed of development for each of these engines comes to the fore.
Other control parameters
Here are some interesting results that we managed to figure out during our tests:
- Both engines almost did not differ in memory consumption. On devices with Android, Unity won a little, on devices with iOS it was Unreal.
- The Unity project is much smaller (Android: 42 MB / iOS: 100 MB) than Unreal (Android: 101 MB / iOS: 173 MB).
- Unity is about three times faster on the device. In addition, the code is compiled much faster in Unity.
- Unreal consumed battery much more economically. After two hours of work with 150 animated models on the screen, Unreal managed to discharge the Android battery by 42 percent and iOS - by 36 percent. Unity consumed about 72 percent on Android and 47 percent on iOS with the same setting and runtime.
findings
According to the study, we liked a lot in both engines. In addition, we found many areas where these tools can be improved to make it easier for the programmer to work. None of the engines had a significant advantage over the other, given how quickly their capabilities and support are changing. The testing of rendering showed that both products squeeze the maximum out of the device and, in principle, are quite comparable. Again, in this situation, usability and intuitive development are at the forefront. Considering everything that we learned about these engines, and what problems we encountered during development, we were faced with a difficult choice, but in the end we preferred Unity.
Despite the fact that initially we were betting on the Unreal Engine win, at the present time Unity is still a better option, at least, if we talk about the development of mobile games.
Here are the main reasons for our decision:
- Unity visually looks more consistent on all devices, moreover, it is quickly deployed "with one click" on any platform.
- Unity takes up much less space on the device, less impact on the end user. The compact size is especially important in the Google Play Store, where the APK has to be divided into parts, if this file is larger than 50mb.
- Unity is much easier to learn and understand. Armed with Unity, an inexperienced user can get to work faster and create products that are supported by a large community of specialists.
- The iteration duration in Unity is much less (deploying and compiling source code is faster, shaders are compiled almost instantly)
We would like to emphasize that our results should be regarded in the context of the prototype made. What is suitable for one company is not suitable for another. In addition, there are many more game engines, some of which may better fit your specific task. In some companies with sufficient time and resources, it will be better to even write your own engine. There is no universal solution to game development. Do yourself a favor and experiment as it should. Moreover, many of them are cheaper or even become conditionally free as Unreal. We would not be surprised if Unity also follows the example of Unreal and liberalizes the pricing model.
Conclusion
It is interesting to note that the guys from Bit Barons, before creating the prototype, advised us to take the Unreal Engine for our project. Considering that we, at OFM, initially preferred the Unreal Engine, it is possible that the final solution turned out to be suboptimal.
Of course, it is not easy to design, write and test a prototype, especially if you just need to decide on the engine for the project. But the question of such a choice is crucial.
Finally, we took into account some more factors that could change our opinion. Namely: how easy is it to find experienced specialists for each engine at present, and what are the available business models?
On the personnel issue, we consulted with experienced recruiters to find out more or less real numbers. Currently, there are about four Unity professionals for each Unreal specialist. As for the business model, Unreal does not provide for an initial fixed contribution, but requires license fees. In Unity, everything is exactly the opposite. Both of these factors were important to us, and as a result, we still stopped at Unity.
Source: https://habr.com/ru/post/269415/
All Articles