This is from the perspective of a new user (me) finding his way around.
After learning about the Knowledge tab I started browsing shops but quickly found that it was very inconvenient to reach them, or to find portals to get there.
This is a suggestion which I believe should be computationally feasible yet extremely useful, particularly for newcomers with limited mobility.
Any beacon should be allowed to store 3-10 “Alternate Locations.” Ideally as many as possible without straining the server. Perhaps a larger capacity if the beacon is responsible for a larger number of portals. This is the way I propose they work:
- When someone is looking for the beacon or shop or map location near that beacon, and sets that as their destination, the system currently just points directly to that destination.
- In my proposed system, the system will first look to see if any of the alternate locations is closer, and instead point the compass in that direction (or perhaps a differently colored alternate compass, showing both directions)
- Users have an incentive to correctly identify locations of relevant portals to help people find their beacon.
Concrete Example:
Suppose you are looking for my beacon at Storis II -1642N 1200E 67Altitude
One alternate location I will add to my beacon is Biitula 1074N -528E 66Altitude, which is a portal in Enjoy Divinity that goes nearby my beacon.
Another will be Circarpous I -1418N -1983E 60Altitude, which is a portal in TNT New Nixia that goes to Enjoy Divinity
Along the same lines, I might add Biitula 1384N -1121E 70A, in the Portal Seekers Hub.
Now, if you are on Biitula or Circarpous you will obviously have an easy time finding a good portal to Storis II… the system will point you in that direction. But it doesn’t stop here! Because the other involved beacons also will have alternate locations. TNT New Nixia might include a number of their portals from Circarpous to other worlds, and the same applies to PS. So on other worlds, the system would point you to the relevant portal on those worlds.
So now if the system is willing to explore the nodes within some distance (maybe 3-4 portal hops) the system can find a quick way to my beacon from any of the connected worlds. Basically recursively: Where is A? Go to B. Where is B? Go to C. Because A has marked B as an equivalent location, and B has marked C as an equivalent location, and C is the closest leaf to the user. Obviously if you are already close to A then you just get pointed to A, since A is closest.
I am vaguely aware that others have proposed that Boundless have a more sophisticated pathfinding algorithm taking into account portal physics or that the community offers an app, but I think this is a good balance. When users provide a small number of nodes to populate the graph (small number compared to every cell in every world) it’s easy to do the pathfinding server-side.
A better way might include the already-existent portal token system (instead of manually entering inexact coordinates), but would require that anyone can interact with a portal and get the necessary portal token to add the portal token to their beacon’s location inventory.