Thanks to everyone who tried it out; I hope you enjoyed dragging the circles around.
I should point out that the layout itself is not my own work. It's done by the force layout module of d3.js (https://github.com/mbostock/d3/wiki/Force-Layout). In particular, I based it on the example here: http://bl.ocks.org/mbostock/950642.
Thanks again to Keith for offering even more help. I think I know how to handle the compressed saves, and how to rewrite the coordinates safely too. I'd have to change the layout slightly to make sure they fit in the game's permitted rectangle, which might not be so easy.
Well, not to short-circuit your experiment here, but it would actually be great if I could get a usable version of the code involved and just have the game do this either automatically for some map types, or on-demand for others. Not that we have to do it that way, but it seems like the most convenient way for players to benefit from it
That said, if you're able to figure out the "stay within rectangle X,Y,W,H" part first that wouldn't be bad.
I poked around the D3 pages you linked and didn't see anything about licensing, is it GPL, LGPL, Public Domain, or what? Or is there some general policy for GitHub stuff (I haven't checked)? To the point: are they ok with me rewriting the relevant bits into C# for use in an existing commercial game? Any conditions on that?
I do have a couple of questions:
- The in-planet locations of wormholes are not in the save file? It seems like instead the map's seed is stored, and then the wormhole locations are regenerated on loading.
- Is it the same for metals and crystals? If not their locations, is the number of metal/crystal deposits on a planet recorded anywhere in the save?
The metal and crystal and wormhole spots are indeed regenerated on load. This can actually lead to them moving or changing in number if I change certain things in mapgen. Though I think wormholes tend to not move nowadays even when I do that. But I can't find any reason in the code for them not to do so