The first time I shipped a VR build to a headset I had no idea how much of the work happens outside the headset. You spend maybe a fifth of your time in goggles and the rest fighting with input mappings, render scale, and SDK version mismatches. So this is the guide I wish someone had handed me: how the pieces fit together, what to install, and how to get a cube you can grab running on real hardware before the afternoon is over.
What you actually need to start
You need three things. A headset, an engine, and a runtime that translates between the two. That last part is the one beginners skip and then wonder why nothing works. The runtime is the layer that owns the display, the tracking, and the controllers, and your engine talks to it through an API.
For hardware, almost any modern standalone headset will do. A Meta Quest 2 or 3 is the cheapest entry point and doubles as both a PC-tethered device and a standalone Android target. If you have a gaming PC, a Valve Index or any Windows Mixed Reality headset works too. Buy used if you can. The hardware moves fast and you do not need the newest panel to learn.
OpenXR is the thing to learn, not a vendor SDK
For years every headset maker shipped its own SDK, and porting an app from one device to another meant rewriting your input and rendering code. OpenXR fixed that. It is an open standard from Khronos, the same group behind Vulkan, and it gives you one API that targets Quest, SteamVR, Windows Mixed Reality, and most things to come.
My strong advice: build against OpenXR from day one. Both Unity and Unreal support it as a first-class plugin. You will still occasionally reach for a vendor extension to get hand tracking or passthrough, but the core loop of poses, frames, and input stays portable. I have moved projects from Quest to PCVR with almost no code changes because of this, and the one time I built against a proprietary SDK I paid for it later.
Unity or Unreal
This is the question everyone asks and the honest answer is that both are fine. Here is how I decide.
- Pick Unity if you want faster iteration, a gentler scripting model in C#, and the widest pool of VR tutorials and assets. The XR Interaction Toolkit gives you grabbing, teleporting, and UI interaction out of the box. Most indie and enterprise VR ships on Unity.
- Pick Unreal if you need top-tier visuals, you are comfortable with C++ or Blueprints, and your target is a powerful PC or a high-end standalone. Unreal’s rendering is gorgeous but you will fight harder to hit frame rate on mobile-class hardware like the Quest.
I reach for Unity for most prototypes because I can change a value, hit play, and be testing in the headset seconds later. For a cinematic, visually heavy PCVR piece I would consider Unreal. Neither choice is wrong, so do not spend a week agonizing over it.
Setting up a Unity project for VR
Here is the path that works reliably as of this writing. Create a new project using the 3D core template. Open the package manager and install the XR Plugin Management package, then the OpenXR Plugin, then the XR Interaction Toolkit. In Project Settings under XR Plugin Management, enable OpenXR for your target platform and add an interaction profile that matches your controllers, like the Oculus Touch profile or the Index controller profile.
For a Quest target, switch the build platform to Android and set the texture compression to ASTC. For PCVR you stay on the Windows platform. That is genuinely most of the setup. The interaction profiles are the part people forget, and without them your controllers report no input at all.
Your first grabbable object
The XR Interaction Toolkit does the heavy lifting, but it helps to see what a small custom interaction looks like in code. Here is a simple script that snaps an object back to its start position when you let go of it, which is handy for tools you do not want players losing in the void.
using UnityEngine;
using UnityEngine.XR.Interaction.Toolkit;
[RequireComponent(typeof(XRGrabInteractable))]
public class ReturnToHolster : MonoBehaviour
{
Vector3 startPos;
Quaternion startRot;
XRGrabInteractable grab;
void Awake()
{
startPos = transform.position;
startRot = transform.rotation;
grab = GetComponent<XRGrabInteractable>();
grab.selectExited.AddListener(OnReleased);
}
void OnReleased(SelectExitEventArgs args)
{
// Snap home after a short delay so the toss still feels physical
Invoke(nameof(ResetTransform), 1.5f);
}
void ResetTransform()
{
var rb = GetComponent<Rigidbody>();
if (rb != null) { rb.velocity = Vector3.zero; rb.angularVelocity = Vector3.zero; }
transform.SetPositionAndRotation(startPos, startRot);
}
}Drop this on a mesh with a collider and a Rigidbody, add an XR Origin rig to the scene, and you have something you can pick up and throw. Seeing your own hands move a real object in 3D space is the moment VR clicks for most people, so get to it as fast as you can.
The render loop is not like flatscreen
VR renders the scene twice, once per eye, every frame, and it has to hit a hard frame budget. On a Quest you are aiming for 72 or 90 frames per second, and missing it does not just look bad, it makes people queasy. That changes how you think about performance. Draw calls, overdraw, and shader complexity matter far more than on a monitor where a dropped frame is a minor annoyance.
Two techniques save you here. Fixed foveated rendering lowers resolution at the edges of the lens where your eye cannot see detail anyway. Single-pass instanced rendering submits geometry once for both eyes instead of twice. Turn both on early. I have rescued projects that were stuttering at 50 frames just by enabling these and cutting a few real-time lights.
Testing on hardware early and often
The editor preview lies to you. Scale feels different in a real headset, motion that looks smooth on a flat preview can be nauseating in goggles, and text that is readable on your monitor turns to mush through the lenses. Build to the device constantly. With a Quest you can use the Oculus developer hub or just sideload over USB, and on PCVR you can play directly into a tethered headset from the editor.
Comfort is its own discipline, and it is where most first VR projects fall apart. I wrote a whole separate piece on it because it deserves the room. If you are past the setup stage, read VR UX design principles before you design a single movement system, because the choices you make about locomotion and interaction will decide whether people can stand to use what you built.
A realistic first project
Do not try to build a game yet. Build a room. Put a few grabbable objects on a table, add a button on the wall that turns a light on, and make a simple teleport system so you can move around. That tiny scene exercises rendering, input, interaction, and locomotion, which are the four pillars of every VR app. Once that room feels good in the headset you understand enough to start something real.
VR development rewards patience and punishes shortcuts, but the payoff is unlike anything in flatscreen work. The first time a tester reaches out to touch something that is not there and flinches, you will get why people keep building for this medium. Start small, test on real hardware, and respect the player’s comfort from the beginning.