After I had a few XR prototypes under my belt at Universal Creative, one day my manager called me into his office and told me, "If you want to go places at Universal, you need to learn how to open a ride." He tasked me with managing installation of the CAVU Interactive VR Motion Base as a tool for the backlot, but following all the safety procedures as if I was opening a real attraction.
The next four months would be an incredible challenge for me, but I couldn't have asked for a better guide in this process than Emmett Peter, former Director of Worldwide Safety and Assurance at Disney, who had been hired as a consultant for the project.
Our associate engineer goes for a test ride on the final installed motion base
I'll keep this section brief, but suffice it to say that roller coasters have rigorous engineering and safety processes! Over the next four months, I worked with our Professional Engineer in Orlando, our ride vendor in Canada, their motion base supplier in Turkey, and Universal Engineers in Mechanical, Electrical, and Controls disciplines, and our Facilities and Tech Services teams.
Here are some highlighted steps from our process:
In early 2018, the Mario Kart attraction design team for Super Nintendo World had a problem: there were hundreds of people working on different facets of the attraction at an off-site test facility, but there was physically only one test track. This meant that our game designers often had to wait minutes or even hours between laps in the test vehicle, as there were so many other construction and maintenance tasks that had to take place in the same space at the same time. The designers needed a faster way to test, or game design was going to fall behind.
An idea was born: what if the game designers could playtest in a simulation instead of using the physical test track? Design iteration time could improve dramatically! Universal formed a task force from across the company to build the unprecedented simulation, as the Mario Kart game design team didn't have the resources to do this alone.
The goal of the game design simulation was to create a version of Mario Kart which was configurable as thoroughly and quickly as possible, achieving maximum design iteration speed. The idea was that a game designer could ride the simulation on the motion base, pause the experience at any time, verbally request a change to us, and we could make the change immediately for review.
Our first game design scenario was around the spawn points of interactible items on the track. How many items should there be, and where on the track should they be placed? We needed to be able to reconfigure the entire map in seconds, not minutes, so manually moving GameObjects around the map was too slow.
One of our developers came up with the idea to load configuration data from an Excel sheet, which not only meant that we could quickly copy and paste rows to generate new maps, but also allowed the attraction designers to directly edit configuration files without needing to open Unity. We implemented the idea, and shortly afterward Universal invited Shigeru Miyamoto and the Nintendo executive team to take the simulation for a ride.
The Nintendo executive team had a great time riding different test maps, and after a while they asked an insightful question that we weren't prepared for: could we manipulate the routes of other racers in a similar way to how our tool handled interactibles? My heart sunk for a beat. Racers had animation curves and other state that our system wasn't designed to handle, but we wouldn't let that stop us. Our mission, should we choose to accept it, was to implement the racer manipulation feature within 18 hours in time for a meeting the next day. Game on.
We needed a system for puppeting racers that was achievable within one day, and after 15 minutes of collaborative thinking, I proposed the solution that the team would choose to implement. I was inspired by the numpad of my keyboard:
My proposed racer puppeting system was based on the layout of a numpad
Imagine a keyboard numpad overlaid on a top-down view of a race track. The player cart is always located at the '5' key, and moves in a forward direction of travel toward the '8' key. So in this coordinate space, '4' represents a position to the left of the player cart, '6' to the right, '2' behind, and so forth.
In my design, if a simulation operator presses the '4' key, the operator's selected racer would lerp to a position to the left of the player over a configurable amount of time. Pressing the '6' key would move the racer to the right of the player, and so forth. In this way, we created a simple set of keyboard commands for an animation manipulation system that we could all remember and operate with low cognitive load. We finished the implementation in 6 hours, and were able to proceed with our gameplay testing.
I led engineering efforts for 4 XR coaster simulations in 2017-2018, but in the interest of brevity I'll just briefly highlight the others: