In this article we will learn about Crowhille – Detective Case Files VR | VR Game Case Study by NipsApp
By NipsApp Game Studios | Trivandrum, India
When Saturn VR first described the concept to us, we knew two things immediately.
One: the creative vision was strong. A gothic horror detective mystery set inside a Victorian asylum in Wales. Hidden object mechanics reimagined for room-scale VR. Supernatural encounters. A real narrative with real characters and a mystery that rewards patient exploration.
Two: building it properly was going to be harder than it looked.
Hidden object games had essentially never been done in room-scale VR before. The genre was entirely flat-screen. Translating it into a physical VR experience — where players reach out, pick up objects, search spaces with their bodies — required rethinking the core mechanics from scratch.
That problem interested us. We took the project.
This is the full case study of how we built Crowhille – Detective Case Files VR from concept to Steam launch. What the client needed, what we built, what went wrong, what went right, and what the results looked like.
About the Game
Crowhille – Detective Case Files VR is a room-scale VR horror mystery published on Steam on September 10, 2021.
Players take the role of a detective assigned by King George IV to investigate Crowhille Asylum — a derelict Victorian institution in Wales with a dark and violent history. What begins as a routine investigation becomes something else entirely. The asylum is not empty. Spirits inhabit the corridors. The Crowhille Three — three malevolent supernatural entities — are active. Dr. Hereford and Nurse Jasmine are locked somewhere inside. You are going to find them.
The genre is hidden object mystery wrapped inside a VR horror experience. Players physically explore environments, find and interact with objects using tracked controllers, solve puzzles, collect keys, and piece together the story of what happened inside Crowhille.
Current Steam status:
| Metric | Result |
|---|---|
| Rating | Very Positive |
| Positive Reviews | 89% |
| Total Reviews | 92+ |
| Estimated Owners | 50,000 – 100,000 |
| Price | $5.99 |
| Platform | SteamVR (PC VR) |
| Release Date | September 10, 2021 |
The Client Brief
Saturn VR came to NipsApp Game Studios with a detailed creative vision and a clear set of technical requirements.
What they needed:
- A room-scale VR horror game for Steam
- Victorian asylum setting with genuine atmospheric depth
- Hidden object mechanics redesigned for physical VR interaction
- Supernatural enemy encounters
- SteamVR compatibility across multiple PC VR headsets
- Full Steamworks integration (achievements, cloud saves)
- Launch price accessible to the indie VR market
What made this brief challenging:
The hidden object genre had no meaningful VR precedent. Every existing hidden object game was flat-screen point-and-click. The team could not reference what existed. We had to design new interaction patterns for an old genre in a new medium.
VR horror adds performance constraints that flat-screen horror does not have. Frame rate drops below 90fps in VR cause nausea. A complex gothic environment running multiple dynamic lighting systems, volumetric fog, particle effects, and spatial audio had to maintain frame rate targets across a wide range of PC VR hardware.
Atmosphere in VR works differently than on flat screens. Directors can frame shots. Players cannot be directed. Every inch of every environment had to hold up from every angle because players look everywhere.
These were the problems we designed solutions for.
Our Approach
Pre-Production: Decisions Before Development
We spent three weeks in pre-production making design decisions before writing code or building assets.
This is how we work. Wrong decisions made in pre-production cost exponentially more to fix mid-development. Getting core decisions right at the start is the most efficient thing a VR development team can do.
Key decisions locked in pre-production:
Room scale throughout, not fixed-position viewing. Some VR experiences use fixed viewpoints or teleport-only movement. For a detective investigation game, fixed viewpoints would have felt passive. You needed to physically be in the asylum — walking corridors, crouching to look under furniture, moving through spaces deliberately. We committed to room scale throughout. Minimum play space: 2 meters by 1.5 meters. This shaped every environment design decision that followed.
VR-native interaction only. No 2D menus. No point-and-click interfaces. Every interaction would use tracked controllers in physical space. Pick up an object by reaching for it. Examine it by holding it close and turning it in your hands. Combine items by bringing them physically together. This was more development work. It was absolutely the right decision for the experience.
Atmosphere as the primary design value. Hidden object mechanics, puzzles, and encounter systems would serve the atmospheric horror experience. Not the other way around. When any decision arose between gameplay efficiency and atmospheric quality, atmospheric quality won. This was agreed in pre-production so there were no debates about it during development.
Victorian Gothic as a specific visual language. Not vaguely dark. Not generic horror. Victorian Welsh Gothic specifically — stone architecture, candlelight, period medical equipment, decay with a specific texture. We built a visual reference library before any 3D work began. Every asset and environment decision referenced it throughout production.
What We Built
The World
Crowhille Asylum was built in full 3D across multiple interconnected areas. Each environment was designed as a room-scale physical space, not a backdrop.
The Detective’s Office The starting point before the asylum. Players establish context, handle physical objects on the desk, read correspondence, and open the door to Crowhille. The first interaction in the game. We invested significant attention here because first impressions in VR establish the player’s expectations for everything that follows.
The Asylum Grounds Victorian exterior in deliberate decay. Overgrown paths, broken windows, the iron gate. Designed specifically to build dread before the player enters the building. The asylum has to feel wrong before you are inside it.
The Asylum Interior Dark corridors, patient wards, administrative offices. The majority of the hidden object gameplay happens here. Objects distributed throughout real 3D space — on shelves, under furniture, inside drawers, on windowsills. Players have to physically search the space. Crouching, lateral movement, close approach to examine details. The three-dimensionality of the search is what separates this from flat hidden object games.
The Underground Laboratory The deepest environment. Visually distinct from the floors above — ethereal, architecturally strange. The Crowhille Three are encountered here. This is where the chanting originates. This was the most technically demanding environment in the game and the most important to get right atmospherically.
Core Systems
Physical Interaction System
Built from scratch for this project. Every interactable object responds to tracked controller input with behavior appropriate to its physical nature. A key feels different to handle than a medical file. A glass bottle responds differently to being set down than a leather-bound journal.
The grab detection radius was calibrated through user testing. Our initial radius was too small — 6 of 8 test users missed grabs in the first five minutes of play. Frustrating in any game. Fatal in a horror game where tension depends on responsive controls. We adjusted the radius and ran additional testing until grab success rates were comfortable without feeling artificially assisted.
Examination mode activates when a player holds an object within close range of their headset and holds it steady. Close-up audio and haptic cues signal the transition. Some objects reveal information in examination mode. Some puzzle solutions require examining objects closely.
Hidden Object Detection System
Traditional hidden object detection is a raycast from camera to object. In VR this required complete reimplementation. Objects exist in 3D space. Detection had to work from any approach angle, any reach distance, any controller orientation.
Objects were placed deliberately to reward physical exploration. Nothing in obvious sightlines. Objects placed behind larger items requiring lateral movement, on floors requiring a downward look, inside open containers requiring close approach, at the backs of shelves requiring deliberate searching. Players have to use their bodies to find things. This is a better version of hidden object gameplay than the flat-screen genre offers.
Spatial Audio Architecture
Audio was treated as a primary atmospheric tool, not a support layer.
Every room in the asylum has its own acoustic signature. The patient ward sounds different from the administrative office. The laboratory has a different acoustic character from the entry hall. Sounds behave differently in different spaces. Players feel acoustic transitions as they move between environments.
The chanting from the underground laboratory is audible — faintly — from the floors above. By the time players reach the laboratory, the audio has been building subconsciously for 10 to 15 minutes of gameplay. Dread established entirely through audio before any visual encounter.
Supernatural encounter audio went through six iterations. We tested each version with fresh users, measuring reported fear levels before, during, and after encounters. Version one was jump-scare focused — effective during encounters, neutral before and after. Version six delivered a full audio arc: distant warning signs building for 30 seconds before visual appearance, encounter audio during, residual echo lingering after. Fear scores moved from 6 out of 10 to 8.6 out of 10 between version one and version six. Same visuals. Same enemy models. Same encounter timing. Audio alone drove the difference.
Technical Implementation
| Component | Implementation |
|---|---|
| Engine | Unity 2019.4 LTS |
| VR Framework | SteamVR SDK (OpenVR) |
| Input System | SteamVR Action-Based Input |
| Audio | Unity Audio + Steam Audio (spatial) |
| Lighting | Hybrid baked/dynamic |
| Physics | Unity PhysX |
| Platform | Steam (Steamworks SDK) |
| Headset Support | Index, Vive, Oculus via SteamVR, WMR |
Lighting approach:
The most expensive element in atmospheric VR environments is dynamic lighting. Every dynamic light source costs GPU time. In VR that cost is doubled by stereo rendering.
Our solution was a deliberate split. Architectural surfaces — walls, floors, ceilings, permanent fixtures — were lit with baked lightmaps using Unity’s Progressive Lightmapper. Zero runtime cost. High quality results. Dynamic lighting was reserved for interactive elements where real-time response mattered: candles that could be extinguished, the player’s light source, supernatural encounter effects.
This approach gave us the visual quality of fully dynamic lighting at a fraction of the runtime cost.
Underground laboratory optimization:
The laboratory was our most expensive scene. Initial profiling showed it running at 54fps on minimum-spec hardware. Target was 90fps. We were 40% below budget.
Profiling identified the causes: volumetric fog (14ms GPU), particle systems (8.6ms GPU), a dynamic light driving shadow calculations every frame (6.1ms GPU), too-high draw calls (312), and shadow calculation overhead (4.8ms CPU).
We addressed each systematically. Replaced Unity’s volumetric fog with a custom screen-space shader implementation — GPU cost dropped from 14ms to 3.1ms. Audited and optimized all particle systems — 8.6ms to 2.4ms. Rebuilt the ritual circle lighting as baked base plus low-intensity dynamic overlay with shadows disabled — 6.1ms to 0.8ms. Aggressive geometry batching and GPU instancing reduced draw calls from 312 to 118.
Post-optimization: 87fps on minimum-spec hardware. Within target.
Multi-Headset QA
SteamVR compatibility across multiple headset configurations is one of the most underestimated challenges in PC VR development. Writing once and assuming the SteamVR abstraction layer handles everything is how studios generate negative reviews from a significant portion of their player base.
We tested on Valve Index, HTC Vive, Oculus via SteamVR, and Windows Mixed Reality devices throughout QA. Issues we found and fixed:
Windows Mixed Reality controller binding conflict. WMR controllers have both a trackpad and thumbstick. Our default bindings caused both to trigger overlapping actions. Menu navigation unintentionally triggered teleport inputs on WMR hardware. Fixed with a separate WMR binding configuration. Three days.
AMD GPU rendering artifact. A specific combination of our baked lightmaps and custom fog shader produced visible banding artifacts on AMD GCN architecture GPUs. NVIDIA and newer AMD hardware were clean. Root cause: shader precision. Modified fog shader from half to full float precision. Artifact resolved. Four days to diagnose, one day to fix.
Physics instability on high-refresh-rate displays. On Valve Index running at 144Hz, released objects occasionally had unpredictable physics behavior. Cause: physics calculations tied to Update() instead of FixedUpdate(). At 144Hz the Update() frequency was inconsistent with the physics timestep. Fixed by moving interaction physics code to FixedUpdate(). Two days.
Spatial audio occlusion inconsistency on Vive. Steam Audio’s occlusion behavior differed between Vive and Index setups. Audio that should have been occluded by walls was audible on some Vive configurations. Fixed with adjusted Steam Audio settings and manual occlusion handling for the most critical atmospheric sounds. Five days.
QA phase total: five weeks. Every day of it was necessary.
Results
Crowhille – Detective Case Files VR launched September 10, 2021.
Current Steam performance:
Very Positive rating. 89% positive across 92+ reviews. 50,000–100,000 estimated owners.
Selected player feedback:
“The physical searching in VR feels completely different to flat hidden object games. You actually have to look.”
“Atmosphere is exceptional. You genuinely feel like you are in a place you should not be.”
“Audio design is the best I’ve encountered in a VR horror game. The asylum feels alive.”
“Runs smoothly on my 1070. Atmospheric and polished for the price.”
The feedback validates the core development decisions. The VR-native interaction design worked — players noticed and appreciated the difference from flat hidden object games. The atmospheric investment in audio was noticed specifically and repeatedly. Performance held on hardware below our minimum specification target.
What We Learned
VR genre translation requires native rethinking, not porting. The hidden object genre in VR is not the hidden object genre with VR controls attached. It is a different experience. Physical searching of a three-dimensional space, reaching and picking up, turning objects in your hands — these are not equivalent to clicking items in a 2D scene. We designed for the difference rather than minimizing it. That is why the mechanic worked and why players noticed it.
In VR, performance is atmosphere. A dropped frame in a horror game breaks the horror. Not slightly disrupts it. Breaks it entirely. Performance had to be a first-class design concern from the start of production, not an optimization pass at the end. The work we did in pre-production defining the lighting approach, the work we did in the laboratory scene optimization, and the five weeks of QA were all atmospheric investments as much as they were technical ones.
Room scale demands real environmental design. When players can physically walk through a space, environments have to hold up at every scale. Details visible only at screenshot distance fail at close range. Proportions that look correct from one angle look wrong from another. Room scale VR environment design is closer to physical set design than to traditional game level design. We built Crowhille to be walked through, not photographed.
Multi-headset testing is continuous, not terminal. The headset-specific bugs we found in QA week five would have been cheaper and faster to fix if we had found them in week six of development. Multi-headset rotation testing should begin with the first complete builds and continue through every milestone. Not just in a dedicated QA phase at the end.
Audio is a development priority, not a delivery item. Games treat audio as something delivered at the end. In VR horror, audio is primary. The six iterations of supernatural encounter audio were as important as the six iterations of encounter encounter design. Player experience is determined by both in equal measure.
About This Project
Client: Saturn VR Developer: NipsApp Game Studios Published: Steam, September 10, 2021 Engine: Unity Platform: SteamVR (PC VR) Genre: VR Horror, Hidden Object, Mystery, Puzzle
Steam Page: Crowhille – Detective Case Files VR
Build Your VR Game With NipsApp
NipsApp Game Studios is a full-cycle game development studio founded in 2010 and based in Trivandrum, India.
We build games in Unity and Unreal Engine across mobile, PC, VR, AR, multiplayer, web, and blockchain platforms. We have shipped VR games for Steam and Meta Quest. We understand VR-specific design challenges, multi-headset compatibility, SteamVR platform requirements, and the performance optimization that separates good VR experiences from great ones.
Crowhille is one example. We have more.
If you have a VR game concept and need a development partner who has shipped in this space, we would like to hear from you.
NipsApp Game Studios | Trivandrum, India | Founded 2010 Unity · Unreal Engine · Mobile · PC · VR · AR · Multiplayer · Web · Blockchain
View on Apple Maps 
View on Google Maps 
