• entries
44
19
• views
2320

1026 views

# Introduction

Hi everyone, I'm Josh, an aspiring game developer hobbyist. I was inspired by the many developer blogs here and decided to post my own personal journey as a new VR Developer!

After having a great time playing with the many different VR devices, I decided that I have to get involved in making apps.

I believe VR is going to be the big next thing, but for that to happen, it'll need a lot of content (apps). With that, I decided to pick up Unity and learn how to make VR applications.

I currently have no experience with Unity, however I work as a Software Developer during the day so I am very familiar with programming so I'm confident in my abilities.

However, Instead of just jumping in and learn how to use Unity, I realized that I might be in the perfect position to help others follow in my foot steps and develop VR applications.

I'm familiar enough with programming that I'm confident I can figure things out, but I'm also new enough that I don't really know what I'm doing so I'll run into the many common problems other people might miss.

With that being said, I decided to document my journey from Zero to a VR developer in what I want to call my 100 Days of VR. My two goals are to:

1. Motivate myself to really learn how to use Unity and make VR applications
2. Create a series of posts that hopefully someday help someone, literally anyone get started in developing in Unity and/or VR applications.

With that being said, here's my progress for the day.

# Day 1

The first step to learning VR, is learning how to use one of the game engines that supports them. In the current market, we have 2 options: Unity and Unreal Engine.

I was told that Unity was more beginners friendly so I decided to pick that up. I installed the latest version of Unity along with Visual Studio 2017 Community Edition that came bundled along with Unity.

Great! Now that we have our toolkit installed, what’s next?

The first thing I did was that I started to go through the Unity’s Roll-a-ball tutorial.a

Here’s a summary of what I learned in the tutorial:

# Setting up the Game

## Scene

The scene tab gives you a 3D view of the world that you can move around in. In this tab, you can directly drag and drop the positioning of the objects that you inserted into Unity

## Hierarchy

The hierarchy is used to display the Unity objects that you create and added into your scene.

## Positioning

Since we’re working in a 3D environment, Unity has a  3D coordinate system: (x,y,z), if we were to select the sphere that was created in the tutorial, if you look at the the inspector on the right, you can see that we can change some of the transform properties such as position, rotation, and scale.

It appears that if we imagine something lying flat on a surface:

• X = Horizontal movement
• Y = Height movement
• Z = Vertical movement

## Material

If you want to change colors of your object, we have to create a material for our Mesh Renderer component that you can see from the picture above.

If you were to select the sphere,  in the inspector under the Mesh Renderer component, you can select a material to apply on our object.

In the tutorial we created a new material in the project pane and made it's color red. Then we applied it to our sphere to get the red sphere that you see above.

# Roll a Ball

After the first video showed us how to setup the environment and use some of the tools available for the roll a ball tutorial, the next thing we learned is how to actually move the ball.

## Rigid Body

The first thing we need to do is to add a RigidBody component to our ball object. What this does is that it makes the ball take part in Unity’s physics engine so that it’ll be affected by things such as gravity and when it collides with other properties

Looking at the code for this part of the video, we can learn a lot of information:

using UnityEngine;
using System.Collections;

public class PlayerController : MonoBehaviour {

public float speed;

private Rigidbody rb;

void Start ()
{
rb = GetComponent<Rigidbody>();
}

void FixedUpdate ()
{
float moveHorizontal = Input.GetAxis ("Horizontal");
float moveVertical = Input.GetAxis ("Vertical");

Vector3 movement = new Vector3 (moveHorizontal, 0.0f, moveVertical);

}
}

The way scripts in Unity works is that they are attached to unity game objects that are in and we can grab any component information that’s attached to the game.

A great example is given in the example code you see above when we’re using the rigid component:

rb = GetComponent<Rigidbody>();

for when we want to access information from our RigidBody component.

## Public variables

Before looking at the rest of the function, I want to point out that if you were to make a variable public in Unity script, that means you can set their value outside of the code under that script’s component in the Unity Editor.

Using the component system we can easily change the text and settings on the fly when you’re play testing your game!

## Learning about Start and Update

So we have 2 functions that are being used in the code Start() and FixedUpdate(). Both of these are functions we’re inheriting from the MonoBehaviour object that controls how the game works.

Here are the more common methods I found

• Start() – this is run only once when your GameObject gets created in Unity. It’s used for initializing your variables and creating the state of your GameObject when it is first created

The next parts are the updates method. Depending on what you might have worked on, the update function might take some time to wrap your mind around.

