Designing for physical or standard avatar locomotion can lead to environments with limited architectural designs, for example those which work well with moving across a continuous floor or within a fixed area. This can lead to designs that feel limited or constrained when compared to non-VR games. Common examples are ladders, gaps, and ledges. Special logic and planning is required to support locomotion across features like these. This will add scope to your project, but the right approach to these scenarios will enable more creative designs due to the increased freedom of movement.
It’s important for the environment to be designed so that it works with the locomotion system. Every locomotion system will have limitations, and the environment needs to be built in a way that allows people to move effectively within these constraints. It is helpful to plan for this early in your development process by identifying what kind of locomotion behaviors the design requires, and creating a test environment that makes it easy to quickly iterate, testing all aspects of the locomotion system.
Features of the test environment will typically include a variety of slopes and materials, doorway dimensions, step heights, path obstructions, tunnels, ceilings of various heights, ledges, ladders, and so forth. Your test environment will ideally include every possible scenario that can test the compatibility of the locomotion system. Many teams have been surprised to see just how much work it takes to guarantee their locomotion system is reliable and comfortable, and streamlining this iteration process is always worth the effort.
Learn more about playtesting and ways to improve your iteration time in the following Oculus Developer Guides:
In many designs, the environment needs to include areas that are not accessible by walking alone. Moving through these areas requires another form of movement, such as teleportation, climbing, or leaping.
Short-range teleportation can be a useful tool for navigating discontinuities in the environment, which in turn provides level designers a lot more flexibility in their map layouts. For example, a short-range teleport combined with a warp mechanic can feel very much like a leap over a gap or ledge. This mechanic can be an effective way to navigate past areas which might otherwise require cumbersome or non-intuitive actions from the user. Even if the majority of the game is designed for use with standard avatar motion, supporting the use of short-range teleportation to move through certain parts of the terrain is an effective way to support more variety in the environment.
Climbing in VR can be an especially challenging design problem. For example, if someone is climbing a rock wall, what should happen if they physically move away from the wall? Here are some common climbing scenarios to consider:
Transition to climbing surface: It’s easy to imagine virtually moving up next to a ladder or rock wall, grabbing it, and moving upward. This scenario gets especially complicated when the ladder (or other climbing surface) isn’t approached from straight ahead, or from above. Traditional flatscreen games will often take control of the camera from the player to reposition the avatar onto the ladder. In VR, overriding the camera orientation and position should almost always be avoided because of the potential comfort issues, but not forcing the orientation leads to another set of problems related to how the character interacts with the ladder and how they appear to other players. These challenges are closely related to those that take place when the user turns while climbing, discussed below.
Turn while climbing: If someone turns away from a ladder, either by physically turning or by artificially turning, the grip on the ladder may need to break in order for character visuals to make sense. For example, if someone is on a ladder and snap turns 90 degrees away, what should the hands do? If they remain attached for as long as the grip is held, the avatar may wind up in an unrealistic pose which only gets worse as they physically move from the ladder. Depending on the design, it could make sense for them to disconnect and fall, or require the avatar to remain attached to the ladder and force the orientation to remain in the direction of the ladder. Be sure to recognize the comfort risks for each of these options., For example, if you choose to force the avatar to remain facing forward on the ladder, this will lead to a sense of vection because the physical movement away from the ladder will require artificial locomotion to keep the avatar in place on the ladder.
There are many possible ways to respond to these situations; however, if it doesn’t have a negative impact on gameplay, it is often a good idea to simply warp-teleport the player to a safe place near the top or bottom of the climbing area.
When climbing, avatars are often attached to virtual ladders or other surfaces. Since there is nothing preventing someone from physically turning or stepping away from the attachment, it is necessary to decide how the avatar should respond when this happens. In this case, the arms are still attached to the ladder because the player has moved away while keeping the grip buttons pressed.
Transition from climbing surface: It can be difficult to design for the instance when the user needs to climb off a ladder that ends at a roof line because the avatar will need to continue to move up and above the top of the ladder, then forward to get onto the platform. This act of ledging is generally best accomplished with a rapid, scripted movement that transitions the user to an appropriate position nearby where standard locomotion is available.
Climb down: In VR, as people climb down a ladder, it can be difficult to know when to stop. What happens if their feet have reached the ground, but they continue to climb down? At some point, the locomotion system needs to detect this scenario and prevent further downward movement.
Due to the challenges related to climbing, it may be a good idea to provide a teleport mechanic that avoids the need for hand over hand climbing entirely. For instance, one option is to enable the user to walk up to the ladder, and provide some means by which the user is able to teleport to a spot near the other end of the ladder.
If you have a gap that a user must get over, a teleport with a warping mechanic can make for an ideal leaping opportunity. Even if you intend to focus on physical locomotion or standard avatar movement throughout your app, teleports are still a useful mechanic for environments that feature ledges, ladders, crevasses, or any other gaps the user must go over.
One of the most important decisions regarding camera behavior in VR design is whether or not the camera will collide with the environment. It’s generally easier to implement cameras without collision; however, the application design may require cameras to collide with the environment. Both approaches have implications to the usability, design, and comfort of the application, which are all discussed in more detail below.
If the locomotion system doesn’t prevent the virtual camera from moving through objects in the environment, such as walls and doors, be sure to consider the following challenges:
Some solutions for these challenges include:
Camera collisions are sometimes necessary to meet design goals, but they can also lead to uncomfortable moments for the user. When someone physically moves and there is a collision within the VR experience, the camera needs to stop, but as nothing will stop the user’s physical movement in the real world (assuming they remain within guardian space), the player will see the wall moving away from them as they attempt to walk into it. This example will produce potentially uncomfortable vection for the user, and it is unavoidable if the camera is unable to go through virtual walls or any other objects. However, with careful planning the effects can be reduced.
It’s useful to consider objects moving in the environment such as swinging doors or projectiles that could collide with the camera as the user moves through the virtual environment. These collisions need to be considered and it is generally recommended to not move the camera in response to moving objects because if every small object can block camera motion this can lead to unpredictable vection events. One approach is to configure the collision system so that the camera only collides with stationary environmental objects, or those objects that absolutely must move according to their scripted requirements, such as elevators. When independently moving objects, such as doors or projectiles, collide with the camera, they should either move away from the camera or ignore the collision in a way that doesn’t cause rendering artifacts. In either case the camera should be unaffected by these collisions. If the object moves away from the camera, this can lead to situations where a movable object is squeezed between the camera and fixed world geometry, which can cause instability in the physics simulation. Objects in this situation will usually resolve the collision by popping out somewhere nearby, but they may also get moved outside of the valid environment, so care should be taken to make sure the object winds up in a reasonable location. A common solution for this scenario is an out-of-world position check which either destroys or resets the object to a known safe location.
If a player is near a ledge or cliff, it is natural for them to lean over and look down. The design problem here is that virtual movement typically follows the physical position of the headset. That is to say, if the headset moves, the character position typically moves to follow the headset (depending on collision behavior discussed above). If the headset moves over the edge of a cliff to look down, there is a risk that the avatar will fall off the edge of the cliff by accident. This problem is most common in situations where the character capsule has a small radius. A simple way to address this problem is to simply increase the width of the capsule which reduces the risk of the user accidentally falling. While this is a quick way to solve the problem, the larger collision capsule may not be suitable for movement in the rest of the environment.
When the movement capsule is locked to the headset position, leaning over a ledge to look down can cause the avatar to fall over the edge.
A better way to prevent accidental falls is to constrain the character capsule to the HMD position with a short positional constraint (think of it as a leash) so that the HMD is essentially pulling the capsule around behind it. With this technique, the user can move the headset a short distance without moving the character capsule, which provides more control near ledges because the HMD can be moved over the edge of the cliff without dragging the capsule off the ledge. It is important that the HMD has its own collision shape, typically a sphere, so that it can detect and respond to collisions with the environment.
The avatar’s collision capsule is often constrained to the headset position. Generally this means as the headset moves around the physical space, the collision capsule follows the user’s movement within the virtual environment. When the collision capsule hits something, such as a desk or other object taller than the maximum step-height, it can prevent the virtual camera from moving forward. This can lead to situations where people are unable to simply lean over the object as the character capsule collision treats this scenario as if the user is walking into a wall. The solution here is to implement the same positional constraint behavior described for ledges, above. This will allow the user to lean over the object as far as the constraint limits allow, while the character capsule remains in the correct position next to the object.
In some designs, the ceiling is so high that the height of the collision capsule is not relevant, but it is important to plan for scenarios where there are objects in the environment low enough to collide with the player’s head.
It’s not uncommon for applications to use collision capsules that have a fixed height, and the content is tuned for that height so that the user can move through areas in a consistent manner. This might seem like a good idea, but this can be problematic when someone is taller than the standard capsule, causing the camera to go into the ceiling. Similar issues are also present for people who are shorter than anticipated, which could lead to situations where someone can visibly walk underneath something but is prevented from doing so because the collision capsule is taller than the user.
One solution is to adjust the avatar’s collision capsule height to match the headset’s offset from the ground. This has the useful side effect of enabling the user to crouch under obstacles, and prevents overhangs from unexpectedly preventing movement. Depending on the design of your application, it may not be necessary to support this, however, it can be useful for some designs because it will enable an experience that requires the user to crouch to move through crawl spaces and other similar areas.
Keep in mind that dynamically adjusting the height of the character capsule can be tricky, for instance, if someone stands up while the ceiling is blocked, the locomotion system will need to continue to behave in a way that is still usable and comfortable. A hard collision with the ceiling might result in the user physically standing upright while moving through a space that only has room for crouching, and when they leave the confined space they may remain crouched in VR unless the system detects this state and restores the capsule to the ideal height.
It may be simpler and potentially more comfortable for the camera to move without collision, and respond in the same way as when the camera moves outside of the environment, which is discussed in the Cameras without Collision section above. Just remember that this will impact the user’s sense of immersion as poking the camera through walls is not as realistic as being blocked by them.
Depending on the environment, the player capsule may need to shrink in order to enable access to areas with low ceilings.
Teleports are difficult for an observer to follow and problematic for non-player-characters (NPCs) trying to reach the player. If an NPC is trying to get into someone’s melee range, the player will be able to break the game design by simply teleporting right before the NPC reaches them. Games have addressed these challenges in different ways, for example implementing a stamina pool to limit how often people can teleport. Unfortunately this can feel unrealistic.
In regards to multiplayer experiences, the environment might be filled with other players moving around the environment unpredictably as they teleport. The user might observe other players standing still, making slight movements due to physical locomotion, or appearing/reappearing in random locations. All of this activity can make the user lose their sense of continuous movement, and as a result, the experience feels much less immersive.
Users generally want to understand where the other players are within their space, as opposed to them simply disappearing and reappearing around the map. You might display some sort of visual effect to indicate player movement which can help inform observers where people are moving, this helps with multiplayer experiences, but does not address the problems related to NPCs.
An effective solution for both problems is projected avatars, where teleportation is the result of navigating the user’s avatar to a new location in third person project, and when the location is selected, the user’s first-person perspective changes to that new location. All observers, both human and NPC, view the projected avatar as if it was moving through the environment with natural and continuous motion. This neatly solves both multiplayer and NPC related issues associated with teleportation. Projected avatars are also useful for improving comfort and usability as discussed in the Improved Turns and Teleports section.
Now that you have established your understanding of the many potential challenges that come with designing a locomotion system, we recommend grounding yourself in those potential issues that can arise with user comfort and usability with the following section: Comfort and Usability Considerations. This page not only outlines the most important considerations, but features an outline of which locomotion types and techniques you may want to leverage as you design your locomotion system.