About This Book
This book began as a collection of notes I took during my years as a virtual reality (VR) developer. I got my first headset in 2020 and spent the years that followed building VR commercially. Over that time, a pattern stood out. Most VR applications shared the same fundamental features, but there was little standardization in how those features were implemented, and few of them felt right.
The situation in 2026 has improved only slightly. When you download a VR game from your favourite store, there’s still a good chance that something will feel off the moment you launch it. That something might be:
- You spawn outside the centre of the scene, but your physical space limits your movement.
- Your view is stuck at ground level.
- You start the game facing away from the title screen.
- Grabbing feels unintuitive, and letting go is worse — the release gesture is awkward enough that you nearly fling the controller after the object.
- Throwing items feels unnatural, and objects never land where you expect.
- The locomotion system is either nauseating or frustratingly difficult to learn.
- You reach for an item on your waist, only to have your view blocked by your own virtual chest.
- The menu uses a laser-pointer system that doesn’t work properly because the menu is too far away, causing small hand movements to translate into exaggerated cursor shifts.
And the list goes on.
This doesn’t mean most VR developers lack skill. VR development is still early. Desktop and mobile applications have decades of established conventions; VR doesn’t. Developers overlook details that will be common sense in a few years.
Knowing What You Want
Look back at the list above. Some of those items are real bugs — wrong tracking-origin height, a missed startup recenter. Most are design choices that got made badly: how a grab releases, how throwing predicts velocity, where a menu lives. In either case, the issue is the same. The people building these apps didn’t recognize they were choosing, or didn’t see what the choice would cost.
Knowing what you want sounds like it should come for free. In practice, though, VR is full of small interlocking decisions whose effects are hard to predict. Consider one of the most foundational ones: should the camera be locked to game physics, so the player can’t walk through walls? Or should it always honour the user’s real head pose, even if that means the virtual head clips into geometry? Both are defensible answers, and either one commits you to a long chain of downstream consequences. The rest of the book is full of questions shaped like this one.
The “right” answer to questions like these depends on the application, the player, and a dozen interacting constraints. The tradeoffs are not independent: your answer to one shapes your answers to the next five. You can’t look up the right call in a reference manual. No such manual exists; the industry hasn’t been around long enough to write one.
Cheap implementation hasn’t made design any easier. Anyone with a clear idea can sit down with an AI assistant and produce a working VR app in an afternoon, but the assistant has no opinion on tradeoffs like the one above. It averages over its training data, which includes plenty of apps that get these decisions wrong. The bottleneck has shifted from typing to articulating what you want clearly enough for someone or something else to build. That requires knowing what choices exist, and what each one costs.
By the end of this book you should be able to:
- Recognize the hardware limitations of VR and the design pressures they impose.
- See what each common VR feature is trading off, and why.
- Look at an existing implementation, whether a toolkit, a sample project, or an AI-generated draft, and tell exactly what’s wrong with it.
- Start a VR project from scratch with a design you can defend at every layer.
A Non-Tutorial Approach
As the 101 in the title suggests, this book is structured like a foundations course, not a step-by-step tutorial.
You shouldn’t approach it as a series of build-along instructions. There is no companion repository to clone, no code listings to copy. The value lies in the discussions: the problems each VR design decision is trying to solve, the tradeoffs between approaches, and the reasoning that informs them.
To get the most out of this book, I recommend:
- Reading slowly. The chapters are short, and every paragraph is loaded.
- Engaging with the discussions. Focus on the rationale behind each design choice, and on how you might refine or extend the ideas in your own project.
- Building, if you want to. If you want to implement something the book describes, do it however you like, with any engine and any tools. The design vocabulary transfers.
Prerequisites
Required:
- Familiarity with modern VR hardware and applications. This book frequently references real headsets, controller layouts, and design conventions. If you have never used a VR headset for any length of time, the material will feel abstract.
Helpful but not required:
- Some experience with a 3D game engine (Unity, Unreal, Godot, or similar). The book is engine-agnostic, but knowing how scene graphs, transforms, and game objects work will help you visualize what’s being discussed.
Next: 0.01 – VR In 2026