The production screen gave me a warning sign: in manual mode I could push every allocation slider to 100 percent. I could see the controls moving, but I could no longer tell whether the choice meant anything in the simulation. Selecting a policy raised a related problem because the allocations did not follow it the way I expected. I had asked how to make production interactive; this was a more useful answer than another layer of polish. The rules and the interface had to agree about who controlled the resources.
That mismatch turned up elsewhere in the project. A curved fleet path suggested an orbital transfer that the sustained-burn model was not actually performing. Later, inspecting the world opened too many windows and made it hard to keep track of what I had selected. The work became a sequence of questions about trust: what does this control change, what does this line on the map mean, and which piece of information am I following?
Making production a decision
I asked for real minerals and processing rather than an overly abstract mineral system. Later, the allocation controls exposed a practical problem: in manual mode I could set every slider to 100 percent, and policy selections did not behave as I expected.
My requested behavior was specific. Policy should determine the allocations when a policy is selected. Direct slider editing should belong to manual mode. That connects an interface detail with the actual resource constraint the player is trying to manage.
Fleet control followed a similar direction, from movement controls toward queued orders and previews that explain what will happen. The point of an order display was to make a plan inspectable before time advanced.
The map needed to match the movement model
For the solar system, I asked for bodies moving on rails around a central sun. Full gravity simulation was not the goal.
The fleet route display nevertheless needed to look like the selected drive mode. A curved route initially suggested a familiar Hohmann transfer even though the simulation used sustained burns. The resulting handoff asked for a mostly direct projected intercept, ending at the destination’s future arrival position.
Its proposed visual curve used a shallow Bézier offset, capped relative to route length, with a midpoint flip marker and an optional projected destination marker. It explicitly deferred low-energy transfer mechanics, transfer windows, and true orbital dynamics. That was a rendering and communication problem, not permission to quietly replace the simulation’s travel model.
Too many windows
Later, I described the interface as having too much going on. The response was not simply to remove information; information is a large part of this game. I wanted a persistent overview of the selected object with a way to follow details.
The interaction design separated three things:
| State | Purpose |
|---|---|
| Main selection | The object the primary interface follows |
| Temporary preview | One reusable view of a related object |
| Pinned previews | Explicitly retained comparisons |
I specified that a temporary preview should not steal focus. Selecting another related object could retarget it; pinning it would preserve that view and allow a new temporary preview.
The foundation before the panel
The reported Patch 3A implemented this as a headless interaction model before connecting it to the running UI. Body, Colony, and Fleet references included a world generation, so a numeric ID reused after loading another world would not make an old selection valid again.
The model handled pinning, unpinning, missing targets, delayed requests for closed windows, and copied snapshots for rendering. Successful world replacement cleared the old state; failed replacement preserved it. A navigation request existed as validated data without immediately performing a gameplay action.
The supplied report recorded 14 internal interaction scenarios and a seven-target CTest run. A later integration report described eight passing targets, including checks that stale selection intentions were rejected after world replacement. These are historical reports of those revisions, not a new validation run.
The persistent Information Panel
The later Patch 3C report said the native implementation had gained a persistent, read-only Information Panel with live Body, Colony, and Fleet overviews. It reserved a left-side workspace and applied shared constraints to ordinary floating windows while transitioning the older Inspector.
I had approved using a separate React redesign as a visual reference while keeping implementation in the native environment. The polished design-study images should therefore be read as references, not screenshots proving the native game’s state.
The latest report in this selected history had the native Information Panel merged, with nine headless and ten UI-enabled test targets passing. It also named the floating-window overlap that remained. I had moved closer to an interface where a selection, a preview, and a pinned comparison each meant something predictable, even after loading a different world.