Finding a Faster Path - Development Log #549

In this week's devlog Michi talks about improving the pathfinding performance and a host of smaller improvements and bug fixes that will go into the next release.

Avatar Michi

Michi (molp)

As the release date for the routes feature gets closer (more on that in the next devlog), I decided to tackle a few issues that have been hiding in our backlog.

The issue that took the most time, but also brought the largest benefit, was the performance of the mission calculation. During mission calculation we take the parameters a player provides (ship, origin, destination, fuel usage, route parameters) and calculate a mission from origin to destination. There are a few steps necessary to get to a mission, but the most important ones are pathfinding, where we check which route the ship takes, and the calculation of the fuel consumption. From a server resource standpoint, pathfinding is the most expensive one. Long missions can easily take hundreds of milliseconds to calculate. That seems like a lot given how fast computers are, and players notice it too: after every change to the fuel sliders, there is a rather long delay until the updated route is displayed.

After careful consideration and performance measurements I decided to get rid of the external library we used for pathfinding and replace it with a custom A* search algorithm. The tests show a 10x to 20x improvement in pathfinding performance, which I am quite happy with. Let's see if this also holds in production once it is released.

There are also a few smaller improvements and bug fixes I worked on this week:

Ship names now support non-Latin characters. You can name them Спутник, Απόλλων or エンタープライズ. Emojis are not allowed, though.

The load step in the route feature got a new field "Retained". This lets you specify the amount of a material to leave at the given waypoint. Very helpful if the base produces something that it also consumes.

For a very long time, the production queues in PRODQ and PROD showed a byproduct instead of the main output of a recipe. I found out why and fixed it.

I improved the user selector so it is not clipped by a buffer border anymore. Results are now ordered differently: a perfect match first, then prefix matches, then the rest of the search results.

And finally: recently we had a commodity exchange order that was overfilled, i.e. its remaining amount was negative. Every match reduced that number even further, so the order was never removed from the CX. I removed it manually and found the bug that caused it.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!