|
|
TubeMapZ1_TFL.png (141,478 bytes) |
|
|
fixed an orphan thought |
|
|
This is the main reason I think the "realistic" map type is odd - its only that the map layout is not optimized in those setups. Physical location is meaningless in the planet layout since there is no way to travel between them without wormholes |
|
|
maybe we need to add a warpdrive or something to travel without wormholes? yes wormholes are faster but bypassing defenses like the ai can is sometime more important. of course the downside is this is out of supply and triggering deep strike rules. maybe make it a hyperdrive cannon that will target systems and any ship entering it comes out the other end a specified time later like a wave arrival without a wormhole connection. loadable with only say 500 ships per mark and firing delay of 2 minutes? unit cap 1 |
|
|
The problem with such things is building galmaps uses massive amounts of computation if not done right. A great way to compromise between computation and readability would be to allow the player to move around planets on the galmap, like the game planarity. I remember one of the devs saying something like that was planned, but dropped off when they moved to the unity engine. |
|
|
Prezombie: if that does get implemented then this algorithm could be used as the "auto-arrange" button |
|
|
HTL: Planarity (making a node graph not have any overlapping connections) is not an easy problem, computationally speaking. it's relatively simple to check if planarity is possible. If there is a subset of the graph with five nodes all connecting to the other four nodes, like a star inside a pentagon, planarity is impossible. If there is two sets of three nodes, where all six nodes connect to the three nodes not within their set, planarity is impossible. If neither of those patterns exist, planarity is possible. It's fairly simple, if slow, to check if a set of nodes is planar, but there isn't any way to easily convert a non-planar map into a planar map, an "auto-arrange" program is beyond the scope of anyone. I'd be happy with being able to rearrange stars by hand, preferably with a group-grab selection to move solved subsets around, and just enough to make the "realistic" maps less confusing, no need to sort it completely. |
|
|
I don't know that non-planarity per se bothers me much. Having an X of connections isn't bad, because it's obvious what's meant. The real problem comes when a connection goes through an already-cluttered section of the map, making it very difficult to tell what it's connected to. |
|
|
@FunnyMan One way to define "a path going through a cluttered area" is if an edge crosses over but does not connect to many different other edges (though an exact value for "many" would need to be nailed down). This should be moderately easy to check, depending on how nasty computing line intersections in your engine is. However, is it feasible [i]in the general case[/i] to avoid and/or to correct such a situation? (Sure, for some map types such as X, tree, and grid, are easy to detect and to correct) However, this ease does not necessarily generalize) If detecting and correcting is a reasonably easy operation, then maybe an automated "weak detangling" could be implemented. If even this weaker requirement is computationay infeasible in general, well, you're out of luck. As Prezombie stared, giving us the regranting us the ability to rearrange positions of planets in the galaxy map is the most flexible solution. |
|
|
untangle_1.png (66,878 bytes) |
|
|
untangle_2.png (22,084 bytes) |
|
|
To further illustrate, added screenshots from Simon Tatham's "Untangle" puzzle: 1. The generated puzzle (80 points). 2. The automatically-derived solution. Puzzle and source code here: http://www.chiark.greenend.org.uk/~sgtatham/puzzles/ I would not be opposed to a manual-untangling option, but there really is something attractive to me about having the map generator create unique subway-style maps on its own. |
|
|
> The automatically-derived solution. Um, no. The solution is not derived from the puzzle, the puzzle is derived from the solution, because the solution is generated first. The points are scattered on a grid, and then it follows rules mixed with a bit of randomness to add all the lines. This is the easiest way to make a puzzle with a guaranteed solution, as it never adds lines that overlap. Those puzzles are made backwards, the solution first, which is then scrambled, which isn't how the basic galmap algorithms are done. But basic idea in the puzzle generator minus the scrambling and the artificial limit of as many lines as possible with at most four connections would make visually interesting galmaps that would be easy to read. |
|
|
Actually, it occurs to me that we're making this harder than it needs to be. The general problem requires that the topology of the network be maintained. Most of the time, we don't really need to do that. A connection that goes way across the map can be broken and new connections added if needed. |
|
|
This. A thousand times this. I can't say how many times I've been turned off by several different map types by the utter chaos that was the map, making it practically impossible to determine what was where. |
|
|
Even though I think it would be pretty peachy-keen to have a tube-style map generator, the "untangle" option goes a long way to making several previously un-viewable maps quite viable. Closing this issue for now. |
|
|
Closing per your comment. Glad it's working out :) |
- Anonymous
