There were a few new issues discovered, mostly in that tricky area of providing enough guidance so that players could find their way to the game's conclusion through exploration and discovery, without too much handholding. But I think considering the fact that tens of thouands of players have played the game in the past month (more than played it during all 20 months of Early Access), the number of players who experienced any significant issues was relatively small.
Since launch I've been working on various updates with QoL improvements, bug fixes, language patches and improved controller support. There's currently an opt-in beta that some brave commanders have been testing for the past week and there's a patch with some additional fixes in the pipeline.
Earlier this week I implemented a change to my content creation tools that made things a tiny bit smoother. I'm mentioning it now because it was essentially the same thing as a feature in the game: the ability to zoom toward the mouse on the map. The default zoom centers on the player's ship, but there's an optional mode with the CTRL modifier (which can be inverted in options) that instead zooms toward the player's mouse.
This was one of those features that conceptually sounded simple, but for some reason I struggled to get it working "right".
The way the map works is that the game keeps a 1:2500 scale model of the universe with icons positioned for each map visible object, and the map camera normally stays centered on the player icon. "Zooming" changes map camera's elevation.
My initial attempt at "zoom to cursor" was to zoom, but instead of centering on the player, center on the mouse. This didn't work, because as soon as the player started to zoom, the camera would jump all the way across the map and then additional zoom inputs would send the camera further and further away.
My second attempt was to use the normal zoom method of changing the camera's elevation, but then also to move the camera toward the cursor by small increments. This was closer to the desired behavior, but I struggled to come up with the correct formula for how much to move the camera as a function of distance and elevation, both of which were constantly changing.
Some time after putting this feature on hold, I was planning a bike ride and noticed that Google Maps did exactly what I wanted and wondered if I could figure out what formula they used. I zoomed up and down while moving the map around and tried to see how the center moved and then I realized I was thinking about the problem wrong:
There is a point on the map underneath the mouse. Whenever you zoom, that point stays under the mouse. So if I figured out the distance between the map coordinates of center of the map and the map coordinates of the mouse before zooming, then after the zoom step I just needed to move the map camera by that amount:
if (shouldZoomToMouse)
{
Vector3 endMapMouse = MapMousePosition;
Vector3 mouseDelta = endMapMouse - startMapMouse;
mouseDelta.y = 0;
mapCamPos -= mouseDelta;
mapPanOffset.x -= mouseDelta.x;
mapPanOffset.y -= mouseDelta.z;
mapCamera.transform.localPosition = mapCamPos;
}
I've subsequently noticed that this is identical to how zoom works in Photoshop and other applications, but it was Google maps that prompted the connection, possibly because my brain needed to be primed with the "map" association.
Besides possibly being of assistance to some future dev, the main point of this minor technical annecdote is that often in game development you can describe what a feature is supposed to do, but you don't really understand it until you have a working example in front of you. Sometimes it's an example that you had to spend hours and hours prototyping, other times (like this) it's when someone else has solved it before you.
Changed depots in acceptance branch