Local Teleportation Using Standardized Portals

[rdixon22]

Name:
Local Teleportation Using Standardized Portals

Purpose:
To reduce the pain of navigating between frequently visited land areas by enabling decentralized land-to-land teleportation on demand

Description

Walking, flying, or taking a train through the Decentraland world will be very fun for a while, but it will soon become tiresome to travel between your own land and your friend's land over long distances. We don't want navigating between frequently-used places to become as dull as a daily work commute.

It might be best to support direct land-to-land teleportation from the very start.

Each owned contiguous plot of land could be allowed one standardized teleportation portal/point-of-teleportation-entry. The owner can place it anyplace within their land. When you want to visit a friend's land -- or an open, public area -- you step onto your own portal, select from your available destinations, pay a fee in MANA, and teleport there.

Each owner could set restrictions on who can teleport in to their land (everyone, everyone except blacklisted, only those who pass an authentication test, or only whitelisted).

There would be a base cost in MANA for each teleport, plus a variable amount that increases based on the distance traveled.

A share of the MANA charged for teleportation can go to the owner of the destination land. (Land owners could even set a supplemental MANA price, on top of the standard fee for those who teleport in.) This would provide a revenue stream for owners who design popular destinations.

The rest of this proposal goes into more depth about design options for standardized portals for local teleportation. I apologize in advance for going into such long-winded detail. :)

Pros and Cons of Local Teleportation

One downside to local teleportation is that it might discourage people from walking around and discovering other amazing places in Decentraland, and therefore reduce the liveliness of public spaces, since there would be fewer walkers. Depending on how local teleportation is implemented, these concerns can be reduced. For example:

• Teleportation fees could be made significant, even for small jumps, so that only players with lots of MANA will teleport routinely. The rest of us would still choose to walk, fly, or take other transportation in order to conserve MANA. (One exception might be teleporting to your other owned lands, which could warrant lower fees.)
• "Entertainment by walking around" will still be free. If an area is full of interesting things to do and see, people will naturally want to walk through there. But if an area is barren, full of ugly 3d primitives, or dotted with objectionable content, people could bypass this by teleporting.
• Nearby destinations can be shown near the top of the portal destinations list, encouraging people to stay in the neighborhood, so to speak.

There are more advantages to allowing localized teleportation with standardized portals:

• It will reduce the visual congestion chaos near central teleportation-hub portals in public spaces. (If you have ever experienced 100 avatars occupying the same exact spot at the entry points to MMO games or Minecraft servers, you know what I mean).
• Owners can place their portals in exactly the right spot to provide new arrivals with a breathtaking initial view of the land.
• Owners with non-contiguous land could swiftly teleport from plot to plot. They could also structure their portals to provide visitors with predefined routes or tours through their lands.
• An alternative would be to allow teleportation from anywhere at any time, just by invoking some sort of teleport command. This might be useful for developers or support personnel, of course, but I think it would detract from the overall Decentraland user experience. Standardized portals, no more than one per plot, mean that there's always a portal nearby, but you can get creative about where you place them, where they go to by default, and so on. This enabled certain kinds of game-play that can't be undermined by people porting anywhere at will and causing chaos.
• One exception to the port-from-anywhere rule might be to let players have a low-cost "Port Home" option that can be invoked from anywhere. It's possible that players could get "stuck" in badly designed places (imagine a pit that's been dug as a trap for unwary visitors -- and if they can't fly they are stuck there). Or perhaps they are in an enclosed space and being harrassed by abusive players. A "Port Home" feature would let people return to their designated home portal for a very low cost, to get out of such situations.

Design Options for Standard Portals and Teleportation Behavior

Here are some specific ideas about the teleportation portal objects and behaviors themselves (merely design suggestions, of course):

Standardization

There should be some standardization of the portal model, texture, or visual effects, so that players can immediately recognize a portal when they see it, even at a distance. The standardization could take many forms, such as:

1. The exact same object/prefab to be used by everyone, so that the size, look, and behavior of everyone's portal is identical;
2. A similar, recognizably-shaped structure that supports the same teleportation behavior, wbut which can be reskinned to look different in different spaces;
3. The ability to turn any model into a portal, but give it an immediately recognizable visual effect (say a blue pulsing glow) so people know what it is.

I would suggest that 1. is the easiest option at the start, since one Unity prefab could be easily provided for owners to place on their land as-is. Later on, different portal prefabs could be offered and/or customized by land owners.

Here are some examples of standard portal model styles that might work (since the Stargate portal shown above might be too big, and copyrighted).

The unique shape this kind of portal would be recognizable from a distance. It could be reskinned according to the theme of the owner's land:

A simple "floor model" would be less intrusive, though perhaps a bit harder to find. But that could work well in scavenger-hunt kinds of situations.

UI/UX

When a player taps/clicks/gazes at a nearby portal they would be presented with a simple UI listing possible destination names the associated teleportation cost in MANA.

The types of destinations shown might include:

