The Starmap was part of the first version of Captain Zero, but this is my most sophisticated attempt. .
Also the stars are connected based on the player's "range" variable, so it's possible to have stars on the starmap that you just can't get to unless you upgrade that range.
It was inspired by the 1980s game, Star Control 1, which had a rotating 3d starmap with lines between the stars and their neighbors:
Star Control 1 3d StarMap (go to time 1:54)
Sorting out paths to nearest neighbors is something that, in a formal language like c# would have been much easier with a simple recursive method, but in an object centered graphical game platform like Construct 2, it's not as straight forward.
The fact that it can be done and in just a few hours, however, shows us just how powerful and versatile Construct 2 is. In a 2D game engine I've created a 3D starmap rotating along the y axis. The problem with "drag and drop" style game makers has always been the limitations imposed by its framework. Do do something outside the game-types it was designed to create usually required a lot of work-arounds that make its advantages useless --if you even could do it. So far with Construct 2 I haven't found anything stopping me from doing what I want pretty easily.
This wasn't super easy though. To make lines between stars and their neighbors, I was faced with the problem of creating a 1 to many relationship for each star, without having any redundant connections. In other words in a method where I go through all the stars once, if I made a line from a star to its neighbor, how do I stop its neighbor from making a line back?
Establishing this kind of self-referential cardinality is something more the job of SQL than of a graphical game making tool. With say LINQ, or a simple recursive function, it would be no problem.
I tried lots of ways, but in the end it turned out to be as simple as "only connect stars to other stars on to the right of them." Once I figured this out, it doesn't matter the order in which the stars are connected... as long as the connections are 1-way, then other stars can't connect back. I could have used up, down, or left for the same effect.
The other problem you run into with Construct 2 is relating a single type of object to other instances of its type. Events narrow down the objects so if you say "all stars such that" you end up with a subset of the stars, and from there you only have that subset and can't easily relate them back to a different subset.
To get around this when setting up the lines, I had to make temporary "stars2" objects on top of the stars, so then I could make connections from a subset of stars to a subset of stars2 without any problems. I saved the original stars' UID to an instance variable in each stars2 so then I could connect the lines to the stars based on that UID, and get rid of the stars2 objects.
Sorry... it helps to talk about it!
Another problem was the hud wheel that controls the starmap rotation speed. I wanted it to move like you're physically putting your finger on a dial and turning it around. Try to find that behavior in Construct 2!
What I ended up doing was making an invisible "pointer" object in the center of the wheel and when you click on the dial, it locks the pointer to point at the mouse xy. As long as you're holding down the button on the dial, it points that pointer at the mouse. From there I can translate the angle changes in the pointer to the dial's rotation angle and voila... it's a rock-solid dial control.