Breaking the VR Speed Barrier: Sprint Vector's Fluid Locomotion Technology

Ever since it officially started in 2013, Survios has never been a developer to shy away from a technical challenge, especially one that increases immersive physicality and presence in virtual reality. Our launch title, Raw Data, relied on full avatar embodiment for natural-motion gameplay mechanics, including telepathic pushing/pulling powers, throwing katanas, and holstering and reloading weapons. With our second game, Sprint Vector, we decided to tackle an issue persistent in VR since the technology’s inception: locomotion. And not only that, we’d go at it head-on by building an obstacle/parkour game where speedrunning was the core of the gameplay. Spearheading this long process of many prototypes and a lot of sweaty HMDs were co-founder and Chief Technology Officer Alex Silkin; Head of Studio Mike McTyre; and Lead Designer Andrew Abedian. And we have to thank Nathan Burba and James Iliff, our intrepid Survios co-founders and leaders, for giving us the developmental freedom to make it happen.

When Raw Data was still in development, we started building prototypes for a single-player VR platformer styled like an obstacle course. At the time, Sprint Vector wasn’t even a concept we were entertaining; we just wanted to play with platforming elements, especially climbing. The first rough demo was created in summer 2015, and it used joystick/trackpad controls for movement (including pressing a button to jump), but also incorporated a one-to-one climbing mechanic along with ziplines and deadly obstacles.

The climbing’s one-to-one physicality and fluid, natural mechanics were incredibly comfortable for everyone who tried it, even when they threw themselves around using it. Mike is incredibly sensitive to nausea in VR, and while the joystick locomotion instantly pinged him, he had zero issues with the climbing. That was our lightning-in-a-bottle moment: we’d found a locomotion mechanic that didn’t make people sick. So, we set about evolving the main factors of the climbing mechanic—the one-to-one physicality and the fluid motion—into what we called “the stride.”

Before we get into the development of Sprint Vector’s signature “stride,” we need to mention Raw Data’s contribution. While Raw Data relies on short-distance teleportation for player locomotion (called “teleshift” in-game), we still used it to push the boundaries of player movement in VR. At the time of Raw Data’s development, many VR games relied on “blink” instant teleportation for locomotion because of the fear of moving a player through space. Teleshifting not only moved the player through space, but did so incredibly quickly. That use of speed was actually our first clue that going fast was not necessarily the key issue with VR locomotion.

The teleshift mechanic became the foundation for a couple combat mechanics as well. The first of these was using it to effectively knock back a player. Suddenly throwing a player in one direction was generally considered a VR “don’t,” but we wanted Raw Data to have some literal heavy hitters on its robotic enemy roster. To figure it out, Mike McTyre spent many hours testing his own limits as engineers finessed the three stages of the motion—the initiation, the travel, and the endpoint—to a point where no testers felt sick after being thrown backwards by one of our heavy mechs.

Inspired, Alex suggested we reverse this mechanic and give the player some control over it. The first of these was cyber ninja Saija’s area-of-effect slam attack; when activated, the player flies up in the air and drops back down. After testing and tuning for comfort, we realized we could make this player-instigated locomotion even more engaging by applying it to a powerful melee punch. The result was a charging punch delivered by Boss, a playable hero with large mechanical hands. The ability quickly became a player favorite, satisfying everyone’s urge to go full melee berserker on Raw Data’s creepy robots.

Altogether, the core arm-based climbing mechanic discovered in our platforming experiments combined with these backward and forward propulsion experiments and the climbing mechanic gave us what we believed were the building blocks for the problem we’d set out to solve. We knew that high-speed locomotion in VR was possible; now, we just had to figure out exactly how they fit together.

Other VR titles had already used the concept of arm-swing and air-grab locomotion, and in playing them for research, we noticed a couple persistent issues. The arm-swinger locomotion systems were gesture-focused, requiring the player to precisely hit specific points in order to continue moving forward; they didn’t actually drive the movement like our climbing mechanic did. Additionally, the motion mechanics felt choppy, a far cry from the smooth, adaptable system we were envisioning—that was when we knew momentum was key in attaining it.

