Trending
Opinion: How will Project 2025 impact game developers?
The Heritage Foundation's manifesto for the possible next administration could do great harm to many, including large portions of the game development community.
Welcome to Day 37! Today, things are finally going to get serious in working with VR! Currently, there are a lot of problems with the app from when we launch it. Some are true limitations and others are bugs. Let's fix them!
Writers Note: Sorry for the lack of updates, I'm not dead yet! I went on a short vacation and got horribly sick. I'm hoping to continue as I have been going before.
Welcome to Day 37! Today, things are finally going to get serious in working with VR!
Currently, there are a lot of problems with the app from when we launch it. Some are just limitations and others are actual problems.
However, before we start to go in and fix everything that we encountered yesterday, today we’re going to add the Google VR SDK into our game.
Today we’re going to:
Set up wireless debugging so we can both: debug and receive console print statements from our game
Remove the old scripts that we’ll replace with VR
Add the Google VR SDK into our game
Set up a simple Event Trigger
Today, we’re going to start working in VR, so let’s not waste time and get to it!
Before we do anything, one of the most important thing we should do is to set up remote debugging or at the very least, the ability to have our console statements be sent to Unity untethered.
Currently, in Development mode, we only get console logs from our Android device if our phone is connected to our computer.
This wire would become too limiting if we must do something like spin around in a circle.
To fix this, we’re going to set up wireless debugging where our phone can send data remotely to Unity.
We’re going to follow Unity’s documentation on attaching a MonoDevelop Debugger to an Android Device.
The instructions are straightforward, so I’ll just leave the link to the instruction.
In our current state, because we have no way of restarting the game, we must rebuild and run every single time we want to see the console wirelessly. The reason being we lost the ability to restart the game inside the game.
However, when we re-add our ability to restart the game, wireless debugging will be more useful.
It’s finally time to start working in Unity!
Before we do anything, let’s think about the things that the Google VR SDK gave us and what must we get rid of in our current system that conflicts with the VR SDK.
The main thing that the Google VR SDK provides is:
The ability to move the camera with our head
Its own Raycasting system
What we need to remove from our game is:
The ability to move our character
The ability to move our camera
The ability to shoot
The crosshair UI
Luckily for us, this process is going to be fast and easy.
First, let’s remove our ability to move:
In our game hierarchy, select the Player game object.
Select the little cog on the top right-hand corner of the Player Controller (Script) and select Remove Component
Next, let’s get rid of the game following our mouse.
Select Player > Main Camera
Remove our Mouse Camera Controller (Script) Component
After that, let’s get rid of the shooting script. We’re going to come back later and re-purpose this script, but that’s going to be for a different day:
Select Player > Main Camera > MachineGun_00
Disable the Player Shooting Controller (Script) We’re still going to need this.
Finally, let’s get rid of the crosshair. As you recall, when we add the VR SDK, we get a gaze prefab that already adds a cursor in for us.
Select HUD > Crosshair and delete it from our hierarchy.
When we’re done, we’ll have a completely unplayable game! Yay….
Recalling from the Google Cardboard demo, for our game, we’ll need to add:
GvrEditorEmulator – to simulate head movement
GvrEventSystem – to use Google’s Event System for dealing with raycasting
GvrReticlePointer – for our gaze cursor
GvrPointerPhysicsRaycaster – The Raycaster that GoogleVR uses to hit other objects
The set up for this will also be very straightforward.
Drag GvrEditorEmulator in Assets > GoogleVR > Prefabs > GvrEditorEmulator to the hierarchy
Drag GvrEventSystem in Assets > GoogleVR > Prefabs > EventSystem to the hierarchy
Drag GvrReticlePointer in Assets > GoogleVR > Prefabs > Cardboard to be the child of Main Camera
Selectcs from Assets > GooglveVR > Scripts > GvrPointerPhysicsRaycaster.cs and attach it to our Main Camera.
When we’re done, we’ll have something like this:
Now with these prefabs and scripts in, we can rotate and look around our game by holding Alt.
We can also shoot our raycasts with our VR Raycaster, however right now we don’t have an Event Trigger set up in our enemies that will detect them getting hit.
Let’s do that!
Before we end today, I want to make a simple event trigger that allows us to be able to defeat an enemy.
Luckily for us, we already have the function available to us! Specifically, inside our Enemy Health script, we have a code that we call to damage an enemy.
Let’s set this up. We want to get something like this:
For now, we’re only going to change our Knight enemy. Here’s what we’re going to do:
Select our Knight prefab in Assets > Prefab > Knight
Add an Event Trigger Component to our prefab.
Click Add New Event Type to select what type of event we want to listen for
Select PointerClick
Now click + to add the object we want to access the scripts of.
Drag our Knight Prefab into the empty Object slot
Then we need to select the function to call: EnemyHealth > TakeDamage(float)
Set the float value we pass in as 1
When we play our game now, when our gazer focuses on an enemy and we click, we’ll shoot him!
There are a lot of things that we’re missing like the push back, but we can start focusing on the rest of that tomorrow!
Now let’s do that to the rest of our prefabs: Bandit and Zombie!
There we have it! Our first dive into doing some work with VR. It turns out right now, there’s a lot less code that needs to be written, instead, a lot of it is just putting prefabs and scripts to the correct location so our game would work.
Either way, now we have a game that is playable. Tomorrow, we’re going to discuss what changes that we should do to make a better VR experience. Or at the very least, as good as it was before we try to VR-ify it!
Phew, it’s been a long day, I’ll see you all tomorrow on day 38!
Read more about:
BlogsYou May Also Like