The idea came from an extremely serious game of hide and seek with my cousins. We were adults, which made it ridiculous, but also strangely perfect. Someone was hiding behind a couch in plain sight, surviving only because the seeker did not look carefully enough.
That made me wonder: what if looking carefully was not enough?
What if the seeker could not freely look around the room? What if they could only see the world through their phone screen, while virtual obstacles blocked parts of their view?
That became the core idea behind AR Hide and Seek: a local multiplayer hide and seek game where 2-5 players use the space they are already in. The hiders physically hide somewhere in the room, while the seeker views the environment through an iPhone. The phone fills the space with digital clutter, making familiar rooms harder to read.
One phone. One seeker. Real hiding places. Virtual obstacles.
Why LiDAR?
LiDAR on iPhone Pro models gives the phone a real-time depth map of the environment, with centimeter-level understanding of the space around it. That means virtual objects can be placed in ways that respect real-world geometry: a crate can sit on the floor, a wall can align with an actual wall, and obstacles can feel like they belong in the room rather than floating on top of it.
For a game where the virtual environment needs to feel like it genuinely fills the space, that difference matters immediately. Without reliable depth information, objects can drift, clip, or hover in ways that break the illusion.
The tradeoff is device requirement. LiDAR is only available on iPhone Pro models, which narrows the audience. But for this game, the better AR experience was worth it. The seeker sees a version of the room cluttered with virtual obstacles. The hiders are still physically hiding behind real furniture; the phone does not make them disappear. It simply makes finding them harder.
Designing the Core Loop
The mechanic is simple on paper, but it took a surprising amount of tuning to make it feel fair.
A round works like this:
- Hiders get a short window to move into position.
- The seeker waits with their eyes closed while a countdown plays.
- The seeker scans the room through the phone.
- Virtual obstacles fill the mapped space.
- The seeker finds and tags each hider through the AR view.
The first playtest revealed that the obstacles were too effective. With enough clutter, the seeker was basically navigating blind. I reduced the obstacle density, adjusted the setup timer, and kept testing until the game felt challenging without becoming frustrating.
Balancing an AR game is weirdly similar to balancing a board game. A lot of the work comes down to tweaking numbers, watching how people behave, and adjusting after each round.
The scanning phase needed its own attention. Before the round starts, the seeker slowly pans the phone around the room so the AR system can understand the space. The more thoroughly the room is scanned, the more convincingly the obstacles can fill it.
To make that process easier, I added a scanning UI with progress indicators, directional cues, and a radar-style animation. The goal was to guide players without making the setup feel like homework. Once players see the obstacles appear in the room, the concept clicks quickly.
Keeping It Local
AR Hide and Seek is local multiplayer: one device, passed between players. That decision was intentional from the beginning.
Real-time AR multiplayer over a network is a very different product. Every device would need to agree on where “here” is in physical space, compensate for latency, and maintain a shared session. That is a fascinating problem, but it was not the right problem for version one.
The single-device model keeps the experience simple. The seeker holds the phone. The hiders go hide. There is no account setup, no pairing, and no waiting for connections. A round can start in under 30 seconds.
The cost is that the game is inherently pass-and-play. A future version could explore shared AR sessions across multiple devices, but for the first release, one device let me focus entirely on making the core AR mechanic work.
Building It Solo
When I started, I had no prior coding experience. Everything I know about making this game came from building it: trial and error, a lot of reading, and mistakes that sometimes cost me days before I understood what had gone wrong.
Unity helped because it gave me a visual environment to work in. When I was still learning how the pieces connected, being able to see objects, cameras, scenes, and interactions made the process much less abstract.
The hardest part was not one specific technical problem. It was managing scope.
Solo development means every decision about what to build is also a decision about what not to build. The temptation to add more is constant: more obstacle types, more game modes, more settings, more effects. But every feature is time, testing, bugs, and polish that you are responsible for alone.
I cut more ideas than I shipped, and the game is better for it.
The features I am proudest of are the ones that directly support the core loop: the radar-style scanning animation, the proximity warning that pulses when the seeker gets close to an obstacle, and the countdown audio that builds anticipation before the round starts.
None of these are flashy by themselves, but together they make the game feel more complete.
The App Store Submission
Submitting to the App Store as a solo developer is its own ritual. For AR apps, the review process can be especially sensitive because the experience depends on hardware, movement, and the physical environment.
My approach was to make the review process as clear as possible.
I included screenshots showing the AR view in action, with real rooms and virtual obstacles visible on screen. I added a short demo video in the review notes showing a complete round, about two minutes of footage from setup to gameplay. I also made the LiDAR requirement explicit so reviewers would know to test the app on a supported device.
The first submission was approved without issues. Review took about 28 hours.
The biggest lesson was that review notes are not just a formality. For hardware-dependent apps, they are part of the product handoff.
What I Would Do Differently
The scanning UX is the roughest edge.
New players do not instinctively know how important scanning is before the round starts. I have watched players rush through the scanning phase and then wonder why the obstacles feel sparse. The room fills in gradually as the space is mapped, so if the player starts too quickly, the initial layout can look thin.
A more guided first-run experience would help solve that.
I would also think about content variety earlier. The first version shipped with a small set of obstacle shapes. Adding more variety after launch meant revisiting an asset pipeline I had not fully designed for scale.
The lesson is simple: design your content system before you need it to grow.
The third thing I would change is playtesting. Most of my early testing was with people who already understood the concept because I had explained it to them. When I later gave the game to people with no prior context, they revealed friction points I had completely missed.
Test earlier with people who are coming in cold.
What Is Next
AR Hide and Seek is live on the App Store, and I am continuing to refine it through small updates.
The next project I am working on is AR Shadow Tag, which builds on some of the same AR foundations but takes the idea in a different direction. More on that when it is closer to ready.
If you are building AR games for iOS, experimenting with LiDAR, or making your first game as a solo developer, feel free to reach out. I am always happy to compare notes with people working on similar ideas.