In developing the stride, we decided to take the best elements of arm-swingers and air-grabbers and expand them into a completely new kind of motion mechanic. Using arm swinging made sense—as human beings, we’re just naturally programmed to swing our arms as we move around—so we used that motion to actually drive the locomotion system, not just act as gestures to trigger the movement. At the top of the swing, the player presses and holds the trigger, swings his arm down and back, and releases it at the bottom; in doing so, the system pulls the player forward by translating the speed and distance of the swinging movement. As a bonus, because the system requires consistent physical movement on the player’s part, it doesn’t trigger nausea. Every time the player makes a stride, he is synchronizing himself with his avatar by engaging with the VR world directly, and continuing to synchronize and engage over and over during the rhythmic arm-swinging motion resets their expectation for nausea each time.

With the stride dialed in, we had to add the next logical component: a brake. Braking started out as a gesture: stick your hands out and forward and you’d come to a stop. But when we needed that same motion for a later flying mechanic, braking changed from a gesture mechanic to a pure button press, albeit with precise tuning to make it work perfectly and not induce nausea because of the sudden stop. This simple switch shows that all locomotion mechanics can be continually tuned until they are nausea-free.

The next challenge was making our new locomotion system adaptable for different physical playstyles. We realized this after conducting playtests within the office and, after describing the gameplay as “running,” discovering that everyone’s individual interpretations of that arm-swinging gait were drastically different. As a result, we devised some assist coding that we called “intended motion” to subvert the frustration these players felt at not having their normal movements adequately translated into gameplay. Intended motion interprets the combined tracking data from the HMD and controllers to decipher what mechanic the player is trying to execute. We even eventually programmed it to interpret when the player was leaning and translate it into a strafing motion. So, instead of the player having to contort himself to adhere to our specific physical scheme, the game figures out and executes the mechanic based on their general movement and button inputs.

Additionally, to further amp the comfort level, we opted to restrict the field of view through a speed-controlled tunnel vision effect. As the player continually gains speed, the edges of their FOV would gradually populate with dust-mote speckles, evolving into lightning bolts that change color and become more intense as the speed reaches and hits maximum. Along with allowing greater player comfort at higher speeds, these visual effects let the player know roughly how fast their avatar is sprinting. These were originally the only feedback available to the player with regards to his speed, but as they existed only on the periphery and could be easily missed within the chaotic context of the game, we did add in a speedometer for specific information.

With the core sprinting mechanic figured out, it was on to jumping. Our prototypes relied on the classic “press X to jump,” but Andrew successfully lobbied that the button-press jumping would make people sick and ultimately wouldn’t flow with our fluid, active VR gameplay. Sprint Vector’s jumping mechanics actually ended up as a natural evolution of that early climbing demo, with full one-to-one physicality as the player “grabs” the air and uses a downward throwing motion to fling himself upward, while continuing to travel forward from the interpreted momentum. And, as Mike pointed out, you can’t have gaming without a double-jump, so we made sure that went in!

As with the stride, intended motion ensured proper player execution when jumping. The downward throw—described and demoed as “throwing a tomato on the ground”—was designed to flow naturally out of the stride, players still scrambled to nail a successful jump, especially at maximum speeds. Adding the assist mechanics from intended motion meant the game could automatically adjust a player’s jump depending on his speed: the faster the player’s speed, the more restricted the angle of the jump, so the player can’t accidentally leap sideways and go ricocheting off course when trying to nail a critical jump at maximum velocity.

Jumping progressed to the next mechanic: flying, which needed a similar degree of control. We admit we initially implemented flying purely to satisfy wish fulfillment, because who doesn’t want to fly like Superman?! Every two-year-old knows that the logical way to fly is to stick your arms out in front of you, so we immediately knew that was the motion we wanted. (It was also a way more intuitive choice after our first failed attempt, which was basically “running in the air.”) Flying came with its own set of air control mechanics that broke a key VR “rule”: never turn the player. But to get a player in mid-air to make a smooth turn, we implemented a banking movement based off the player subtly twisting his arms, not unlike turning a steering wheel. Because the motion is very natural and adjusts in speed based on the player’s input, this turning didn’t affect the players. With these air controls, we successfully added flying to the Fluid Locomotion trifecta of movement mechanics.

But what goes fast must slow down. After watching our QA team (and Alex) play round after round of Sprint Vector by taking to the air and soaring over the maps, using the jump mechanics to stay airborne, we knew flying had to be nerfed—not because we hate fun, but because running on the ground had to be the fastest way to get from start to finish. (After all, the game’s called Sprint Vector, not Fly Vector.) So, flying’s speed was reduced to make lingering in the air a guaranteed trip to the back of the pack. But we still wanted flying to be a key component in a pro Sprint Vector player’s skillset, so we needed to give it something more.

