top of page

Acerca de

Quest 3 mystery.png

Unannounced AAA VR Game (Major IP) - Technical and Systems Design

About this Game

This game was in development at Sanzaru when Meta decided to shift their strategy away from AAA VR Games and shut down all unannounced first party projects. It was a AAA VR Action game with a high profile IP, belonging to a beloved series with over 5 award winning games. It was a huge honor and vote of confidence for Meta to award us with this IP as it was the most valuable IP Oculus Studios had to work with.

At the time of cancellation, the project was roughly a year and a half into development with a fully polished vertical slice featuring roughly 2 hours of gameplay and roughly 2/3rds of the rest of the 20 hours of intended gameplay at an alpha level of completion. It was showing well internally, with the IP owners indicating a high level of excitement for the project's state. The game's cancellation was a result of a shift in strategy on Meta's part rather than as a result of the game's state.

On this project, I was asked to take design ownership of all props in the game and to handle the design and tuning of the Damage, Health, Rewards, and Skill Tree systems. 

When working on this project, my primary jobs were:

  • Designing and managing our Prop Infrastructure.

  • Prop Design, Blueprint Scripting, and Implementation.

  • Supporting other developers in their prop usage both in person and by creating tools.

  • Designing and balancing numerical systems alongside making tools to enable this process.

 

The game was developed for an unannounced VR platform using Unreal Engine 5.

This project remains under NDA, and thus discussion of it must be circumspect.

I apologize for the lack of specifics or visuals in this section.

VR Doors

At the start of this project, I was asked to take ownership of props. My expertise in both design and programming left me as the top candidate to handle the props, and it was clear from the get-go that we'd need a significantly higher amount of props to create this game than we'd needed for previous games.

 

During pre-production I sat down and created a list of props we'd definitely need, and the standout prop was doors. We were creating a game that took place entirely within a city. The player would spend a lot of time going in and out of buildings, as well as moving between rooms within buildings. The buildings were going to primarily be normal buildings, so we couldn't get away with sliding doors in a large part of the game. Lastly, the game was in development for the Quest 3 which has the processing power of a mid-end mobile phone (but still has to render to 2 screens at 72-90 FPS). As such performance is at a premium and we need the line of sight blockers that doors represent so we can aggressively cull and unload areas out of sight.

 

Given this, I spent a lot of pre-production playing various VR games to see how they handled doors and came away very unsatisfied. Most VR games do anything in their power to avoid realistic doors, and those that don't always had extremely simple solutions. Even Half Life: Alyx used only simple constraints and a grab point on the doorknob, something that was workable but would quickly get tedious if the doors were used too often.

 

None of that was going to work for our project, so I sat down to plan out how I was going to make the best doors in any VR game.

 

My first step was to figure out all of the affordances the door needed to support. I wanted the door to generally act like a door would in real life, but be optimized for the common case actions to minimize friction around those. Furthermore, I wanted to the player to interact with the door like the character they were embodying would. In our game's case that meant the player would either interact with the door like a normal person, burst through the door like a superhero, or carefully open the door while sneaking like a spy. Given this, the list I assembled was that the door needed to have behavior for: Opening/closing with the doorknob or door edge (while holding it all the way), opening/closing with the doorknob or door edge (releasing after the initial motion), pushing the door (with a hand, or an object), throwing an object at the door, sprinting into the door (to open it), sliding into the door (to open it), punching the door, and being hit by an explosion. This was quite a lot, especially since doors are notoriously difficult to get right, but for a feature that the player would be likely interacting with multiple times a minute in many parts of the game I deemed it worthwhile to invest time into.

 

The first step I took to make the door, was actually to make a prop that's similar but simpler. We needed a Vent Cover prop, which would cover air vents so that the player could remove the covers and enter the air vents to sneak around (like in a spy movie). The Vent Cover could be created as a generally small door with only the affordances of: Opening/closing while grabbing it (while holding it all the way), opening/closing while grabbing it (releasing after the initial motion), punching it, sliding into it. I decided to use this as a testbed for the real doors, so iteration could be done on a smaller scale.

 

For the Vent Cover, I went with a non-physics based approach that manually set the orientation of the Vent Cover while grabbing it. Then, once it was released, I caused it to swing open (or closed) based on velocity (with a significant bias towards opening). The swinging behavior was modeled as interpolation over a curve and scaled based on the amount of distance to cover. This allowed me to author three different animation curves that played if the Vent Cover was being opened or closed fast, slow, or if the player let go of it when it was nearly stationary (which would still cause it to move to the open or closed state). This allowed me to make the prop look and feel physically simulated, despite being completely kinematic. The most notable benefit of this was that the Vent Cover always opened perfectly. If it was physically simulated, then slamming it open too hard would cause it to bounce back into your face. This approach meant it would slam open with a satisfying bounce, but would essentially operate on "movie realism", wherein the most satisfying interaction is what actually happens. Development and iteration on this took about 2 and a half weeks, but by the end I was extremely satisfied with the result. The Vent Cover was extremely easy to interact with, looked like the best case scenario in every interaction, and was intuitive enough it didn't need to be tutorialized.

 

