FEB 2026
XR SWITCHCAR
The Challenge
The brief was not your typical school assignment. Build a VR/MR game for children with motor disabilities, from scratch, using a Meta headset and Unity. Make it functional, make it accessible, and make it actually fun to play. Not fun in theory. Fun in the way that a child picks up a controller and does not want to put it down.
This was also my first project in the Digital Innovation program, which meant jumping straight into the deep end before I had fully figured out where the pool was.

The Scope
This was an accessibility-first project, which meant every design decision had to be thought through with a specific user in mind. The core interaction had to work with minimal motor input. One button starts and stops the car. One switches the model. One honks. One disables the track entirely. Simple on paper, but getting simplicity right is its own kind of hard.
The game uses the headset's passthrough cameras to scan the physical environment in real time, detect a flat surface like a table, and procedurally generate a track around it. The world the children play in is their actual world, just with a tiny car racing around it.
What I Built
Two game modes. The first is the structured track mode, designed for children with more limited motor control. The car follows a generated path around the scanned surface, and the player controls it with single-button inputs. The second is free roam mode, for children with more advanced motor skills, where the car is let loose on the table to go wherever it wants and knock things over.
That second mode turned out to be unexpectedly popular with a demographic I did not design for: adults. Turns out picking up a tiny MR car with your actual hands and using it to send a pen flying off a table is universally enjoyable. Accessibility feature became a party trick. I am calling that a success.
My Role
I built everything. The code, the 3D assets, the car models, the track elements, the environment pieces. Having a background in 3D modelling meant I could close the loop between what the game needed visually and what actually ended up in the scene without any back and forth.
The coding side was a genuine stretch. I had done a game jam a couple months before this, which gave me a rough foundation in Unity, but MR development is a different animal. Spatial anchoring, plane detection, procedural track generation around a dynamically scanned mesh. None of that is covered in a beginner tutorial. A lot of it was reading documentation, breaking things, and figuring out why.
What It Demanded
Accessibility work has a higher bar than regular product work in one specific way: you cannot just build something and assume it works. The user population this was designed for has real constraints, and if the interaction model is slightly off, it stops being playable entirely. That kept the design honest in a way that most projects do not.
It also had to be genuinely enjoyable, not just technically functional. A game that works but is not fun is a failed game. Especially when your target audience is a child who has seen better.
What It Proved
VR and MR development, procedural generation, spatial computing, custom 3D assets, and an accessibility constraint running through all of it. For a first project in the program, it pulled from a lot of different skill sets at once and asked them to produce something coherent. The fact that it did, and that it was actually fun to use, is what made it worth doing.
Also, honking a tiny car in mixed reality never gets old. That one is not up for debate.
Also here is the link to the LinkedIn post: