Making a VR Game with UE4 & Publishing It

Hi everyone! My name is Artem Severin, I am one of the developers of Witching Tower VR, an action-adventure.

I want to share my experience in the VR game development and speak about the difficulties our team faced. Perhaps, my story might motivate young developers because anyone who has enough persistence, diligence, and desire can make games with Unreal Engine.

We are a small company called Daily Magic Productions. Nine years ago we launched our first Hidden Object Puzzle Adventure game, after that we have released more than 20 successful projects. Also, there are a few more or less successful mobile apps in our portfolio.

After a while, we understood that we were on the dead-end road and we had to start looking for more ambitious, interesting and advanced directions. It was time to explore new technologies, improve our team and move forward. In terms of development, our business was at the stage of maturity, and after the maturity always comes a decline.

There are a few core trends in the modern game development that you must follow to keep up to date. In those days we nearly failed to keep pace with the time: the artists had been doing the routine work drawing in the same style for a long time, programmers got stuck in Visual Studio 2008 (in 2015!), scripters and level designers worked in a 2009-year version of Playground-based engine. However, the workflow was smooth. It was like an outdated server which works perfectly that, being technologically old, isn’t capable of any changes. However, the budget, porting, optimization, localization, and terms were demanding urgent improvements.

What were we going to do?

We had no doubts what niche to choose for our experiment. VR  both was something we wanted to do and provided a few advantages:

• Opportunities. One way or another, the future belongs to VR. Everyone wants it, from Oculus to HTC. We are sure that in 20XX when VR will come to every home and shopping mall, we will have enough experience to satisfy the players.

• Low competition. Dozens of games appear in Steam every day while just 1-2 of them are VR. Some of them are great, some of them are not. Nowadays everyone has a chance to get a big piece of the pie. It has to be said though that this pie is only for viable companies with portfolio who clearly see their future and looking for new horizons. VR is expensive.

• High-tech. VR is a trend which is not going to fade in the foreseeable future. As for the software, having accumulated some experience with several engines we opted for Unreal Engine. Its tutorials, low barrier to entry, plenty of content and a great marketplace just a small part of the features which Epic Games you for free.

Off we go!

We started pretty fast but the technological failure and narrow thinking easily let us down. Nobody knew what to do and how to do it. We had to learn everything from scratch. It happened not only with artists, animators, and programmers I’ve mentioned before, but also game designers, project managers, and producers. Achieving the desired results was a tough process but the best moments came when we were overcoming the difficulties.

Now, looking back at the work that’s been completed, I want to share some ideas on the building of the process and optimization workflows. They work for all Unreal Engine projects, not only for VR games. I don’t want to sound like Captain Obvious, but I am sure that we are not the last company who did things in a rush and had to learn a lot in a short amount of time.    

When developing your first VR project, don’t forget that you are making a very demanding game where the slightest drop in the fps is torture for a player. You will struggle and fight for each mesh, particle or texture. In VR, your video card and processor are rendering pictures for both eyes.

This means you will need to forget about a beautiful open world with thousands of interactive objects with realistic physics. Your aim is 90 fps (60 fps for PS4) or 11 milliseconds.

Learn how to merge Actors. It is a subtle point, which always depends on the situation. You can find an ideal solution only by testing and comparing the results. Long story short: merge any time you see a drop in draw calls. But if there are problems with rendering, it will only make the situation worse, as there will be more polygons to draw. There is no sense in merging five objects if you see just one of them. But if these five objects are always shown together, it is better to merge them.

Turn on VR Instanced Stereo (Stereo Rendering) if you haven’t done it yet. Otherwise, each eye will be rendered separately. Stereo Rendering optimizes CPU but worsens GPU. You will win some draw calls, but it will cost you adding more instructions in materials.

Check if the resolution isn’t too large. Probably you made our mistake: we had to change the resolution from 2700×1600 px to 2160×1200 px (actual Oculus Rift resolution). It reduced GPU load keeping the graphics outstanding.

LOD. I can’t help mentioning it if though you might know it already. It is a powerful and indispensable tool. In some places, you will have to add special lightweight materials by changing from Translucent mode to Masked, from Masked to Opaque, etc. But it’s worth it.

The gifs above show how LODs help in optimization. Use them wisely and a player won’t notice any difference, the result still will be great. Keep in mind that you see the game differently wearing glasses. So, to avoid the unnecessary work never test the LODs without glasses.

Translucent. Minimize the transparency, especially when one transparent object overlaps another. Usually, it is typical for particles, God rays, grass, bushes, glass, roots, etc. Shader Complexity clearly shows all these bottlenecks. The tool is not ideal but shows the overall situation. Don’t trust Shader Complexity in Cascade. Drag the effect to the work scene and analyze it there.  

Don’t use double-sided materials where players don’t see them, especially Translucent. It causes a double rendering process and extra instructions. We can’t afford it. Watch the Instance Material, since a double-sided material could be enabled by default in the Base material.

