A different way to implement portals

Tags: #<Tag:0x00007fa0d70ae4f0>

Has it ever been considered the idea of implementing portals that are not permanently open and/or portals with more than one possible destination? So, simply put, portal conduits that work exactly like warp conduits, except that they don’t disappear after use, and whose cost is not simply related to the time they remain open, but to the amount and distance of portals they are connected to (so I fuel X for each destination portal, but overall I’ll need less portals). Note that the two suggestion don’t need to be both implemented, they work fine separately.
Not-always-open portals are probably less cool to watch than current ones (which is a heavy minus to them), but could really help lag in hubs. Multi-destination portals would change hubs entirely: one single, probably big, very decorated and cool portal. From an aesthetic point of view I would very much prefer “hubs” made this way. As they are now, they’re slowly but steadily becoming a maze of portals. I memorized the majority of the network, but I still get lost sometimes, lol.

Does anybody else think this is not the worst idea ever?

1 Like

So would the multi destination one behave just like the the one in Sanctum in terms of interaction?

Yes, it could.

Only downside I find is, you probably would want to allow portals to open to a certain location only locally (other players don’t see it), so that each player can open its own destination without having to wait “in queue” because other players are using the same portal. Which is not super-good because people traveling together would not be able to go across a portal together. Unless you make it so that a portal connected to the same destination for multiple players, visually works exactly as it does now :thinking: in the end, it would be very similar to what many MMOs do…

Yeah that’s what I was wondering how it would handle groups of people or even just a bunch of random people without queues building up. The group would need it to stay open for a certain amount of time but the random people going to different destinations would need it to close instantly so each can interact inturn to choose their destination.

Sounds pretty much like warps…

1 Like

It could be pretty interesting to have a portal that you can change the destination while it’s open. It could work the same way portals do now; requires same conduit configuration, has a running cost based on the size of the portal and consumes extra oort on start up. Once the portal is open:

You put in portal tokens and it gets consumed adding the destination to a list.

You interact with the portal and select a destination from the list.

Portal takes a moment to connect and opens to the destination and you can step through.

Like warps it would be a 1 way trip, the difference is you come out of a portal that’s already set up.

Like other portals it has a running cost in oort and not coin.

This could be great if I had multiple friends I wanted to maintain a connection to, I could visit them without needing to maintaining a portal to each. Obvious downside is it makes it cheaper to run, but I think that’s fine because the trade off is it’s one way and the destination portal would still need to be fueled from the other side as well. Of course they can always reconfigure their multi-destination portal while I’m there so I can go back home.

1 Like

Warps require time (to place conduits), the conduits themselves, and especially coins. The behavior of portals made this way would be much different imho.

That’s another option, but I don’t fully grasp your idea: why you’d want to make them one-way? Isn’t continuous reusability the main purpose of permanent portals? :thinking:

It would stay open on the one side. Ill draw up a pic in a couple hours to demonstrate my idea better.

So here’s the most basic situation:

All portals are 1x2.

The A and B pairs are normal portals that are always connected as they are now. Pair A and Pair B require 1 shard per hour to stay open. This is how portals work currently.

Portal C contains 2 tokens, one for A2 and one for B2. When you first open up portal C you select either A2 or B2, pay your initial opening cost and the 1 shard per hour to keep it running. In this example we open up to A2. If you go through C you come out at A2, but because it is a one way connection if you go through A2 you come out at A1. Portal C stays open and always leads to A2. If we interact with C we can change the destination to B2 which will then continue to stay open.

C would probably need to be made out of a different type of conduit so it can have a different recipe, it also might be a good idea to increase the cost per hour to maintain as it is a pretty powerful tool. Although it is a one way trip so that helps to even it out as well.

The major advantage I can see is I can connect to multiple places from a single portal, reducing the number of active portals I have in my base.

EDIT: Just like every portal the conduit configuration would need to match, and the cost per hour would still be based on that.

1 Like

Thanks for the time you put in your answer, now I understand. In practice, you want portals to be one-way so that we can continue using the already existing system, and just expand it with these multi-destination portals. Correct?

My idea was pretty much the same as yours for functions and costs, except that, when you build portal C and add to it destinations A2 and B2, you’re also adding destination C to portals A2 and B2 (automatically or manually, doesn’t change my point). Therefore you can travel from C to A2, then from A2 to A1, OR change destination in A2 to return to C. That’s simply because I don’t see any real purpose in limiting A2 to only A1, AND because it would leave all portals functionalities exactly as they are now, just adding to them the possibility to expand their destinations list. Also, you wouldn’t need any new conduit block.

I think there is a use for each kind of portal and they each fill different needs. I kept the example as simple as possible to demonstrate the idea, but it could certainly get more complex for sure.

I wouldn’t want to change how portals work, mostly just add in a different type with some different functionality. I think there would be plenty of use for single destination portals. Shops for example would still want a dedicated store front on various shopping hubs, but they could also have a multi-destination portal so multiple players could set up a direct link with their home via a single portal.

You could certainly have both ends of the portal be a multi-destination portal so you can travel back it’s just a little harder to illustrate and explain.

The other advantage of this is that instead of having multiple player portals on a hub always open, generating portal effects and looking into other worlds you could have a single portal that can be configured to go to each players home.