An update method is called once every time Unity renders a frame. You might have heard the term, frames per second? If we have 60 frames per second, which means our update function gets called 60 times every second.

So what’s a frame? If you have some knowledge of animation, you’ll know that an images is made of multiple images that are being replaced one after another. An image to illustrate my point is this gif:

This gif is actually made up of multiple images from a sprite map that is being looped through per scene.

From my basic understanding, this is extremely important for VR, if we want to avoid causing motion sickness, we have to make a game that achieves 90 fps

But anyways that’s a problem for the future, I don’t even know how to work with Unity! Going back to the update methods, we have:

• Update() – this methods Is called every frame that the game runs in. I did my own investigation by inserting the code snippet Debug.Log("update: " + Time.deltaTime); to print out how much time has passed since the last update call and found that the time per frame isn’t consistent.
• FixedUpdate() – Similar to update, but this code runs at fixed times, which is good for physics calculations which we see in the code above. Printing the deltaTime, it appears that the FixedUpdate method is called every 0.02 seconds. Forcing 50 fps

## Inputs and Vectors

Finally the last part of the code is the movement code. Unity comes with a handy set of api’s that make it easy to detect when the user is hitting on the keyboard.

We used Input.GetAxis, to get the movement when we hit the arrow keys to get the direction that is being hit and store those values in a vector.

If you remember a bit of physics from High school, you might remember that a vector is just a direction. So in our code, when we say we create a vector (x,y, and z location) it means that we’re creating a force that’s going in that x,y, and z direction that we specified…

…which is exactly what you see here:

rb.AddForce (movement * speed);

# Moving the Camera

So that was a lot to learn about Unity already and we’re only in 3rd video of the series! So continuing on, after learning about moving the ball around, we now see that the game tab that we run doesn’t really move or follow the ball when we roll it around.

This was resolved by using a camera object, the view that you’re seeing in the game tab is from the camera.

So a nifty way to follow the ball is to make the ball a child of our ball, by dragging our Main Camera object on the hierarchy into the Sphere we made.

By doing this, we made our camera relative to our ball’s position. Unfortunately, when we move the ball around the camera follows.

To fix this we added the provided CameraController script to our camera:

using UnityEngine;
using System.Collections;

public class CameraController : MonoBehaviour {

public GameObject player;

private Vector3 offset;

void Start ()
{
offset = transform.position - player.transform.position;
}

void LateUpdate ()
{
transform.position = player.transform.position + offset;
}
}

What was done was that we created the distance from the camera to the player in the Start() function and update our camera so that it is always that distance away in LateUpdate()

LateUpdate() acts the same way as the other update() however the difference is that it is the method that’s called when rendering a frame.

# Setting up the Play Area

There wasn’t too much in this section, just learning how to setup our environment by moving around objects

# Creating Collectable Objects

There also wasn’t too much here, we created collectible items that the player can roll the ball over, we created a script to make the ball rotate which we do by grabbing our GameObject’s transform component and modifying the rotation.

transform.Rotate (new Vector3 (15, 30, 45) * Time.deltaTime);

Note: Time.deltaTime is the time that elapsed since the last time we called Update()

## Prefabs

However one interesting thing to note is that after we make the object we want, we can drag it from the hierarchy into the project pane on the bottom to create a prefab.

A prefab is a template or a clone of the object that you made. With this, we can create multiple instance of that same object.

The benefits of using prefab is that if you ever decide to change the components of the GameObject, instead of changing them one by one, just by changing the prefab, you can change all instance in one go.

Collecting the Pick-Up Objects

Now things are finally getting more interesting. In this section, we learned a variety of subjects involving colliders and how objects in the game interact with other objects.

From the previous video, we created these cube objects (which has their own rigid body) that we can collect, however if we were to roll our spheres into the cube, we would bounce back.

This problem will be addressed in this video.

## Collider Intro

Whenever a GameObject that has a Collider component touches another GameObject with a Collider component, we call that a collision.

Unity provides many collider components that you can attach to your GameObject. These colliders all come in difference shapes and sizes. The goal is to pick a collider that matches the shape of your GameObject.

When we were to use a different collider, let’s say a square for example, the collision won’t actually occur at when something else touches the material (the red sphere), instead the collision will start when they touch the edge of the square

From my understanding, we can use a mesh collider to try and hug our object as close as possible, however the more fine grain control we need on our GameObject for collision, the more calculations will need to be done, resulting in worse performance.

The TLDR of this: only use complex colliders if you absolutely have to, otherwise we should try and use more basic shape colliders.

## Using Colliders