Get used to resource optimization. If you create materials yourself, it won’t be a problem for you to make two versions of the shader for different graphics quality levels. You will not notice much difference after changing one material, but if you implement it for all materials in the game, you’ll definitely see the result.

Optimize VFX at once. Don’t put away for later the adjustment of LODs and emitters on different graphics quality levels. Firstly, having a vision, you will be able to do it properly on the first attempt. Secondly, it will save a lot of time in the future especially if next time you’ll give this asset to someone else. Obligate your VFX artist to do it, it should be one of his main responsibilities.

Bear in mind that emitters’ visibility could depend on the graphics quality level.

Hint: uncheck the parameter Apply Global Spawn Rate Scale if you don’t want the graphics quality influence the quantity of appearing emitters. It might be useful when due to the graphics low-quality level UE reduces the number of particles causing lags and twitching of the effect.

Teach the game designers and level designers to think about optimization. Spend some time to explain to them what Culling is and how it works in UE, that transparency is very bad and should be avoided, that lots of stones and grass is a bad idea, and nothing could be worse than an open world.

We nearly cut the next room. Otherwise, we wouldn’t be able to meet the platform requirements. Unfortunately, we weren’t able to implement this simple and radical approach everywhere.

Above all others, it’s the designers who are responsible for solving this problem during the concept stage! VR is not about large rich environments, it is more about small rooms with corridors.

We didn’t know these peculiarities and weren’t prepared for that at the start, so we found ourselves in the clutch. On the one hand, our levels were too large to be rendered quickly, on the other – they were too small for the smooth work of LODs. Our architecture was designed absolutely wrong. If we could go back 9 months in time, our game probably would look differently.

Check Bounding Boxes. Often, while walking around the level we had a feeling that something wasn’t clipped. In such cases, it is highly likely that the Bounding Boxes aren’t working properly. It is not uncommon for effects, especially when bounding boxes were generated automatically in GPU particles and deleted after that. That issue made us check and fix all the effects.

The emitter was removed but the Bounding Box remained:

Use RenderDoc. It is a small graphics debugger which analyzes each frame helping to find what eats the FPS. I highly recommend it for game optimization.

Polish the level right after the approval. First, get the best result you can, then get down to its optimization.

It gives the opportunity to analyze the scale of the problem, find weaknesses of the process, realize your mistakes and save a lot of time in the future. We learned it from our experience when all our beautiful immersive locations full of life were finally assembled. We knew that we probably would have some problems with optimization, but at the same time we were stuck thinking “C’mon, we will do the optimization the month before release. It is not a core task yet.” But it is a core task. Don’t repeat our mistakes! You can’t optimize something that cannot be optimized! At this stage, it is too late to change the layouts of the levels or core mechanics. One does not simply set a wall or remove the enemies if they are required by the gameplay.

If you are new to the development and don’t know what to expect, try to follow my advice: optimize your first location as soon as it is ready. After achieving the desired results you’ll understand how to make the rest of your game, what your potential weaknesses and limits are.

A Few Words About the Release

We had never released games on Steam, neither for PC nor for Oculus or Viveport.

Sure thing, we used all possible opportunities to shoot ourselves in the foot:

• We had to postpone the release several times, and consequently, it happened not on a very appropriate day (maybe the best of the worst). As a result, we had a bunch of problems.
• We missed the Halloween Sale, being released right before it.
• What is more, the release happened the day before Red Dead Redemption came out.
• We caught only the second half of the pretty profitable Autumn Sale. Usually, Steam sales boost purchases by 2-4 times or even more. By the way, it is when buyers with wish-lists wake up.
• The version of the game sent to the press had some issues and we received a few negative feedbacks about the FPS drops and bad optimization.
• Nearly all big publishers and streamers neglected us because of the end of Red Dead Redemption 2 review embargo and oncoming sales. Usually, such big events are preceded by loads of posts with recommendations, announcements and information noise alike.
• We immediately received the negative reviews due to a small bug that had constantly been killing the FPS.

About the Stores

Steam

It would seem that VIVE and Steam are the best friends working in tandem. No way. You will be struggling with your game alone, without any support or feedback. Kudos to Steam for its technologies and the way it uploads and updates the builds (while the interface and some methods are outdated).

The release happens in three stages:

Filling in the store page. I recommend you to proceed to this stage armed with really cool screenshots and catchy game description.

Game approval. Within 5 working days, your game will (or won’t) be approved. After that, you will be able to update the build whenever you want without additional approvals. You don’t have to upload all your 30Gb again and again (as you do on some other marketplaces). Steam will upload only those bites of the build that were changed. Steam also has an App Branches system that allows sharing separate branches with the press, Youtube bloggers and testers. It is very convenient!

The release. You push the big green button, confirm the release and that’s it, your game sees the light of the day. There is no other way to release it. Now, Steam will be promoting your game for a month, showing its banner on the showcases according to its clever algorithms.

If you release updates (no more than five) they will give you a few more rounds of promotion. They will attract some attention to your game but don’t hold your breath – you won’t see the rush of customers. The result is too poor to mention it. We got a 3% increase in engagement. However, it was our first try, probably you’ll get better results.

What Needs to Be Taken into Account?

Demo build. You must have an ideally polished piece of the game to show to any meaningful figure on the Internet. Do it a month before the release, impose an embargo if you need. It is important to send the offer in advance because many people have their own working schedules to follow. It is your demo version that must put your game in the spotlight and make it viral.   

Final Build. This stage may be obvious, but we managed to fail even here by getting a few negative reviews on the very first day which remained popular for a very long time.

Never make changes in the build before the release! Just know it. It is taboo.

What did we do? Oh, we “just” added one feature into the tutorial, which totally dropped the FPS. It was so bad that one of the negative reviews was from a dude with GeForce RTX 2080. It would be funny if it weren’t so sad. Anything that can go wrong will go wrong.

Hint: if you solved the problem of someone who had left a bad review, let him know about it. People really love when developers communicate and take care of them. It is very likely that they will change their bad rating after that.

Release date. Take it very seriously. Analyze the nearest sales, competitors’ releases or any other big launches, the schedule of events. The focus of the press and streamers must be only on you, not on something like GDC, CES, Oculus Connect or Red Dead Redemption. “Why should I bother about Red Dead Redemption when it’s a console game if I release a VR game on Steam?” Because none of the popular streamers will prefer you over a game with millions of fans if you appear on the same day.

Basically, there are no restrictions on the date and time of the release on Steam. It could be any day of the week. But Friday, Saturday and Sunday are bad days, because on holidays Steam won’t be able to come and help you. Previously it was believed that Thursday was the best choice, but today only a few people think so. You probably won’t notice any statistically significant correlation.   

Besides, think about the sales schedule. You can’t participate in discounts and sales if it’s been less than one month since the day of your release. For example, if your release was on December 5, you can’t participate in Winter Sale.

HTC

Communication with HTC made a very positive impression. These guys really want to help you to make a great game. For many months they have been supporting us with advice: what to fix, change or add, what solutions work best for VR. They share their experience and they are really cool guys in general. So, don’t hesitate to write to them and ask for help.    

In addition, HTC has an active social support network. They repost you, show your games on their channels and groups. Don’t forget to use VIVEPORT hashtags and mention their groups in your posts.

In general, the developer console is user-friendly. One thing worth of mentioning: when sending the game for the review, in the Submit section, opt for“Create production release”, no “Create a Beta version”. We once made that mistake in an important moment and HTC didn’t notice our build. The thing is they don’t see the beta versions at all, it is just for you to check the performance, showcase and so on.

The approval takes a bit longer than in Steam. Slightly more than a week. Each time the build must be uploaded from scratch. Each new version must be approved. Keep it in mind. A little hint: if you have a really serious reason to upload an update (like a critical bug), you can ask for the urgent approval.

Oculus

This is a very conservative company with rigid rules. They don’t care about the half-way results. You can’t set a release date until you have a proper final version of the build that matches their check-list. It makes marketing activity difficult. Oculus rarely promotes games on their social media, although promises to support developers at their conferences. After two months of communication and meetings, we got only a few pieces of advice on optimization. However, at the same time, they provided us with a banner on the main page. Many thanks for that!

In order to obtain this result, you will have to put up with investing time in business development always being in touch with people from Oculus. You won’t be able to focus only on the development.

At first sight, it may seem that such a rigid process is bad, but that’s not the case. Rigidity is a good practice, it obliges all the developers to follow the rules to create proper content. That’s the way of Oculus to make your project better.

As for the developer console, it is friendly, intuitive and just great. You’ll find there a lot of helpful things from the system requirements with reports to check-lists, apps descriptions, and guides. Make sure to study section Develop/Doc/Unreal. They put their heart into it. Builds must be uploaded fully (as in VIVEPORT Developer Console). But you can download a special uploading tool (now it is obligatory for games larger than 1Gb). It saved us time when it came to uploading the build. They promise that in the future it will only upload the bits that have been changed since your last build.

Oculus provides three default release channels: Alpha, Beta, and Release Candidate. There is also a special channel named Store. They will proceed to the approval only when you upload the build into Store. Before that, they might not know about your existence at all.

A small hint: if the duration of your trailer is around 2 minutes, you’ll probably be asked to cut it to 1 minute. Do it in advance, they believe that it is the best timing.

Afterward

In conclusion, I want to say that our experiment has been fulfilled. The Daily Magic team made a breakthrough and mastered their skills. We learned how to work in Unreal Engine, understood how to create 3D worlds and environments. We grasped how to differentiate important things from unimportant ones, and how to manage priorities. Our company added a great project in the portfolio and it has been bringing the results already. We opened up new horizons which seemed to be unachievable before. Believe in yourself and your colleagues, and you’ll achieve some great results.

Artem Severin, Game Developer at Daily Magic Productions

Translation prepared by 80.lv