A couple of weeks ago, I introduced our new method for traveling through a virtual word: Curated Locomotion. I gave you reasons for what inspired us to build it; let’s take some time now to talk about the process we went through to arrive at the system we’re proud of today.

The key to Curated Locomotion is constraining (or curating) the choices the player can make as they jump through the world. If we know where the player will be, we can design the game so that they won’t (or won’t often) run into the physical limits of their play space. It goes in reverse too; because we can control where the player goes, we have more flexibility in building the world, knowing that the Curated Locomotion system will be there to guide them along.

When we began building out the system, our thoughts centered around the teleportation pad. We would strew — carefully, of course — these discs throughout the world, following the plot’s flow and at any points of interest. The user would point their hand controller at the pad and be warped there. Simple enough, right? We now know exactly where the user would be in the virtual world: on the pad. However, that’s not enough. We have no idea where the user would be in the physical world; they would be in whatever arbitrary place they were before teleportation, and we can’t generally predict that as we are designing the game. The pad on its own doesn’t help us maintain the user’s physical position. In fact, the pad is almost a strictly worse solution. We’ve constrained the user’s ability to interact with the world but gained very little in return.

With a small addition, however, we could extract some gain from these pads. The simplest way to tie the player’s physical position to their virtual one is to force the user to go to a particular spot as part of the teleportation process. A teleportation pad wouldn’t have just a virtual location; it’d have a physical one too. If we, for example, wanted the player to have all of their physical space ahead of them, we could locate the pad at the back of the play area.

Of course, there’s the matter of getting the player to that spot before we virtually teleport them to their destination. Thus marked the start of what we called “phase space.” When the user selects a destination, we teleport them first to a void. Only one thing occupies this void: the teleportation pad. It’s positioned such that, if the user were to be standing on it, they’d be in exactly the physical location at which we want them to be. The user then simply has to walk over to the pad and push a button; the system would then warp them back to their destination. We can now design our world knowing exactly where the player will be both physically and virtually, all thanks to the phase space.

The phase space, however, was a controversial idea. Play testers found it jarring to warp into a void. They found it jarring to warp out of a void. If our original intention was to increase immersion in the virtual world, yanking the player out of it every time they wanted to take more than a few steps was the wrong idea. Fortunately, we realized that we could simply forego the phase space. We could, in fact, just place the phase space’s teleportation pad near the player’s original location using the same computations. The user would select a destination pad, and a new pad would appear near them. Just as with the phase-space pad, they’d walk onto it and push a button, except this time there’s no void.

The loss of the void, though, introduces a couple of issues. The biggest is that the new pad (the one the user stands on before teleporting) could end up anywhere. It could end up under or inside of other objects. Or behind objects, obscured from the user’s view. Careful game design could mitigate that, but we couldn’t get rid of the pad appearing behind the user. That happened a lot, and our play testers didn’t like it. Sometimes they didn’t realize that the pad had appeared and thought the game had gotten stuck. All times, though, they found it frustrating. With the void, at least there were no distractions. Without the void, we turned our locomotion system into a Where’s Waldo mini-game. As we continued to test out Curated Locomotion, one thing became clear to us: teleportation pads just wouldn’t work. You can probably guess that we figured out a better way, but that will have to wait until yet another update. Stay tuned!

At Codeate, not everything is all about games. Fundamentally, more than anything else, we want to advance the state-of-the-art in virtual reality, to bring to the vanguard new ways for users to interact with virtual worlds and elevate the level of immersion they feel when doing so. Our current project, The Torus Syndicate, could be simply described as a shoot-‘em-up game. However, we also like to think of it as a platform through which we can introduce novel ideas about VR and the experiences it makes possible. In a way, The Torus Syndicate started with a reflection on the difficulties in locomotion — that is, the system that makes it possible for a user to move through a large virtual world even when their physical play space is substantially smaller. That reflection turned into a conversation and, ultimately, a new locomotion system called Curated Locomotion, and I’d like to give you an introduction into how it works and what inspired its development.

Free-form teleportation is the most common locomotion scheme I’ve seen used by room-scale VR experiences. When the user wants to move to a point that’s outside of their play area (or when they are otherwise unwilling or unable to move physically), they indicate to the system where they want to go and, voilà, they’re there. Games vary in how the user indicates their desired destination and in how specifically they are moved there, but the key characteristic of this mechanism is that the user’s in nearly total control of where they can go in the game.

That total control, though, often presents a problem. In my early experience with room-scale VR, I often found myself constantly up against a physical wall. I’d walk towards something but run out of space before reaching my goal. Teleporting forward would work, but I’d run into the same problem if I wanted to continue going forward. This locomotion mechanic requires the player to maintain both their virtual and their physical location, centering and re-teleporting themselves periodically to ensure maximal room in all directions. That might be a simple thing to ask of users in a calm game. However, in a shooter like The Torus Syndicate, having to worry about one’s place in the physical world is frustrating when the virtual world is full of danger. There’s perhaps nothing more immersion-breaking than trying to dodge a virtual bullet only to slam into your painfully real bedroom door.

Before The Torus Syndicate was even a concept, we knew we wanted to address that frustration; we wanted our game to make the user’s motion through the world seamless. Unfortunately, free-form teleportation stymied us: if the user can go anywhere and do whatever, how could we even start to mold the world such that the user always finds his or herself in the right physical place? It seemed that the answer was some kind of constraint on the user’s movement. If we could somehow prescribe the path the user took as they progressed through the game — if we curate the places they could go — we could ensure an optimal mapping between the physical play space and the virtual world. That would prove to be a bit easier said than done, though. VR’s all about immersing the user, and artificial constraints easily jeopardize that immersion. We’ve spent the better part of our development time iterating over the mechanism, fine tuning every detail, until we arrived at what we think is a novel, seamless, and all-around awesome way to travel through a virtual world. The details of that process, of what we tried, and of what ultimately stuck will, however, have to wait until another update. Stay tuned!