I then moved on to the actual Doors. I started with all the same scripting as the Vent Cover, but right from the get-go I knew I needed the door to be physics enabled. Unlike the Vent Cover, the Door needed to be able to be pushed with your hand or other objects. This meant it couldn't be completely kinematic like the Vent Cover. I sat down to figure out how to handle the conversation and came up with a clever solution in two parts. Firstly, if the player is holding the doorknob then it's set to kinematic while they're holding it and physics-enabled when they release it. This enabled a re-use of the same code used for the Vent Cover when it came to actually grabbing the door, but allowed for the door to operate as a physics object using physics constraints otherwise (and thus handle pushing, explosions, and having things thrown at it naturally). Secondly, I changed the script that governed the door swinging open or closed from directly setting the position to instead directly set the velocity. Then instead of directly retrieving the position from the animation curves, I instead retrieved the velocity by taking the derivative of the animation curves. This allowed for the behavior of the door opening and closing to be authored via curves in the same way as the Vent Covers, and also achieve the same "movie realism" that the Vent Covers had. While this ended up taking longer than I expected due to a variety of reasons (primarily having the door "bounce" required restructuring the script), in the end it worked fantastically and the door opened and closed in it's "idealized real life" manner.

 

From there, the door primarily needed scripting added for the various affordances. I added and tuned similar behaviors for when the player sprinting into the door, slid into it, exploded it, or just pushed it. The door then further needed behavior to make sure it closed under all circumstances for optimization purposes, and being linked to our manual culling systems.

 

While all of the above sounds simple on paper the door took roughly a month to get to our standards of completion, and it continued to get further updates as time went on. Overall, I believe this door was potentially the most complex door in any videogame. At the very least, it was likely the most complex door that isn't tied directly to loading in a videogame. The high level of interactivity and player freedom in VR, combined with the tailoring of door interactions to the "ideal interaction" every time was a massively complicated endeavor. The result though was a door that was easy to interact with in a natural way, responded to every type of interaction you could try in VR, and always made the player feel like the supernaturally competent character they were embodying.

 

While the game may have been canceled, I'm extremely proud of the word I did on this door prop.

Prop Infrastructure in UE: Look and Feels

When we began on props for this game, we took a look back at how we had handled props previously and immediately determined that our previous prop infrastructure was going to be insufficient. In Asgard's Wrath 2, we had a handful of props and each prop and prop variant had it's own blueprint. We used Unreal's natural infrastructure of inheritance to create visual or gameplay variants of props as BPs which inherited from the original prop. In the new project, we were expecting to make significantly more prop types and have likely 100s of visual or gameplay variants of props. Our old method was going to be entirely insufficient.

 

I sat down with one of our engineers, and we brainstormed how we wanted to resolve this issue. The solution we came up with was what we ended up calling Look and Feels. Our process was to make only a single blueprint for prop type. Then we used a special type of data asset we created that could be configured within editor to define all of the variables we wanted Level Designers and Artists to be able to change. This could be any variable, so we could directly expose the mesh and materials, expose tuning variables to allow for customizing the prop, or even abstract out the tuning variables to something that's easier to work with. Lastly, we hooked up these variables to the prop BP in the construction script.

 

This required a bit of extra time for the prop creator up front, but in return meant that Level Designers, Artists, or anyone (even someone with no blueprint experience) could make a new visual or gameplay variant of the prop. For them the process was just to copy the default Look and Feel we had created, change the variables, and then drag the Look and Feel into the scene like you would a normal BP to spawn the prop. The Look and Feel was just a simple variable field in the details panel, so it could be easily swapped out as well if a developer needed to change only one specific instance of a prop.

 

This approach had a ton of benefits. Firstly Level Designers could use the prop in their level, then when artists finished the level specific art for that prop they could just mass select the props and change the Look and Feel variable. Compare this to the process using default Unreal infrastructure wherein for every prop Level Designers would delete the old prop, replace it with the new prop, and hook up any interactions again, and it's a clear improvement. The second major benefit is that prop designers can define exactly what variables are safe for level designers and artists to change. During Asgard's Wrath 2 we had a lot of Level Designers create prop variants that broke the prop, due to not understanding what variables were and weren't safe to change. With the Look and Feel system they could confidently change variables without fear of breaking the prop. Furthermore, this system meant that the prop designer didn't need to be involved in the creation of each individual prop variant. Because the Look and Feels were more standardized than a blueprint could ever be and there was no meaningful risk of misconfiguring a prop, it meant that Level Designers and artists could create new prop variants without the prop designer ever being involved.

 

Overall, this approach proved to be a massive workflow improvement and allowed us to massively scale up our prop production.

VR Doors
Prop Infrastructure in UE

© 2026 — Joshua Butner.

bottom of page