Engineer Shares Details On The Tools Behind Super Nintendo World’s Mario Kart Ride

Andy Biar, a virtual production engineer who worked with Universal to create a simulation for Super Nintendo World’s Mario Kart ride, has shared some interesting insights on the project, which is still shrouded in secrecy.

Biar’s blog revealed how he and his team came up with a tool to help the ride’s game designers playtest instead of using the physical test track, which was being worked on by hundreds of people. He also shared how the team helped to achieve a request from Nintendo’s executive team.

Read on below:

Mario Kart

The Problem

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 Design

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 Meeting

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.

What do you think? Let us know in the comments.