Last updated: 2026-09-23

U
Undergraduate level

Building for Immersive Platforms: Engine Choice and the Risks the Engine Doesn't Handle

Immersive technology" covers more ground than the headset on the shelf suggests. It's useful to place four things on one spectrum, by how much of the physical world a user keeps track of while using them: augmented reality (AR) overlays digital information onto the world a user still sees clearly — a phone camera, a filter, a retail try-on demo; mixed reality (MR) blends the two through pass-through cameras, letting a user reach for a real coffee cup while a virtual window floats beside it; virtual reality (VR) replaces the physical world with a computer-generated one entirely, usually for one user at a time; and immersive virtual worlds (IVWs) — Horizon Worlds, VRChat, Rec Room — add other people's avatars into that generated space, with or without a headset at all [1]. The terminology keeps shifting under this — Apple calls its headset "spatial computing" specifically to avoid the VR association, Qualcomm prefers "extended reality," Meta prefers "metaverse" — which is worth knowing before assuming a job listing or a paper means the same thing your course does by any of these words.

Three Engines, Three Different Bets

Engine Architecture covers what a general-purpose engine is built from; this page is about choosing one off the shelf to build an immersive experience on top of, which is the decision most student and indie projects actually face. Three engines dominate that choice, and they represent genuinely different trade-offs rather than cosmetic branding differences:

  • Unity (C#) has the deepest install base for VR and mobile AR specifically, a large asset store that shortens prototyping time considerably, and an XR Interaction Toolkit that handles a lot of the tedious controller/hand-tracking plumbing for you. It's the engine most likely to already have a package for whatever headset you're targeting.
  • Unreal (C++, or Blueprints for visual scripting) is the industry standard for high-fidelity real-time rendering, which matters directly for VR: a dropped frame in a headset doesn't just look bad, it can make a player physically sick. Unreal's OpenXR support and its rendering headroom make it the more common choice for high-end simulation and location-based VR rather than mobile-first experiences.
  • Godot is open source, node-based, and — per Engine Architecture's own point about reading a shipped engine's source — the easiest of the three to actually look inside, which matters if the point of the exercise is learning how an engine works rather than only shipping a product. Its OpenXR support is newer and thinner than the other two, which is itself a useful lesson in the trade-off between a mature ecosystem and an inspectable one.

None of these choices resolves the problems below. They're properties of what you're building, not of which engine you built it in.

The Data Problem the Engine Doesn't Solve

A VR or MR headset collects categorically more data than the phone or laptop it's replacing: physiological data from head and eye movement, environmental data from the cameras that let pass-through and room-scale tracking work at all, and positional data on top of both [1]. Once that data exists, an Ada Lovelace Institute report on the resulting harms found it accumulating under the same "loss leader" business model that already governs targeted advertising elsewhere, with minimal consent friction for using it to train other systems — Meta's own privacy policy for its Ray-Ban smart glasses, for example, requires a user to manually delete voice recordings if they don't want them used for AI training, rather than opting in [2]. Whether you build in Unity, Unreal, or Godot, the moment your project logs eye-tracking, hand-tracking, or room-scan data for anything beyond the current frame's rendering, you have taken on a data-protection question a game engine's API does not answer for you — see Legal Framework in Computing for the general obligations that apply the moment you are processing anyone's personal data, immersive or not.

The Embodiment Problem

A second risk is specific to immersive technology in a way ordinary online harassment isn't: harm that has a physical component because the user's body is, in a real sense, inside the interaction. The same report documents "new forms of targeted harm enabled by embodied interactions, including stalking and assaults with physical impacts," and a specific, low-effort attack against users with epilepsy — deliberately triggering strobing effects — that a flat 2D interface simply doesn't expose in the same way [2]. Anyone within range of a headset's cameras who never opted into anything can also end up captured and profiled — a "shadow profile" built from bystander data the platform never asked their permission for. If a student project involves any multiplayer or shared-space component, this is the point at which "who can approach whom, and how close" stops being a design nicety and becomes a safety requirement to design in from the first prototype, not a moderation feature to bolt on before a demo.

The Accessibility and Wellbeing Problem

The same report catalogues cyber-sickness, hardware weight and heat, and awkward input methods as some of the most common reasons real users stop using a headset at all — not exotic edge cases, but the ordinary experience of a large share of first-time users. Addictive-by-design patterns (customisable avatars, virtual assets, hyper-personalised content) drew a blunter comparison from one interviewed user of an immersive virtual world: "they are like cigarette companies" [2]. Comfort options (seated mode, snap turning, a vignette during fast movement), genuinely optional data collection, and colourblind-safe, captioned UI are not accessibility features to add once the "real" build is finished — they are the difference between a build a representative range of people can actually use for more than five minutes and one that can't leave a demo booth.

The Market Is Smaller Than the Pitch Decks

It's worth building with realistic expectations about who will actually use the result. A companion report tracking adoption found Meta's Horizon Worlds reaching only about half its projected 2022 user numbers, venture capital funding for AR/VR startups falling by more than 90% between 2022 and 2023, and Meta Quest headset sales themselves down 16% year-on-year as of November 2024 [3]. None of this means the technology is a dead end — display resolution alone has gone from the Virtual Boy's 384×224 pixels in 1995 to the Vision Pro's 3800×3000 in 2024 — but it does mean "everyone will be doing this in VR soon" is not a safe premise for a project brief. The report's own read is blunter: immersive technology is "probably gonna remain quite a niche technology" for the foreseeable future, concentrated in specific enterprise and training use cases rather than displacing general computing the way some 2021-era pitches assumed.

What This Means When You're the One Building It

  • Collect only what the interaction actually needs. If a mechanic doesn't use gaze direction, don't log it just because the SDK makes it easy to.
  • Design proximity and consent into multiplayer spaces from the start, not as a moderation patch after the first uncomfortable incident.
  • Treat comfort and accessibility options as core scope, sized and tested the same way a core mechanic would be, not as stretch goals.
  • Be specific about who the experience is for and what it does that a cheaper, lower-friction tool doesn't — one interviewee's own challenge to the field applies just as well to a student pitch: "what are these immersive tools offering that low data intensive tools don't do?" [3]
  • Expect convergence with AI — over half of experts interviewed for the explainer above raised it unprompted, usually around scene understanding, avatar generation, or NPC behaviour — and treat that combination as inheriting the governance questions of both fields, not neither; see AI Governance for the state of oversight on the AI side of that combination specifically.

References

  1. Rincon, C., & Perez, J. (2025). What are immersive technologies? Ada Lovelace Institute, 5 March 2025. https://www.adalovelaceinstitute.org/resource/immersive-technologies-explainer/
  2. Rincon, C., & Perez, J. (2025). Let's get real: The benefits and risks of immersive technologies for impacted communities. Ada Lovelace Institute, 30 October 2025. https://www.adalovelaceinstitute.org/report/lets-get-real/
  3. Rincon, C., & Perez, J. (2025). Reality check: Key trends in the development and adoption of immersive technologies. Ada Lovelace Institute, 9 September 2025. https://www.adalovelaceinstitute.org/report/reality-check/