A week before GDC 2017, Alex found the answer in the braking mechanic. Flying is essential in Sprint Vector for getting around obstacles and finding key shortcuts and secret power-ups, so we theorized that giving the player an easy and fast way to get back down to the ground and take off running would establish its function. We mapped the brake to the controllers’ grip buttons, increased the gravity so the player would drop faster when air braking, and tested and tweaked to ensure there was no momentum loss once the avatar’s feet touched the ground and the movement shifted to running. We were rewarded with a game that now played completely differently—and way better—than before, as our seasoned QA players established a new rhythm of running, jumping, flying, air braking, and slamming down to take off sprinting. It was exhilarating to watch as the gameplay smoothly looped among the different mechanics without any hiccups save for player error.

Which brings us full circle back to climbing. In the early public Sprint Vector convention demos, even as players reveled in zipping around the Egyptian-themed environment, they struggled with the climbing walls—which made us realize we’d given so much love to the other locomotion mechanics that climbing had remained fairly unchanged from its original incarnation. We tried everything we could think off, including additional helper systems to guide players up the wall and over the edge when they flung themselves upward, but it wasn’t fluid and consistently killed the momentum of the race.

Andrew’s solution was inspired by monkey bars, a zipline mechanic from the now-ancient prototype, and a strip of bacon—well, that’s what it looked like in his whiteboard sketch of squiggly streaks with directional arrows. His concept was a smooth directional stream that the player could zip across using a monkey bar-like motion, but maintain their current momentum from running, jumping, or flying; its entire surface was nodes, so there was no issue with slowing down trying to grab a specific spot. In sharp contrast, you could actually increase your speed on a gripstream because there’s no speed cap. The gripstream not only solved the stalling problems of the climbing walls, but opened up a ton of new possibilities for maps. We ended up placing high-flying gripstreams over pits of acid and lava, curving them around surfaces to emulate wall-running, and swooping them down for controlled descents on long drops. If you watch streams from the recent ESL VR League qualifiers, you’ll see that the pro Sprint Vector players consistently build up and maintain ludicrous speeds by leaping from one gripstream to another with crazy-fast platforming maneuvers that are super fun to watch.

The final locomotion mechanic we worked on was drifting, the cherry on top of the Fluid Locomotion System and our take on smooth rotation. Drifting was crucial for making sure Sprint Vector performed well on forward-facing VR setups as snap turning broke the flow of the game and often resulted in overturning. Operating on the same momentum as the stride, the player engages the arm that’s in the direction he wants to turn by pressing down two buttons while pulling the arm toward his hip. (He can continue swinging his other arm to continue pumping momentum into the drift motion.) The turn rate of the drift is controlled by the angle; pulling the arm closer to the hip makes the turn tighter, while keeping it farther away results in a wider turn. The game reads that hand as the anchor point, initiating the drifting motion by rotating the player around it—yes, we turned the player again, this time from nothing, so as with the FOV lightning bolts for the stride, we spent a lot of time tuning and testing on the entry, travel, and exit parts of the movement so that every part felt fluid and comfortable.

Drifting is the most advanced mechanic in Sprint Vector. Watch the top-ranking players, especially those competing in ESL’s VR League, and you’ll quickly notice that drifting is a frequently-utilized mechanic for achieving and maintaining maximum momentum.

We’re proud to have made Sprint Vector, and consider it a turning point for VR development. We opted to push locomotion to its limits to prove to everyone—ourselves included—that the current assumptions about its mechanics were false, opening up opportunities for amazing new experiences across the board. Making a game whose core mechanics are all locomotion-centric and then ratcheting up the intensity beyond anything currently in VR was a huge ask of our players. They’ve not only embraced it, but shown us tenfold that they were ready for the challenge. Even we couldn’t anticipate the crazy levels of speed and skill they’d bring to the game, and we continue to be blown away by the runs our player community share with us.

Sprint Vector is also a unique case of being what we consider the first of a new, VR-exclusive genre: an adrenaline platformer. It’s exhilarating, engaging, and a rush to play in a way that you can’t get on a traditional PC or console platform, and we’re incredibly proud of what we’ve accomplished. By breaking the rules of speed and rotation to build the Fluid Locomotion System, we’ve proven that VR really has no limits, and we’re excited to see what the next wave of developers can engineer as we create VR experiences that continue to push the limits of physical and mental immersion.