What VR interaction design keeps getting wrong - Writing

I’ve been using Unity since 2016 and building for VR since 2018. Some mistakes have been made the whole time. These are the ones I keep running into.

The player’s body is an input device you don’t control

In a flat game, input arrives through a device you specified. In VR it arrives through a person in a room, who will do things your game didn’t offer. They’ll stand up when you assumed they were seated. They’ll put a hand through a table. They’ll drift across the play space until the floor is somewhere else.

None of these are rare. On Memoreum the game recalibrates the player’s height automatically when the camera drops too close to the floor, and holsters and pouches can be moved to fit the player’s body. Each of those is a small system, not a setting.

Scripts assume the player knows where to stand

This one comes from working with writers. A scripted sequence is written by someone imagining a player who knows exactly where to hide, which way to look and when to move. A real player in a headset knows none of that, and can’t be pushed into position the way a flat-screen camera can. On Memoreum a fair amount of my time went into making sure those moments still worked when the player did something unexpected - giving them more room, clearer cues, or a sequence that waits for them. The writing usually survives; it just needs to tolerate a player who isn’t on their mark.

Discontinuous movement breaks code that doesn’t know about VR

Trigger volumes assume things move continuously. Something enters, something leaves, you get both callbacks. Teleport locomotion breaks that: the player stops being in one place and starts being in another. Unity doesn’t raise a trigger-exit event when that happens, so whatever the volume was doing - a slow zone, a damage region, an audio state - stays on. On Memoreum the teleporter keeps its own record of which volumes the player was in and sends the missing events itself.

The wider point is that a lot of engine and middleware code assumes things move. Whenever you add a way of moving that isn’t movement, it’s worth asking what else assumed otherwise.

Left-handed support is an architecture decision

Roughly one person in ten is left-handed, and plenty of VR games leave them out. Part of the reason is that doing it properly isn’t a toggle. Every weapon, tool, holster and grab point needs a mirrored counterpart, and mechanisms with real handedness, like a break action or a revolver, need checking after the mirror or they animate wrong. On Memoreum it’s one setting, but behind it every gun has its own left-handed handling.

Decided at the start, it’s a modest constraint on how you author interactive objects. Retrofitted at the end, it’s a large job, which is usually why it doesn’t happen.

Comfort options aren’t extras

Snap turning or smooth. Teleport or stick. Seated or standing. These often get filed under accessibility and buried in a menu, but for a meaningful share of players they’re the difference between a game being playable or not, and someone who feels ill in the first two minutes rarely goes looking for a fix. Which option should be the default depends on the game; what matters most is that players can find the choice before they need it.

Physical objects cost you in systems that look unrelated

If a magazine is a real object the player pulls from a pouch and pushes into a gun, that’s a great interaction and worth doing. But understand what you’ve taken on.

Your ammunition count now exists in several places - the pool, a magazine in someone’s hand, the round in the chamber - and they all have to agree. Your save system has to restore not just “the player had a shotgun” but the state of that shotgun: what was loaded, whether the action was open, where it was holstered. On Memoreum that means re-spawning each gun, then driving it back to its saved state in timed steps, then re-checking the ammo totals over several frames because equipping a gun changes them.

None of that is visible to the player, and all of it is the real cost of the interaction being physical. It’s usually worth paying - just plan for it from the start.

The common thread

Most of these come back to the same thing: VR puts a real person, with a real body, inside something that was mostly designed on a flat screen. The mistakes that last are the ones where the design still assumes a player who stands where they’re told, moves only in ways the code expects and holds things with the hand the developer happens to use. When I’m planning a VR system now, the first question I ask is what a real person in a real room will do that the design hasn’t allowed for, and whether the system still holds up when they do it.