Jump to content
  • entries
  • comments
  • views

Day 36 of 100 Days of VR: Getting Our FPS Game Running in VR

Josh Chang


Welcome back to Day 36! Yesterday we set up our mobile device to be able to play VR device and there’s nothing quite like that experience, especially if you’re the one that “made it”.

If you’ve made it this far in the journey, but you haven’t tried using the Cardboard or other VR devices, I highly recommend trying it once!

Now… with my pitch out of the way, let’s talk about what we’re going to do today!

We finally started working in VR, today, we’re going to try and convert our simple FPS into a VR experience.

This will be a multi-day progress. Today, I want to:

  1. Do some Asset clean ups for our app so we don’t have to spend forever building
  2. Set up our Google VR tools
  3. Play our game

Getting the Project GitHub Repository

Before we get started. I realize that not everyone (or anyone) followed me step by step to get to Day 36.

In our Simple FPS game, we have reached a complete prototype so I’ve decided to make a Github Repository of our game before we start adding the VR components in. Specifically, after doing some manual cleanup work in Step 1.

Now anyone can start following along to build our VR application.

You can find my Simple VR First Person Shooter GitHub repository here.

Step 1: (FAILED/SKIP) Clean Up Un-Used Assets

If you haven’t tried switching to the Android platform in our simple FPS game, you might notice, that it… takes… FOREVER.

I’ve tried building the app (and I waited 10+ minutes). Thank goodness for the Unity previewer, I would not know what to do if I had to build my app on my phone every single time!

Luckily, I found that Google/Unity does have a solution for this. Google has Instant Preview. Unfortunately, which loads the game into our phone while also playing on the editor. The bad news is that this only appears to be for the Daydream Viewer so I’m going to hold off for now.

However, let’s see what we can do to optimize this!

When I say optimize, I really mean get rid of our un-used assets! Looking at what we have, we have 1 GB worth of files! That’s not good!


Unfortunately, this didn’t exactly work. I tried to export all our dependencies and then import it into a new project and there were some problems.

It turns out, things like Layers and Tags do not get preserved so if we wanted everything to work, we had to manually add everything back in.

Instead, I used the files I exported into a new project as a reference and then manually removed assets from a copy of our project (that’s what I get for not having source control!)

Also from testing with a before and after build time, I believe that un-used assets DO NOT improve our build and runtime, so the only useful thing that came out of Step 1 was that I:

  1. Cleared some clutter so we can find files more easily now
  2. Made the project smaller so people can download it from Github faster, so not a complete loss!

Step 1.1: Exporting our Assets

Let’s get rid of our old un-used files! How? Well, a quick search on how to get rid of unused assets in Unity.

All we need to do is:

  1. Select our scenes, which in this case is just Main
  2. Right-click and click: “Select Dependencies”
  3. Export our assets by going to Assets > Export Package… and save your package somewhere.

Warning: This will not export Editor scripts and plugins, which in our current situation, is not a problem.

Now at this point, we have 2 choices:

  1. Delete everything and re-import the assets that we exported or…
  2. Create a new project and import our exported project

I’m going to do the 2nd choice and make a new project.

Step 1.2: Importing our Exported Assets

We’re going to create a new project and import everything we just exported. To do that:

  1. Select File > New Project…
  2. Call your file whatever you want, but I’m going to call mine First Person Shooter VR

And now we’ll have a fresh new Unity project:

Now we need to re-import everything we exported.

  1. Go to Assets > Import Package > Custom Package and find the .unitypackage that we just created
  2. Afterwards, just choose to re-import everything

Step 2: Set Up Our VR Tools and Settings

The next thing we need to do after we have our new project is that we need to import the Google VR SDK and configure our Unity.

I’m going to be lazy and just refer us to Day 35: Setting Up Google Cardboard In Unity.

Just do the exact same thing in downloading the SDK and setting up our Unity configuration.

Note: In the repo, I already included Google VR SDK 1.100.1 and the necessary changes for Player Settings. I assume the PlayerSettings are project-based and not computer-based, but if it’s not, follow the instructions in Day 35.

Step 3: Playing Our Game

At this point, we should be almost ready to play our game!

At this point, we have:

  1. imported the Google VR SDK
  2. Switched to the Android platform
  3. configured our PlayerSettings to the appropriate settings to run a Google Cardboard app

The last thing we need to do that’s specific to our Game Project is that we try to build in Build Settings… we run into a problem to resolve incompatibilities between Color Space and the current settings.

To fix this, we just need to change our Color Space from Linear to Gamma. To do that:

  1. Go to File > Build Settings > Player Settings > Other Settings > Color Spaces
  2. Change Linear to Gamma

With this setting in, we’re ready to build our game.

To do that, I recommend running the development build to build our app.

Contrary to what the name sounds, development build DOES NOT make our build faster, instead it allows us to have access to useful debugging settings gives us access to the Profiler and Script Debugging.

Now once you’re ready, let’s build our game! Make sure your phone is connected to your computer.

  1. Go to File > Build Settings…
  2. Enable Development Build
  3. Click Build And Run
  4. You can save the APK anywhere.

Now enjoy the long wait~!


That’s it for today!

