TL;DR
- Improved the automation scripting API
- Expanded mining script capabilities
- Laid architectural groundwork for smarter automation
- Updated dependencies and server environment
- Take a look at current deployed version s0.5.2/c0.5.1
Automation system improvements
Automation is one of the core gameplay mechanics, so in this sprint I focused on deepening and refining it. The first step was revisiting the existing scripts that are already used by ships.
One issue surfaced almost immediately: Lua scripts had to rely on very low-level code for basic operations, such as calculating distances between ships and objects or points in space. This not only cluttered the scripts but also made them harder to read, reason about, and maintain.
To address this, I moved these operations into the engine-level API, making them directly accessible from Lua. As a result, the following functions were introduced:
-
ship.distance_to(object)— calculates the distance between game objects, taking their radii into account -
ship.is_within_distance_to(object, max_distance)— optimized distance check for frequent calls -
utils.distance(x1, y1, x2, y2)— classic center-to-center distance calculation
This significantly simplified and cleaned up the scripting code, removing a lot of routine math from gameplay logic.
Expanding mining scripts
The next step was extending mining automation. Ships can now automatically unload mined ore directly to the station they are docked at.
For this, a new API function was added: ship.upload_cargo_to_station()
Behind this seemingly simple feature lies a more substantial architectural change. I had to introduce an additional caching layer that tracks the state of all ships in the world: which system they are in, whether they are docked, and who owns them.
This works consistently for:
- NPC ships and player ships
- automated ships and manually controlled ones
- ships without an active process (for example, sitting idle in a player’s hangar)
In parallel, the asset handling system was improved as well, which now allows NPC ships to fully participate in mining and resource unloading just like player-controlled ones.
What’s next: from declarative scripts to FSM
All of these changes made automation scripts easier to read and write. Players no longer need to implement low-level logic for common tasks.
That said, the current automation model is still too declarative. This makes more complex behavior harder to express and raises the entry barrier for players.
Because of that, I started exploring a shift toward a more imperative approach using FSMs (Finite State Machines). The idea is to let scripts focus on decision-making, while the actual execution of actions remains handled by the engine, behind the scenes.
So far, this phase was limited to research and architectural analysis. If everything goes according to plan, implementing FSM-based automation will be the next step, likely starting next week.
Dependency updates
Since I was already reworking the automation stack, it made sense to update the entire environment that supports the Lua virtual machine.
As a result, the following were updated:
- utilities related to the Lua VM
- Erlang VM and Elixir versions
- the server-side Docker container
Just a bit of internal, server-side technical magic 🙂