Now back to what was taught, how do we use them?

In our PlayerController.cs we just inherit the OnTriggerEnter() function!

void OnTriggerEnter(Collider other)
{
if (other.gameObject.CompareTag ("Pick Up"))
{
other.gameObject.SetActive (false);
}
}


This method gets called every time our sphere bumps into another collider, we get passed a Collider object that has access to the GameObject that we collided against.

Notice how we have something called Tag? That’s how we can identify what we hit in Unity. In each GameObject in the hierarchy, you can create and attach a Tag to them. As you can tell from the code above, we can use Tags to help identify which GameObject we collided against.

After we found the object with the tag we want, we can do whatever we want with it!

## Performance Optimizations

While probably not important to know this early on, something that was briefly mentioned  is that there are two types of colliders, static and dynamic colliders.

Static colliders, as you expect, are objects that don’t move and dynamic are objects that do move. The important thing to remember here is that static colliders are cached by Unity so that we can get performance benefits, however if you plan to change and move a static game object, this will cause Unity to constantly cache the object, which now becomes a performance problem!

To make a GameObject be a dynamic collider is to make it impacted by Unity’s physics engine, ie adding a RigidBody component to it.

Dynamic Collider = RigidBody Component + Collider Component

Static Collider = Collider Component

## Displaying the Score and Text

The game is “technically” done, but the user will never know it. In the last video of the series, we learn a bit about using Unity’s UI system.

## UI

You can create a UI element like text the same way you create a GameObject in Unity by right clicking in the hierarchy pane, however one big difference is that all UI elements are made children of a Canvas GameObject.

And another thing is that the Canvas is actually directly on the screen when you’re in the Game tab and is not part of the Scene Tab… well actually it is, but it’s in a completely different scale!

The canvas covers the whole Game tab screen and for our UI GameObject, instead of Transform, we have something called Rect Transform.

In a way it’s very similar to a normal GameObject where you can still drag the object around, however a nifty trick that help position the text is to click on the square button on the top left corner of our Rect Transform component and you'll get this:

If you hold alt and click one of the square, your text will be automatically moved into one of the 9 spaces! Nifty!

## How to use our UI components

Looking at the code that was created in the video:

using UnityEngine;
using UnityEngine.UI;
using System.Collections;

public class PlayerController : MonoBehaviour {

public float speed;
public Text countText;
public Text winText;

private Rigidbody rb;
private int count;

void Start ()
{
rb = GetComponent<Rigidbody>();
count = 0;
SetCountText ();
winText.text = "";
}

void FixedUpdate ()
{
float moveHorizontal = Input.GetAxis ("Horizontal");
float moveVertical = Input.GetAxis ("Vertical");

Vector3 movement = new Vector3 (moveHorizontal, 0.0f, moveVertical);

}

void OnTriggerEnter(Collider other)
{
if (other.gameObject.CompareTag ( "Pick Up"))
{
other.gameObject.SetActive (false);
count = count + 1;
SetCountText ();
}
}

void SetCountText ()
{
countText.text = "Count: " + count.ToString ();
if (count >= 12)
{
winText.text = "You Win!";
}
}
}

We created a public variable of type Text, you can assign the value by dragging and dropping the Text object in our hierarchy into the variable slot in the script’s component.

One very important thing to remember when you’re using UI gameobjects is to include:

using UnityEngine.UI;

Otherwise Unity won’t know any of the UI objects that you’re trying to reference.

The only new important part is the function SetCountText() which is where we see how we interact with a UI object:

void SetCountText ()
{
countText.text = "Count: " + count.ToString ();
if (count >= 12)
{
winText.text = "You Win!";
}
}


It looks pretty straightforward right? You get the UI object, and you set it’s text to be whatever you want it to be. Easy!

# Conclusion

Phew, doing this write up summary might actually be harder than the actual learning of Unity… and it’s only day 1!

But that’s okay. We’re just starting to learn about Unity, I’m sure as we progress along we’ll start seeing things like colliders, rigid bodies, and UI again and I don’t have to do THIS again. I really hope so. I really do…

Anyways, that’s the end of day 1! I hope you learned something valuable from this!

Read from the original Day 1

I was wondering if ultimately you end up doing VIVE/Rift games? Just wondering because I jumped ahead to see when you actually get to VR and you are doing Google VR thing... so do you actually do real VR... aka Vive or Rift at some point?

Looks like an awesome tutorial but I'm really looking for something that focuses on VIVE (eventually), hopefully that's the plan. Thanks!

Hi,

