A Review of Portals in Virtual Worlds


A year ago, we started to look at how we might travel from one virtual world (anything from a simple program launcher to a more complex program like JanusVR) into a completely unrelated virtual environment.

As I searched for some consensus on how portal should look and operate, I wasn’t able to find any good guides which cover the topic. (The extensive use of the word portal by web-based companies has made it a particularly difficult topic to search.) This article is a (non-exhaustive) review of portals as a popular method used in virtual worlds today to transport the user to entirely different regions.

What are portals? Portals are typically objects or areas in the environment which advertise the ability for a user to approach and engage them in order to be teleported to a new location. Traditionally, they are placed vertically along a wall (and walked into), but they can be placed horizontally along the floor (and stepped onto). An additional action may be required, before or after moving an avatar into the aperture, to actually engage the portal.

Portals won’t be the exclusive means of long-distance travel within and between virtual worlds. What portals have going for them is that they’re already commonplace in virtual worlds, they can be visually integrated into many themes, and they’re easily understood by players.

In JanusVR, portals take center stage as the method used to connect otherwise unrelated virtual worlds.

In JanusVR, portals take center stage as the method used to connect otherwise unrelated virtual worlds.


Portals offer us the convenience of long-distance transportation, but without any of the cost (in terms of time, and physical or mental effort) that is associated with real-world travel.

When setting up a portal for transportation, there are a number of items to consider.

SYMMETRY: Are your portals one-way device, or can they transport the user back-and-forth between both ends? You’ll need to decide which method you’re going to use and stick with it. You can mix one-way and two-way portals, but if you plan on doing so, implement it in a way that is clear to the user before they take the trip. At the least, they should be visually distinct.

CONTIGUOUS: Is the portal a doorway that you click on and are teleported to the destination environment? Or is it a doorway which contains a live environment on both sides, and you can seamlessly move through the doorway?

The choice to use a contiguous portal or not may be one that has already been made for you. Depending on what you are trying to accomplish, and what features your graphical engine offers, you may not be able to use contiguous portals. If you do use them, be mindful that they have the potential to cause a substantial decrease in client performance. Just because you can use a contiguous portal doesn’t mean that you should.

RETURN TRIP: If you have many different portals in your environment which terminate at the same destination, you may have to determine how the player makes the return trip. Do you create multiple portals, each one leading back to a different destination? Or do you have a single portal which they use to return from where they came?

If you use the signal portal approach, take care on how you handle the association back. It could be possible for a player to nest through several of these types of portals. It may also be possible that the user never takes the return trip. Be sure to consider if these connections need to be saved between sessions.

ISOLATION OF SPACES: Non-contiguous portals allow us to provide isolated spaces that are not conventionally connected to the rest of the world. There are any number of good technical reasons to do this, including unique environmental settings, reducing the memory and processing load of large areas, and creating a space with additional security and privacy. There are also good psychological reasons to use them, such as exclusivity. You might want to review an earlier article on the topic, How attached are we to the open world and Euclidean space?


GROUP TRAVEL: How do we determine a group of people who wish to travel together? Do we use lobbies? Group teleportation pads? How do we deal with latecomers? Could we use a grouping mechanism to let users travel on an individual basis, and then find each other after they go through? Should the portal itself identify the names of group members who are already on the other side?

STACKING: What if we want to prevent avatars from stacking at the destination? (If not for visual reasons, then perhaps to spread out some of the load in a conventional game engine.) Can we spread them among multiple destinations? Is the spread something that we want to define at the entrance or the exit point?

PERMISSION: It is possible that you want a portal to have special requirements which limit its use to a subset of players. In such cases, it may work best if the portal is still publicly visible (so that other players can understand why people are disappearing).

For a player that does not have permission to enter a portal, it should be visually apparent, and there should be some mechanism to explain what is required in order to take advantage of it.


