Skip to content
Home » DEVLOG » From System View to One Continuous Galaxy

From System View to One Continuous Galaxy

GALSOV remains in pre-release Alpha development. Everything shown here — interface, visuals and behaviour — remains work in progress.

Sometimes a feature starts with one problem and ends up changing your understanding of something much bigger.

The GALSOV galaxy map has become one of those features.

At first glance, the difference between the previous and current builds might look like a denser map and a nicer zoom. In reality, it represents a much larger change in how GALSOV thinks about the relationship between the galaxy, its star systems, and eventually everything moving through them.

Old and new GALSOV galaxy map builds shown side by side.
Previous and current galaxy-map builds. The change is more than a visual refresh: the map is becoming the foundation for a continuous journey from galactic to system scale.

The original approach

The earliest GALSOV galaxy map was deliberately simple.

The map represented star systems. You used it to navigate the galaxy, select a system, and decide where you wanted to look next. The planets and moons belonging to that system were then presented somewhere else.

As development continued, that became a dedicated System View. It gave GALSOV a useful local representation of a selected star, its planets, moons and orbital relationships while allowing the galaxy map to remain focused on the larger strategic picture.

Previous GALSOV System View showing a selected star, planets and orbital paths separately from the GALSOV galaxy map.
The previous System View. The galaxy map located and selected a star system, but detailed inspection of its star, planets and moons happened in a separate dedicated view.

That was a perfectly reasonable structure for the game at the time.

But as more gameplay began to happen directly through the map, the distinction started to feel increasingly artificial.

Use the map, not another menu

A recurring theme in GALSOV’s interface development has been reducing the distance between seeing something and interacting with it.

If you can see a planet, why should inspecting that planet require moving into an entirely different presentation?

If you can see a Fleet, why should basic interaction with that Fleet begin somewhere other than the map?

That thinking gradually pushed GALSOV towards a more map-led interface: select the thing you are interested in, interact with it in context, and avoid changing screens simply because the scale of the object has changed.

At roughly the same time, there was another problem to solve.

The galaxy map itself was becoming more demanding.

More stars, more labels, more interaction and, eventually, more Fleets, Task Forces, routes, sensor information, logistics and strategic overlays would all need to coexist on the same surface.

Enter SkiaSharp

That led to what initially looked like a fairly technical question:

Would GALSOV benefit from moving the strategic map away from large numbers of individual WPF visual elements?

Several approaches were considered. The first practical direction was to introduce SkiaSharp inside the existing WPF application and give the strategic map a drawing system better suited to a large, increasingly busy spatial surface.

Performance was the obvious attraction.

But the more we looked at the problem, the less interesting a simple renderer swap became.

The more important opportunity was establishing a cleaner boundary between the game and the thing drawing it:

The simulation decides what exists and where it is. The map decides how to present that truth at the current scale.

A Fleet should not be at a location because a graphical object happens to have been placed there. A movement route should not be true because a line exists on screen. Stars, planets, Fleets, routes and later strategic information should all come from the authoritative game state, with the renderer acting as the player’s lens over that state.

That became important enough that some map-heavy Endeavour work was deliberately held back while the new strategic-map foundation was established.

It was no longer simply about making the old map faster. It was about building the map the rest of the game was going to need.

Then the System View started looking temporary

Once the strategic map was being treated as a proper spatial surface rather than simply a collection of interface objects, another question became increasingly difficult to ignore:

Why should the System View be a separate place at all?

The direction that emerged was much more ambitious.

Stars, planets, moons, Fleets and local space should ultimately occupy the same spatial presentation.

At a distant zoom level, a star system may be little more than a point in the galaxy. Move closer and the star becomes more important. Closer still and the structure of the system can begin to emerge.

Continue travelling inward and planets, moons, Fleets, installations and other local details can progressively become meaningful.

The important difference is that the underlying objects have not been moved into another screen.

The camera has moved closer to them.

Making space feel large

That idea immediately created another design problem.

Simply putting planetary bodies onto the same map does not automatically create a convincing sense of scale.

If a planet becomes visually substantial while neighbouring stars remain prominent around it, the galaxy stops feeling enormous. Instead, the whole thing begins to feel like a diagram with very large planets and very short distances between stars.

That was exactly the wrong result.

So the zoom itself had to become part of the design.

At the point where a player first begins to resolve a star system, its planets should still feel tiny in comparison with the scale they are travelling through. There needs to be substantially more camera journey between recognising a system and reaching a scale where planetary imagery and local detail become dominant.

The goal is therefore not simply to support a very large numerical zoom range.

The goal is to make that journey communicate scale.

The GALSOV galaxy map in motion

The difference is easiest to understand in motion.

In the previous build, the player zoomed through the galaxy, selected a system, and then entered its separate System View.

In the current development build, the player simply keeps going.

Previous Build vs Current Build. Pre-release Alpha footage showing the move from a separate System View towards a continuous galaxy-to-system map.

Where we are now

The current build is not the finished version of this system.

There is still substantial work ahead around presentation, levels of detail, object interaction and all of the other information that will eventually need to coexist comfortably on the strategic map.

But the important change is now visible.

The galaxy and the star system are no longer being treated as two unrelated places.

They are becoming two scales of the same place.

That matters for much more than presentation.

Movement, exploration, sensors, logistics, Fleet operations and simply understanding where something is should all benefit from sharing one consistent spatial language.

There is also something satisfying about the way this particular piece of development has unfolded.

It began with a question that was largely technical:

Can we make the galaxy map handle what we are going to ask of it?

And it has gradually turned into a rather more interesting one:

What should it feel like to move through a galaxy?

We are still answering that question, but the current build is beginning to show where that answer might lead.


If you would like to follow GALSOV as development continues, you can find project updates on Facebook and development videos on the GALSOV YouTube channel.

Leave a Reply

Your email address will not be published. Required fields are marked *