Mobile VR-game on the Unreal Engine: pitfalls
Recently, virtual reality technology has become increasingly popular. And along with the popularization of VR, more developers are starting to make VR games. At the same time, those rakes that can be stepped on when developing your VR games often differ from the rakes in conventional mobile development. Under the cut, you will find a detailed story about the pitfalls that the developer of a mobile VR game on the Unreal Engine 4 may encounter. Internet projects ”and together with the FurecoVR company.
Before you start any mobile development, you need to decide on basic things. In particular, create a concept, vision and other game design documentation for your project. I will not now focus on this topic - read more in another article on Habré from the teacher of the course “Project documentation” of the program “Management of online gaming projects”.
If we talk about our 2048 VR game quite briefly, then we set ourselves the goal of testing the development and launch of a VR game exclusively. In this regard, it was necessary to choose a simple and fast-to-develop mechanic, which however would be interesting for us, and also had the potential to appeal to the audience and gain user base without marketing investments. Although we do not embed monetization in this game, it will be useful for our future VR projects to have a user base of our VR game. After all, as you know, the marketing of VR games on mobile devices is now a separate song, and apart from transferring players from one VR game to another, there is no way to send targeted traffic to people who own VR glasses.
')
So, based on these goals, it was decided to port the well-known and simple mechanics to VR. Known to use the organic base to install. Simple, so that the development was fast. Our solution in this case was a clone of the well-known mobile game 2048, but transferred to VR format using 3D graphics. Controlling the game field is different from the original game in that the numbers on the field are not shifted with a swipe of a finger, but with head movements left / right, up / down. It was probably inspired by the fact that a friend in one of clones 2048 (not VR of course) without marketing injections had more than 1.5 million installations from the world, and even monetized well.
So, a simple and potentially popular mechanic is chosen. Concept and vision we wrote. It's time to develop.
We went over a few ideas on how exactly the game field will be managed. At first they wanted to use the side button on the helmet to confirm the action of the field bias, but quickly realized that it was too tiring for both the hand and the whole. Then they wanted to use the Bluetooth remote control, but they also quickly refused, because The device, though convenient, is extremely poorly distributed, which means we will not have an audience.
So we came to the simplest and most obvious decision - to track head gestures. While tracking gestures - it says loudly. In fact, we track the turns of the game camera. When the center of the screen goes beyond a certain “safe” zone on the playing field, we consider that the player intends to make a gesture, and depending on where in the center of the screen crossed the border of the safe zone, we decide in which direction the player wants to move the field. (left / right / down / up).
Of course, there is one drawback: if a player wants to just look around, the game will still react and the numbers on the field will shift as with a normal gesture. So you can freely turn your head, though it is possible, but not without consequences for the game results. We decided that this is a one-time event and in general it is not scary.
Remember, at first we estimated the development estimate for Unity and Unreal? So, the development on Unreal cost us no less, and even more. The main reason for this overkill emerged, initially, because of the fight against the SDK, and then, because of the fight against the publishing of the iOS version.
If you ask us, would we again undertake to make a mobile VR game on Unreal, going through all this? If done exclusively under Android 5+, then, probably, yes. Otherwise, no. The team made such an application on Unity for several evenings, and did not worry about the SDK, focusing on the functionality, although the developer managed much more expensive, but less nerves and a faster result.
What is UE suitable for? If you are doing a VR project on a PC, or NOT a VR project for mobile phones, then the UE is an excellent choice for a number of reasons, which we will not delay now, since The article is not about that. But for a mobile VR, it is not yet ready. However, for sure, with updates, mobile VR support will improve.
As for the direction of VR development as a whole, I myself personally believe that virtual reality will ignite already by 2020 and will bring good revenue to VR developers. Therefore, those who are now starting their experiments or conducting research on this technology, in my subjective opinion, have great chances to get their profit a hundredfold by 2020. And I hope that the article will help those who are now dropping into this as yet only picking up course of the VR locomotive.
Separate, thanks for the help in developing the application and writing the article for the FurecoVR team: Evgeny Filchenko and Dmitry Kostyukevich.
And thanks for advising Kallist and Eligar
Here are the links to the game:
iOS: https://itunes.apple.com/ru/app/2048/id1109740917
Android: https://play.google.com/store/apps/details?id=com.antarex.vr2048
I will be glad to answer your questions and discuss the prospects of mobile VR in the comments!
Before you start any mobile development, you need to decide on basic things. In particular, create a concept, vision and other game design documentation for your project. I will not now focus on this topic - read more in another article on Habré from the teacher of the course “Project documentation” of the program “Management of online gaming projects”.
Let's start with goal setting and selection of development tools.
If we talk about our 2048 VR game quite briefly, then we set ourselves the goal of testing the development and launch of a VR game exclusively. In this regard, it was necessary to choose a simple and fast-to-develop mechanic, which however would be interesting for us, and also had the potential to appeal to the audience and gain user base without marketing investments. Although we do not embed monetization in this game, it will be useful for our future VR projects to have a user base of our VR game. After all, as you know, the marketing of VR games on mobile devices is now a separate song, and apart from transferring players from one VR game to another, there is no way to send targeted traffic to people who own VR glasses.
')
So, based on these goals, it was decided to port the well-known and simple mechanics to VR. Known to use the organic base to install. Simple, so that the development was fast. Our solution in this case was a clone of the well-known mobile game 2048, but transferred to VR format using 3D graphics. Controlling the game field is different from the original game in that the numbers on the field are not shifted with a swipe of a finger, but with head movements left / right, up / down. It was probably inspired by the fact that a friend in one of clones 2048 (not VR of course) without marketing injections had more than 1.5 million installations from the world, and even monetized well.
So, a simple and potentially popular mechanic is chosen. Concept and vision we wrote. It's time to develop.
A few words about the choice of engine. Why exactly Unreal Engine 4 (further UE)?
- VR support . UE was one of the first to announce official support for VR. The fact that in fact it did not help us, we will tell further.
- A set of free assets . Assets are a set of standard models with customized materials that come with the engine. Since we did not have a budget for creating a unique environment, and for our purposes this was not necessary, the availability of high-quality standard assets allowed us to save a lot of time and money.
- Good render out of the box . The UE has a quality render, which produces a decent picture without any special tambourine tricks, if there are well-tuned materials on the models. And since we used assets provided by the UE itself, we easily got a decent picture.
- Price issue . We had the opportunity to do everything on Unity or on the UE, and we just gave a task to evaluate both specialists. The evaluation of development on Unity was 3 times higher, and having no doubts about UE at that time, we decided not to overpay. I’ll clarify that for the price it was in our team at that time that the work of the available specialist on Unity was more expensive than the specialist’s work on the UE.
Something about core mechanics
We went over a few ideas on how exactly the game field will be managed. At first they wanted to use the side button on the helmet to confirm the action of the field bias, but quickly realized that it was too tiring for both the hand and the whole. Then they wanted to use the Bluetooth remote control, but they also quickly refused, because The device, though convenient, is extremely poorly distributed, which means we will not have an audience.
So we came to the simplest and most obvious decision - to track head gestures. While tracking gestures - it says loudly. In fact, we track the turns of the game camera. When the center of the screen goes beyond a certain “safe” zone on the playing field, we consider that the player intends to make a gesture, and depending on where in the center of the screen crossed the border of the safe zone, we decide in which direction the player wants to move the field. (left / right / down / up).
Of course, there is one drawback: if a player wants to just look around, the game will still react and the numbers on the field will shift as with a normal gesture. So you can freely turn your head, though it is possible, but not without consequences for the game results. We decided that this is a one-time event and in general it is not scary.
Now about the pitfalls of the development of Unreal Engine 4
- Mobile VR is not supported . It quickly turned out that when the UE talked about supporting VR, it was only about the SDK for Sumsung Gear VR, Oculus Rift and Steam VR (aka HTC Vive). As it turned out, there was no official SDK for Google Cardboard and other mobile glasses. But there was an SDK, developed and shared by Nival, which was launched under Cardboard and only on version 4.10 of the engine. We, determined to work with him .
- No correspondence of head gestures to camera turns . One of the first problems we encountered was that the player turns his head horizontally to the right, and instead, the camera rises. Or the player lowers his head down and the camera turns clockwise. Those. Axes and controls are confused. The Nival SDK was apparently designed only for the android device, and everything worked as it should for them. But on the iPhone, when switching the orientation from portrait to landscape Pitch, Yaw and Roll did not switch. At the same time, depending on whether we have the right landscape orientation or the left, they had to switch differently. The solution was to select only one orientation (used only Landscape Left Orientation) and remove the direct camera control from the HMD. The orientation of the device only affected the controller, we received its orientation for the camera and changed it: Roll to Yaw, Pitch to Roll and Yaw to Pitch.
- Blocking free flip phone . When we overcame the problem with the axes, it turned out that if we turn the phone over and try to control the field, then the axes will again become confused. The solution to this problem could take extra time, so we decided to just block the image flipping, and when loading to display a picture that would show how to properly hold the phone .
- Duplication and layering of text fields . We have over the playing field displays points for combining cells with numbers. Each time a player made a new union, the number of points above the field was not replaced with a new one, but overlapped with a new value. And this could be repeated to infinity. The correction took about 2 days. As it turned out, it was a mistake in the engine itself. It consisted in the fact that on 3D widgets when building on a device, the rendered text was never removed from the widget. This error was safely fixed in the 4.11 version of the engine, but we could not use it, since Nival did not patch its plugin. It was necessary to re-create the entire widget with every change of the account .
- Under-cross-platform . It was not possible to develop a single cross-platform build that could be easily built on iOS or Android. We had to lead and maintain 2 separate builds for each of the axes. At the same time, creating and testing a project on two platforms turned out to be a bad idea, since the SDK for Android and iOS worked differently and the build requirements for Android and iOS are different. The solution was to duplicate the project and focus on developing a game for one platform, and then for another .
- Wrong starting position of the head when starting the application . When launching, the user did not align the horizon line in the application, i.e. when a player clicks on the application icon on the desktop, then the download takes place, and this is where the phone was at the moment the download was completed, this position was considered to be original, and then all the offsets were calculated from this point. This led to the fact that if a person launched the application while holding the phone in their hands so that, for example, the phone’s camera was aimed at the floor, then after downloading the application, when the person had already inserted the phone into the helmet, the person tried to look straight ahead, the game camera looked instead somewhere up. As it turned out, this problem cannot be fixed in adequate time, because This decision lies on the side of the SDK. Therefore, all that was in our power is to add a picture when the application is loaded, that when starting the application, the player must place the phone with glasses immediately, while the application has not yet fully loaded. We were able to solve this problem only with the release of the official SDK for Google VR in version 4.12, but more on that later .
- Accumulated offset . In the process of testing, they began to notice that the longer you play, the further the center of the camera moves somewhere to the side. It could have gone so far that the camera was so lowered down that the player rested his chin on the chest while trying to make the next field shift down. Most likely, this bug also came from the Nival SDK, since In similar VR-developed applications on Unity, this problem was not noticed, and with the release of UE 4.12 update, this bug was also not reproduced .
- Logos on download . As in most mobile applications, in the process of downloading the game, we put our logos. But the fact is that the UE now, in principle, does not have such a way to insert a picture or video for download so that it is displayed in the VR format, so the logos are shown as flat, as in a normal non-VR application. This is because the standard way to install the boot image displays the image before the game is downloaded directly in VR format. And if we move the logos inside the game and display it to show it in VR format, then the player will not understand at first what the game will look like while the game is really loading, and when the game is loaded, they will still watch the video with our logos, which in general will delay the entry moment in Game. Therefore, in one of the versions, we turned off the video with logos altogether .
- Weight of the application . Our first builds weighed about 370 mb. And this is the weight of a simple one-play game! Obviously, the UE has by default packed a lot of its libraries in the build, which, most likely, were not used in our application. As it turned out, the standard Unreal Engine 4 is a lot of plug-ins connected. Therefore, we have disabled everything that we did not need: 2D graphics plugins, Android support in the iOS version and vice versa, and the like. But here you need to be cautious and do not turn off the excess. As a result, the Android version has decreased to 87 MB, and iOS to 182 MB.
- Problems with creating iOS build with certificate for publishing . From the very beginning, we faced the problem of building a build for iOS. Since we didn’t have a Mac device at hand, we had to raise a virtual machine with a Mac and configure the Unreal Remote Tool (to tell how to do this, you need to write a separate article). When we began to release the iOS version, and tried to supplement the build with a certificate for publishing, the AppStore did not accept the application in any way. We spent about 30 hours searching for a solution, and, in desperation, asked for help in support of the UE. Fortunately, thanks to Alexey Savchenko, the question was processed quickly. It turned out that we are working on the only version of UE 4.10, which has a bug with creating publishing builds for iOS, in previous and next versions there is no problem. Here is this luck! Actually the problem was that the build compiled by the engine was not properly “signed”. Because of this, the assembled build had to be unpacked, re-signed and re-built .
- UE update and official SDK Cardboard support . And on that very day, when we finished our sprint on a rake, we overcame some problems, reluctantly, reconciled with some, Google announces a new platform Daydream, and right there the UE rolls out an update that supports this platform, and at the same time and Cardboard. Thus, a normal SDK for mobiles appears in the UE. Without hesitation, we decide to try out this SDK. On the test scene, we see that the problems we have struggled with for so long are not. But then the bad news also turns out - the SDK only supports Android devices. OK! Let us decide at least on Android, and begin the process of transferring the game to the new SDK. It takes us about 2 days. As a result, we get a build in which all the problems from the list above are solved. Hooray! Or not? Not really. First, some problems still arose, although they were reproduced only on separate devices. For example, on one Chinese device there was a noise similar to the one that appears when the TV signal is bad. In addition to this, they began to podlyuchivat little materials (material crawled from one object and partially clasped on another). As well as the VR image looked defocused, it doubled in the eyes. However, the bug was not repeated on modern branded phones like the Samsung S6, so it's difficult to assess the coverage of the problem. But the critical problem for us was that the new SDK did not build Android builds below version 5 at all, although before that we started the application on 4.1+. After examining the analyst, we found out that about 43% of devices work on Android 5+, which turned out to be below the critical level for us. We wanted to support at least 80% of devices. After weighing all the pros and cons, we decided to postpone the release of the version on the new SDK, in favor of the old one, and when the coverage of devices on Android 5+ increases, we update the application.
findings
Remember, at first we estimated the development estimate for Unity and Unreal? So, the development on Unreal cost us no less, and even more. The main reason for this overkill emerged, initially, because of the fight against the SDK, and then, because of the fight against the publishing of the iOS version.
If you ask us, would we again undertake to make a mobile VR game on Unreal, going through all this? If done exclusively under Android 5+, then, probably, yes. Otherwise, no. The team made such an application on Unity for several evenings, and did not worry about the SDK, focusing on the functionality, although the developer managed much more expensive, but less nerves and a faster result.
What is UE suitable for? If you are doing a VR project on a PC, or NOT a VR project for mobile phones, then the UE is an excellent choice for a number of reasons, which we will not delay now, since The article is not about that. But for a mobile VR, it is not yet ready. However, for sure, with updates, mobile VR support will improve.
As for the direction of VR development as a whole, I myself personally believe that virtual reality will ignite already by 2020 and will bring good revenue to VR developers. Therefore, those who are now starting their experiments or conducting research on this technology, in my subjective opinion, have great chances to get their profit a hundredfold by 2020. And I hope that the article will help those who are now dropping into this as yet only picking up course of the VR locomotive.
Separate, thanks for the help in developing the application and writing the article for the FurecoVR team: Evgeny Filchenko and Dmitry Kostyukevich.
And thanks for advising Kallist and Eligar
Here are the links to the game:
iOS: https://itunes.apple.com/ru/app/2048/id1109740917
Android: https://play.google.com/store/apps/details?id=com.antarex.vr2048
I will be glad to answer your questions and discuss the prospects of mobile VR in the comments!
Source: https://habr.com/ru/post/304810/
All Articles