EXPLORATION: The excitement of exploration and the journey itself may be something that you want to cultivate into a rewarding experience. Be mindful, though, that experienced players will want shortcuts once the excitement and reward is gone.

INTRODUCTION AND MASTERY: You may want a player to be firmly introduced to an environment before giving them a chance to quickly escape. Perhaps there is a story line which needs to be explored, or a task which needs to be accomplished. See if you have situations where a non-linear choice to escape actually works against the situation, and make sure that portals do not provide that opportunity.

NEW PLAYERS: Unless you environment is based on portals, you may want to hold off before your player has their first introduction to a portal. It is important to let a player become accustom to the unique features of the environment and how to use the controls before jumping them to a new location.

TRAVEL AS AN INTENDED COST: Sometimes you actually want to force a cost (in terms of time and effort spent) to reach a destination. Perhaps you want to limit the number of people in that space. Maybe the destination contains an unusual reward? What if just reaching the destination is its own reward? Conventional travel is one way to make a destination more expensive.

For the times where you do not want transportation to be easy, you may not want portals to help the player get there. That said, once they reach their final location, you could have a portal which teleports them back to the beginning. (Once a new location has been reached, you could also allow two-way portal travel from that point forward.)

CLUTTER AND DISTRACTION: Portals themselves can be a visual distraction as much as the stream of people popping in and out of them. A portal (or a series of portals) should be placed in an area so that it does not detract from the surrounding environment. In it natural area (a travel or transportation hub), a portal is actually the star attraction.


The problem with giving your users a powerful tool is that, soon enough, they’ll figure out how to use them to annoy and attack each other. Portals are a powerful tool. If you give your players the ability to create portals, how many ways can they potentially be misused?

Environmental trap: using the Teleporter in Team Fortress 2 to trap for friendly players.

Environmental trap: using the Teleporter in Team Fortress 2 to trap for friendly players.

TRAPPED: First and foremost, a portal can be used to trap players. Consider the well-known teleporter trap in Team Fortress 2, which would wedge teammates between the teleporter itself and an environmental incline.

A portal can be used to place a player outside of the map, wedge them into a wall (or other object), trap them in an enclosed space with no exit, toss them into an environmental hazard, or even force them into an infinite loop by placing them in the activation threshold of another portal.

FORCED: A portal that activates on contact can be placed at a spawn point. The moment a player appears on the map, they will be automatically teleported without their consent.

Architecture room in VRChat. A hallway is blocked by an unavoidable portal.

Architecture room in VRChat. A hallway is blocked by an unavoidable portal.

BLOCKED: A portal can be used to block access to in-world items, such as signs, controls, critical paths, and doorways.

REPLACED: A fake (and possibly disguised) portal with a different destination may be placed in front of a known portal.

UNRESTRICTED: Portals can be used by players to grant their personal access to a restricted area to other players. Arbitrary portals could allow a player to access any place in the map that they choose.

If you give players the ability to create their own portals, you’ll need to decide how severe each of these problems are, and in what ways you can reduce their potential to be exploited.


Portals are environmental devices which are used to transport a player to a new location. When setting up a portal, there are a number of items to consider, such as symmetry, a contiguous threshold, a return trip, and the isolation of spaces. We reviewed some of the problems with deploying portals, including group travel, destination stacking, and permissions.

There were some situations where portals may not make sense, such as wanting the user to focus on exploration, introducing a new area, educating new users, using travel as an intended cost, and avoiding clutter and distractions.

Finally, we looked at the ways that players typically abuse user-created portals, including traps, forced teleportation, blocking objects, replacing real portals, and gaining unrestricted access to the environment.

Portals are cool, and teleportation techniques become increasingly important in large environments. As a review of the use of portals, what other advice would you add?

We have an upcoming series about metaverse implementation which may be copublished to a larger audience. It explores the current problems with metaverse implementations, and then adds a new approach which exchanges unworkable issues for more tractable problems.


Tags: , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: