There's been talk about wormholes and stargate for a while. How to make the interface work without confusing lane crossing has recently gelled in my mind so here's the basics.
The little "?" off of Beta means there's an unexplored wormhole at beta. The circle is a little smaller than the one around systems. If you target your fleet on it, the feel will end up at the other end the next turn. Assuming it lead to system Gamma, once explored under it would appear "to Gamma" in slightly smaller type than the system names.
Once explored, left-clicking within the circle will jump the galaxy map to the destination system.
Probably there should be some sort of icon instead of the "?", but there's time to worry about that later.
This assumes (or asserts that it should be so) that Wormhole/Stargates are all come in pairs. If there was another one at Beta there would be another extension with it's own clickable target.
If possible the the Wormhole/Stargate target should extend out from the system half-way between the widest angle created by two lanes meeting the system -- i.e. appear where there is the most room.
Advantages:
* Wormhole/Stargate lanes don't cross and visually tangle with normal lanes.
* Doesn't require the player to know where the Wormhole/Stargate ends up to travel on it.
* Saves scrolling across the galaxy to plot a fleet path through a long Wormhole/Stargate
Interface for Wormholes/Stargates
Re: Interface for Wormholes/Stargates
That seems intuitive to me. <thumbs up>
Code released under GPL 2.0. Content released under GPL 2.0 and Creative Commons Attribution-ShareAlike 3.0.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Interface for Wormholes/Stargates
There's no concept of "unexplored wormhole" in the game; systems either have a lane/wormhole to a particular system, or don't. If you want pathfinding and movement mechanics for wormholes to be treated as normal valid path routes in future (ie. automatically determined move pathes use wormholes when it is optimal to do so), it probably has to stay this way. If they are to be treated as a special case that have to be manually selected to be used, then that can change...eleazar wrote:The little "?" off of Beta means there's an unexplored wormhole at beta.
- eleazar
- Design & Graphics Lead Emeritus
- Posts: 3858
- Joined: Sat Sep 23, 2006 7:09 pm
- Location: USA — midwest
Re: Interface for Wormholes/Stargates
Not knowing where the wormhole opens out is not of primary importance. A good deal of the surprise is contained in finding out who and what is there. Letting the pathfinding understand and use wormholes is, IMHO very important.Geoff the Medio wrote:There's no concept of "unexplored wormhole" in the game; systems either have a lane/wormhole to a particular system, or don't. If you want pathfinding and movement mechanics for wormholes to be treated as normal valid path routes in future (ie. automatically determined move pathes use wormholes when it is optimal to do so), it probably has to stay this way. If they are to be treated as a special case that have to be manually selected to be used, then that can change...eleazar wrote:The little "?" off of Beta means there's an unexplored wormhole at beta.
But i think not knowing where the wormhole opens out would be nice.
Perhaps if you think of it this way it would be possible:
An unexplored wormhole entrance is sorta like an unexplored system. You know how to get there, but you don't know what else may be connected to that system. Then a wormhole on the map would be a pseudo system whose travel distance from the host system is magically 0, and when reached instantly transports the fleet to a different specific system.
Re: Interface for Wormholes/Stargates
I see a few potential treatments, which of course get a bit more tricky to implement as they get more desirable.
Approach A: Pretty easy I think, and reasonable, would restrict rendering more than pathing. The graph discovery for pathing would be the same as now -- you know the existence of a starlane/wormhole as soon as you get sufficient visbility into a system that connects to either end of it. For rendering a wormhole, you don't ever get the mini-circles hanging off alone, you only see an end at all if you have had visibility into the near system at that end such as gives you that near system's starlanes. Whether the wormhole circle is then rendered as a circle with ? or as a specific designator of its destination would be made dependent on what visibility you've had of the system at the far end. In this simplest approach, full information about the wormhole can be gained by regular exploration of both ends along starlanes. Most or all the new code absolutely needed for rendering & visibility could be contained entirely in the wormhole rendering code. I guess also a little bit of new code would be required for fleet window destination text, but very very similar to existing code.
Approach B: like the above, but with a little extra restriction on rendering -- the ends of the wormhole would remain circle-? until you'd actually traveled it. The wormhole could have some kid of object associated with it which you only gain visibility of when travelling the wormhole, and that is what determines if the wormhole ends are rendered as circle-? or something more specific. If this were the only change to the above though, then the pathing system would have more info than is rendered on the map, and the 'proposed path' dashed lines might give away where a wormhole leads to.
Approach C: like B, but making pathing info consistent with rendered info -- you are not told the wormhole destination & pathing does not know it, until after you have traveled it once. Rendering could be as in Approach B, but the specific object associated with the wormhole would be a special kind of system, never rendered, sitting in the middle of the wormhole. This system would have an effect like the spatial distorter effect, automatically and instantly kicking you out the other end. On first thoughts it seems it would take three such systems in a wormhole to disrupt pathing info until the wormhole was actually travelled. We could add an extra flag to keep such systems from showing up on the system side-panel or in the pedia. So, a but more code, but reasonably doable I think, and what seems to me like a pretty desirable treatment.
Approach A: Pretty easy I think, and reasonable, would restrict rendering more than pathing. The graph discovery for pathing would be the same as now -- you know the existence of a starlane/wormhole as soon as you get sufficient visbility into a system that connects to either end of it. For rendering a wormhole, you don't ever get the mini-circles hanging off alone, you only see an end at all if you have had visibility into the near system at that end such as gives you that near system's starlanes. Whether the wormhole circle is then rendered as a circle with ? or as a specific designator of its destination would be made dependent on what visibility you've had of the system at the far end. In this simplest approach, full information about the wormhole can be gained by regular exploration of both ends along starlanes. Most or all the new code absolutely needed for rendering & visibility could be contained entirely in the wormhole rendering code. I guess also a little bit of new code would be required for fleet window destination text, but very very similar to existing code.
Approach B: like the above, but with a little extra restriction on rendering -- the ends of the wormhole would remain circle-? until you'd actually traveled it. The wormhole could have some kid of object associated with it which you only gain visibility of when travelling the wormhole, and that is what determines if the wormhole ends are rendered as circle-? or something more specific. If this were the only change to the above though, then the pathing system would have more info than is rendered on the map, and the 'proposed path' dashed lines might give away where a wormhole leads to.
Approach C: like B, but making pathing info consistent with rendered info -- you are not told the wormhole destination & pathing does not know it, until after you have traveled it once. Rendering could be as in Approach B, but the specific object associated with the wormhole would be a special kind of system, never rendered, sitting in the middle of the wormhole. This system would have an effect like the spatial distorter effect, automatically and instantly kicking you out the other end. On first thoughts it seems it would take three such systems in a wormhole to disrupt pathing info until the wormhole was actually travelled. We could add an extra flag to keep such systems from showing up on the system side-panel or in the pedia. So, a but more code, but reasonably doable I think, and what seems to me like a pretty desirable treatment.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: Interface for Wormholes/Stargates
@eleazar: hi, can wormhole on image have more starlanes to be reachable from more systems, or just one so you must cross Beta to aces wormhole?
Re: Interface for Wormholes/Stargates
I think wormholes are pretty consistent treated pretty much everywhere as just having two ends, and that will certainly be easiest for us to deal with.biza wrote:@eleazar: hi, can wormhole on image have more starlanes to be reachable from more systems, or just one so you must cross Beta to aces wormhole?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
- eleazar
- Design & Graphics Lead Emeritus
- Posts: 3858
- Joined: Sat Sep 23, 2006 7:09 pm
- Location: USA — midwest
Re: Interface for Wormholes/Stargates
Agreed on both counts.Dilvish wrote:I think wormholes are pretty consistent treated pretty much everywhere as just having two ends, and that will certainly be easiest for us to deal with.biza wrote:@eleazar: hi, can wormhole on image have more starlanes to be reachable from more systems, or just one so you must cross Beta to aces wormhole?