• Recommended/default destination: The owner of the portal can recommend one destination, which will be shown at the top of the list. There should only be one recommended slot, or else some people would spam the list with poor choices, in order to part the traveler from some MANA.
• Nearby destinations: A few more slots could show nearby destinations that the player can access, as a way of having them explore the neighborhood.
• Favorite destinations: A few slots should show destinations that the player travels to very often, to make it easier to repeat frequent trips.
• Home: The traveler could set one destination as his home destination, to be included in all lists.
• Other: The player can enter the name (or address?) of any possible destination, which will then be validated and the player's ability to access it confirmed, and then the player will see an estimate of how much MANA is costs to teleport there.
• Whitelisted: If a whitelisting concept is implemented, a player could see a list of all the destinations that he has explicitly been allowed to access.

The first list of destinations shown for a portal might combine the above, with some buttons that let them open up other destination lists, something like this (but with friendly destination names, of course):

Where do you want to go?

Destination      MANA
--------------   ----
Recommended      5.0 
Nearby #1        3.0
Nearby #2        4.0
Nearby #3        4.5
Favorite #1      5.5 
Favorite #2      5.0
Home             3.0

FAVORITES  NEARBY  OTHER

Visuals and Sound

People will expect some kind of visual and/or sound effect to show when teleportation occurs. This could include:

• Lighting VFX plus sounds
• Fading out of the current view (for the player)
• Fading away of the player's avatar (for observers) (optional, because of the overhead involved for the display engine)
• Lighting VFX and sounds upon arrival at the destination
• Fading in of the new view (for the player)
• Fading in of the player's avatar (for observers) (optional, because of the overhead involved for the display engine)

In the initial implementation, simply relocating the player's avatar to the new portal destination, plus playing a teleportation sound effect, should be enough.

Non-colliding Avatars

Near portals, it will be important for avatars to be ethereal -- that is, they cannot collide with other avatars even if they occupy the same space. Many avatars might try to access a portal at the same time, and they must all be able to get close enough to interact with it.

Teleportation Contract(s)

The smart contract that handles teleportation would manage at least two rate variables:

• Fixed MANA price per teleport
• Variable MANA rate per unit traveled (or an equivalent pricing strategy)

The rates should be updateable over time, as the economics of teleportation become clearer.

Teleportation fee calculations should probably be handled outside of the contract, to save gas.

The process that handles teleportation requests might go something like this:

1. Get current rates from the contract (or from a recent cache)
2. Calculate the teleportation fee given the fixed rate, variable rate, and any surcharges requested by the destination owner
3. When the player submits the teleport request, call the contract's teleport() function, given:

• player address
• origin
• destination
• destination owner address
• precalculated fee

4. Upon success, after MANA has been transferred and received, perform the teleportation in the game app.

There might be a significant delay for the player, since I assume the contract's teleport() method will not be validated until the next block is mined. As long as block times stay short, this delay might be acceptable. But avoiding in-game delays due to longer block times is a separate topic of its own.

Conclusion

To sum up, local teleportation using one standard portal per plot offers the following advantages:

• Improves the overall user experience by reducing boring commutes, and making it easy to travel to frequently-visited places
• Lets users bypass barren, ugly, or unpleasant locations
• Lets land owners easily travel between their non-contiguous plots of land
• Lets land owners control a teleportation visitor's initial view of their land
• Reduces congestion around public teleportation and transportation hubs
• Lets destination owners earn MANA from visitors to their beautifully-designed spaces
• Enables game-play such as tours, treasure hunts, adventure-game-style navigation, and so on.
• Can provide an "escape route" if players are stuck somewhere

On the downside, local teleportation will reduce the number of avatars that are just walking around in public spaces. But "entertainment by walking around" will still be popular as long as the public spaces are vibrant and fun, so I think this won't be a big issue.

Thanks for reading this proposal. I apologize for writing so much detail about areas where the dev team is far more qualified than me. :) I'm happy to hear any suggestions or objections to the ideas presented here.

Rob (rdixon on slack)

A number of other issues have addressed different aspects of teleportation, including:
#4
#6
#13
#24
#53

[dgrmunch]

Pretty interesting and promising proposal! :)
I can understand the idea of charging a small fee for teleporting in order to promote "walking" and traffic through common areas, but I have my concerns. I imagine people coming from other metaverses like Second Life expecting free teleportation to any place they want. I think that those fees would penalize people owning land in districts out of the "downtown", for example. And would add a friction that I don't have completely clear if is necessary. This is, of course, a personal point of view as a future user and owner of the metaverse :)

Additionally, I would consider allowing the owners of land to add free-of-charge portals to external WebVR scenes. As I posted in the #development channel of the community chat:

Considering that you are working on a-minus (and probably a bigger subset of a-frame soon), I wonder if something like the link traversal would work: aframe.io/docs/0.7.0/components/link.html#controls

I am doing some experiments with this option lately. I think that working on the way of the standard would be good to make Decentraland parcels interoperable with external a-frame scenes.
Allowing teleportation both to internal and external scenes (and maybe showing a different color when "glowing" to show the difference between an internal portal and an external portal) would be super powerful.
I imagine Decentraland as a Metaverse which can be easily plugged from/to outside resources.
This way you can access the WebVR site of a land owner and come back to Decentraland in a smooth and natural way.

I don't know. Just some thoughts for this preliminary stage. 🗡️