Today we cleaned up a bit of our project and then set up the game so that we can run our app directly from our phone.

The build is long and horrendous, which is unfortunate. There are a couple of solutions available, but I’m going to look at them some other day.

We can also play the game directly from Unity. If we were to play the game right now, we’ll encounter problems.

From a technical limitation:

  1. We can’t move
  2. We can’t reload anymore

To actual technical problems:

  1. The enemies are all black color
  2. We don’t have any of our UI’s anymore

I’ll have to investigate these things and solve them one at a time, but I can finally say, we’re here! We’re finally working in VR!

That’s what we’re going to try and tackle the next couple of days. It’s going to be a fun one!

Day 35 | 100 Days of VR | Day 37



Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By Rio Lloyd
      Hey all!
      we are a team of 3 looking for more members, 
      we are making an isometrical Survival RPG.
      we are looking For Members who can make low poly 3D artists who can do character models, environments, tools and more.
      if interested and want to know more email me at rioishere14@gmail.com
    • By nxrighthere
      BenchmarkNet is a console application for testing the reliable UDP networking solutions.
      Asynchronous simulation of a large number of clients Stable under high loads Simple and flexible simulation setup Detailed session information Multi-process instances Supported networking libraries:
      ENet UNet LiteNetLib Lidgren MiniUDP Hazel Photon Neutrino DarkRift More information and source code on GitHub.
      You can find the latest benchmark results on the wiki page.
    • By trapazza
      I'm trying to add some details like grass, rocks, trees, etc. to my little procedurally-generated planet. The meshes for the terrain are created from a spherified cube which is split in chunks (chunked LOD).
      To do this I've wrote a geometry shader that takes a mesh as input and uses its vertex positions as locations where the patches of grass will be placed (as textured quads).
      For an infinite flat world (not spherical) I'd use the terrain mesh as input to the geometry shader, but I've found that this won't work well on a sphere, since the vertex density is not homogeneous across the surface.
      So the main question would be: How to create a point cloud for each terrain chunk whose points were equally distributed across the chunk?
      Note: I've seen some examples where these points are calculated from intersecting a massive rain of totally random perpendicular rays from above... but I found this solution overkill, to say the least.
      Another related question would be: Is there something better/faster than the geometry shader approach, maybe using compute shaders and instancing?
    • By FedGuard
      Hello all,
      I would like to start off with thanking you all for this community. Without fora like these to assist people the already hard journey to making an own game would be exponentially more difficult. Next I would like to apologize for the long post, in advance...
      I am contemplating making a game. There, now that's out of the way, maybe some further details might be handy.
      I am not some youngster (no offence) with dreams of breaking into the industry, I am 38, have a full-time job, a wife, kid and dog so I think I am not even considered indie? However I recently found myself with additional time on my hands and decided I would try my hand at making a game.Why? Well mostly because I would like to contribute something, also because I think I have a project worth making (and of course some extra income wouldn't hurt either to be honest). The first thing I realized was, I have absolutely no relevant skill or experience. Hmm; ok, never mind, we can overcome that, right?
      I have spent a few months "researching",meaning looking at YouTube channels, reading articles and fora. Needless to say, I am more confused now than when I started. I also bought some courses (Blender, Unity, C#) and set out to make my ideas more concrete.
      I quickly discovered, I am definitely not an artist... So I decided, though I do plan to continue learning the art side eventually, I would focus on the design and development phase first. The idea being, if it takes me a year or more solely learning stuff and taking courses without actually working on my game, I would become demoralized and the risk of quitting would increase.
      So I thought I would:
      1: Keep following the courses Unity and C# while starting on the actual game development as the courses and my knowledge progress.
      2: Acquire some artwork to help me get a connection with the game and main character, and have something to helm keep me motivated. (I already did some contacting and realized this will not be cheap...). Also try to have the main character model so I can use it to start testing the initial character and game mechanics. For this I have my first concrete question. I already learned that outsourcing this will easily run up in the high hundreds or thousands of dollars... (lowest offer so far being 220 USD) I am therefore playing with the idea of purchasing https://assetstore.unity.com/packages/3d/animations/medieval-animations-mega-pack-12141 with the intention of then have an artist alter and/or add to the animations (it is for a Roman character so some shield animations are not going to work the same way.). This way I could start  with the basic character mechanics. Is this a good idea, waste of money,...? Any suggestions? I then have a related but separate question. Is it a good idea to buy Playmaker (or some other similar software I haven't yet heard of like RPGAIO), and using this for initial build, then changing/adding code as the need arises?
      3.Get a playable initial level ready as a rough demo and then starting to look for artist for level design and character/prop creation.
      I would really appreciate some input from more experienced people, and especially answers to my questions. Of course any advice is extremely welcome.
    • By GameTop
      Dirt Bike Extreme - another game made with Unity. Took about 2 months to complete.
      Take part in extreme motorcycle races across the dangerous and challenging tracks. Dirt Bike Extreme is easy to pick up but hard to master. Race, jump and crash your way and other mad rivals through the amazing tracks as you master the skills and physics of motocross in this high-speed racing adventure. Conquer challenging routes on 23 different runs, discover new bikes and become the best of the best! Over 257K downloads already!
      Windows Version:

      Mac Version:



Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!