Thanks for the compliment, unfortunately, my current plan is to do mobile VR because it is more accessible to me at the moment.

However I do have hopes to either get the Vive/Rift in the future and play around with them although no promises on when that will be.

Posted (edited)

NP, still super super awesome/helpful and I gotta say you have a real gift for this kinda thing. Greatly enjoying the series so far... thank you so much for doing this !

Oh and maybe consider doing a Udemy.com or similar online class, you could fund a nice VIVE setup with your earnings.

Edited by evo_9

## Create an account

Register a new account

• ### Similar Content

• 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:
https://www.macstop.com/games/dirt-bike-extreme/

• Continuing to work on “Eldest Souls” (first article here!), I’ve begun familiarising myself with the workflow between Fmod and Unity, and the integration system. I know much of this will be pretty obvious to most, but I thought I’d share my thoughts as a complete beginner learning the ropes of sound designing.
The library of sounds that Fmod provides has been very useful, at least as reference points. I’ve still kept to my ethos of producing the sounds myself as much as possible. Having said that, Fmod gives you 50 free sounds with your download, and I’ve used a wooden crate smash, a drawbridge and electricity sound you can hear in the foley video below.

The thing i found most useful was witnessing changes i made in Fmod being realised instantly in Unity. If a volume needed changing, or the timing of one of my effects was off, i can literally switch to Fmod and then back to Unity and immediately see the result of my alterations. It also seems apparent that using middleware such as this (or i've heard Wwise is also equally intuitive) grants the developer, and myself included, a great deal more flexibility and opportunity to edit sounds without going all the way back to a DAW, and bouncing down again. Needless to say, my workflow is so much faster because of it.
I've also loved the randomised feature of Fmod, whereby any sound can be made to sound slightly different each time it is heard. Taking a footstep recording i made for example, I was able to add further authenticity of uneven footsteps by randomising the pitch and volume of each playback.

I used this technique when creating footsteps for the first major boss in the game called "The Guardian". A big, over-encumbered husk of a monster. I also had fun rummaging through the garage for old tools and metal components for the “Guardian” (the first boss) footsteps. See below!

I also created a sword attack for our player, trying to sound different from the generic “woosh” I see in so many video games. I used a very “sharp” and abrasive sound to differentiate him from any enemies.

On another note, I recently upgraded my microphone to a Rode NTG2 shotgun, which has been phenomenal. I haven’t had to worry about noise interfering with the clarity of my objects, whereas before with the sm58 I had to be clever with my EQ and noise reduction plugins.
Important to note again that this still a “cheap” mic in comparison to most other products on the market, and all in all my entire setup is still very simple and affordable which I’m quite proud of. I’ve seen many musicians spend heaps of money on gear they don’t necessarily need. I much prefer being resourceful with less equipment, than to have more than I can understand or remember how to use.
It’s forced me to understand every aspect and capability of my tools, which I believe is a principal that can be applied to any discipline.

I have more fun little sound effect videos on my Instagram for those interested, where I post regular updates. Thanks for reading! (if you’ve made it this far)

www.sergioronchetti.com
INSTAGRAM
fallenflagstudio.com

• BASICS IN SOUND DESIGNING FOR VIDEO GAMES

Recently I joined the talented team at Fallen Flag Studio as the composer for their latest release "Eldest Souls" which consequently lead me into a field I have always dreamt of trying - sound design!
Having no prior experience, I began watching a few online tutorials (if you want to learn from anyone make it Akash Thakkar from "Hyper Light Drifter"... what a guy!) and basically just testing stuff out i found around the house. Luckily my dad has a garage FULL of random crap to use.
Before i continue, it's important to note that i DO NOT have fancy equipment, meaning anyone can try this. (my equipment is an sm58, focusrite scarlett interface and Logic Pro X plugins... that's it!)
I started basic with some footsteps, which weren't all too difficult. Then I moved on to projectiles and a spear attack one of the bosses has. Below are a couple super short videos on my resulting attempts.

Amazing how great a banjo sounds for that typical "woosh" sound! And if you're wondering, the paper was added to give some texture to the jab.
I could be finding a lot of these sounds in libraries online (like the built-in ones that come with Fmod and Unity) but I've chosen not to, in order to produce authenticity and hopefully a more unique gameplay experience for players when the final product is put together.

P.S. if you'd like to try the game and hear my hard work we'll be at EGX and several other conventions later this year, soon to be announced! Thanks for reading!
www.sergioronchetti.com
fallenflagstudio.com

To those interested, there's an Alpha trailer of the game in question below.

×