Fire Escape
|
Published By: Google, Jun 2018 (Daydream release), Ink Stories, Apri 2020, (PC/Steam Release)
Developed By: Inhance Digital, Ink Stories, Frima Tools and Tech: Unity, Visual Studio, C#, Perforce, Adobe Illustrator Platforms: PC/Steam, Google Daydream VR Services Provided:
|
Overview
FIRE ESCAPE is a first-person narrative murder-mystery designed for virtual reality, inspired by Alfred Hitchcock's classic film Rear Window. Initially released as a Google Daydream exclusive before being ported to Steam, the experience seats the player on a Brooklyn fire escape at night, observing a row of apartments across the street while communicating with a narrator through their smartphone. Multiple narrative scenes unfold in parallel within the various apartments, and the player pieces together a mystery by choosing where to look and listen.
FIRE ESCAPE is a first-person narrative murder-mystery designed for virtual reality, inspired by Alfred Hitchcock's classic film Rear Window. Initially released as a Google Daydream exclusive before being ported to Steam, the experience seats the player on a Brooklyn fire escape at night, observing a row of apartments across the street while communicating with a narrator through their smartphone. Multiple narrative scenes unfold in parallel within the various apartments, and the player pieces together a mystery by choosing where to look and listen.
|
Brief
The defining interaction of Fire Escape was a "near-far" mechanic: the player points and clicks their phone at an apartment across the street, and the phone rises toward their view to deliver an up-close, higher-fidelity look and listen at the scene inside. The creative vision for this mechanic was owned by an external narrative team and shaped collaboratively through on-site whiteboard sessions, but those sessions produced intent and feel, not a technical solution. Nobody yet knew how the mechanic should actually work, or whether it could be made to work at all. The hard constraint was performance: this was 2017-era Daydream mobile VR hardware, where maintaining a stable 60 frames per second is non-negotiable, both for immersion and to prevent motion sickness. We had committed to the mechanic before we knew it was achievable - and my job was to discover the real solution by building toward it. |
Role
As Lead Unity Developer, I owned the moment-to-moment implementation and feel of the near-far interaction, working hands-on in Unity and C#. This was a mix of individual contribution, cross-disciplinary coordination, and negotiation: I worked directly with character animators and environment artists to keep their assets within strict performance budgets, and I navigated the inevitable fidelity conversations with the narrative team, who had strong aesthetic and animation ambitions that the hardware couldn't always accommodate. While another member of the team programming team supported the branching-narrative back end using JSON; the interaction layer and performance work were mine. |
Method
We began with the most literal interpretation of the mechanic: rendering the chosen apartment from a closer camera into a RenderTexture, then mapping that texture onto a plane attached to a floating smartphone model positioned in front of the player. I suspected early that this approach would be costly, so I learned and leveraged Unity's performance profiler to diagnose exactly where the frame budget was going. The data confirmed the problem definitively: we were effectively rendering the scene twice, which is punishing for VR framerate, and it killed the literal approach within a couple of weeks. That evidence let the team pivot. The solution we landed on - arrived at collaboratively once the profiling made the constraints concrete - was, in effect, a teleportation mechanic disguised as a zoom. The phone interpolates from the player's hand up to their head camera; we cross-fade to white to mask a teleport from the fire escape (far) to a camera point right beside the chosen apartment (near); and we surround the player in a dark vignette sphere with a smartphone-shaped cutout, so they're looking "through the phone" into the scene. I implemented this transition in C#, including the math to constrain where the player could look so the illusion held. |
Outcome: The disguised-teleport approach delivered the impression of the near-far mechanic far more elegantly - and far more cheaply - than a literal implementation ever could have, holding the 60fps target the experience depended on. The technical and experiential foundation I built for Episode One carried forward into subsequent episodes of the series, which went on to be showcased and recognized at the Tribeca Film Festival, IndieCade, E3, and numerous film and game awards.
