AI Plays Simutrans

[Andarix]

Simutrans 124.5
pak64.german 0.124.4.0.1
sqai_rail 0.10.0.0

[Andarix]

Simutrans r12086
pak64 124.4 r2223
sqai_rail 0.10.1.1 (includet Simutrans r12096)

[victor_18993]

This is really impressive. The network already looks much more developed and coherent than I would have expected from a scripted AI.

What I find especially interesting is that it is no longer just building railway connections, but is gradually becoming a much more complete transport player. Projects like this could add a lot of life to single-player games and could also be very useful for testing paksets and detecting unusual situations in the engine.

I would be very interested to see how it performs over a longer game: whether it remains profitable, renews old vehicles, reacts to congested lines, and adapts its choices to different paksets.

Great work, and thanks for continuing to share its progress.

[Andarix]

The script-based AI featuring railways has existed since 2020 and has been part of Simutrans for several years.

The script-based AI itself has been around for much longer and was created by Dwachs. However, it can only handle trucks and ships.

[Andarix]

...
I would be very interested to see how it performs over a longer game: whether it remains profitable, renews old vehicles, reacts to congested lines, and adapts its choices to different paksets.

...

Well, if you're interested, why not run a map with scripted AI?

before


afterward


What has been done?

- Platforms were extended at the ends
- Electrification of the line
- Train with electric locomotive

The script-based AI is capable of adjusting the number of convoys on a line to match transport demand.


Since freight rail transport becomes unprofitable over time in pak64, generating a profit in the later years is likely to prove difficult. Currently, the script-based AI cannot yet convert routes from one mode of transport to another (e.g., rail to road).

Another issue in pak64 is that there are no cargo aircraft available after 1998. Currently, the situation is such that the script AI cannot send convoys to the depot and retrieve them from there.

The Script_KI is certainly capable of handling very long trains as well.

[victor_18993]

Thanks for the clarification — I had underestimated how mature the scripted AI already is.

The before/after example answers several of the things I was wondering about. Extending the platforms, electrifying the line, replacing the train and adapting the number of convoys to demand goes well beyond simply constructing a railway connection.
The remaining limitations also make sense. Changing an existing service from rail to road, or retiring a transport mode when the pakset no longer provides suitable vehicles, is a much higher-level decision than renewing a convoy within the same mode.

The pak64 examples are especially interesting because they show how difficult it is to separate AI behaviour from pakset economics and vehicle availability. A service may become unprofitable even when the AI is making reasonable operational decisions.

It looks as though the railway management side is already quite capable, while the next major step would be strategic multimodal conversion and knowing when to abandon or replace an entire type of service. Thanks for showing the before/after examples — they make the current capabilities much clearer.

[Andarix]

Unprofitable routes and "dead" routes (incomplete chains) are already being removed. However, there are still various issues and errors. That said, if a route represents the final link between two industries in an established chain, it should not be removed—even if it is unprofitable—so as not to break the chain.

Testing these functions is, however, very difficult.

The fact that the script AI is not permitted to build tunnels is also a disadvantage in some cases.

The biggest problem right now is crossing rivers with shallow banks. River-road crossings are no longer built if the speed limit of the selected road is too low.
It used to be different; the behavior was changed around version 123.x.x.

Bridges aren't being built either, though.

Paksets can either accommodate the scripted AI or as is the case here place further obstacles in its path.

[victor_18993]

This is becoming much more capable than I initially realised. Thanks for taking the time to explain the current limitations so clearly.

Some of the remaining problems, especially bridge and tunnel construction or anything limited by the functions exposed to the scripted AI, may eventually require changes on the C++ side of Simutrans rather than only changes to the script.

If you reach a point where you need help investigating or implementing something in the C++ code, please feel free to let me know. I would be happy to have a look and help where I can. I do not want to interfere with your work or direction, but I would be glad to support the engine-side part if it would be useful.

It is a really interesting project, and I would love to see how far you can take it.

[Andarix]

The biggest help would simply be more games featuring scripted AI.

Unfortunately, there is hardly any feedback on this. Consequently, there are no error reports and certainly no save files (autosave is disabled for most users) where the errors can be reproduced.


A somewhat older assessment of the script AI.
https://forum.simutrans.com/index.php?msg=203555
I don't know why all threads from before June 2025 were locked.

Changes and issues are listed in the following posts.

Another issue aside from bridge construction on flat banks is the fixed starting capital.

This means that the starting capital remains the same regardless of the map size. However, large maps inevitably involve long distances, making it difficult to establish a profitable route a challenge that affects both the AI and the player.

It would be desirable here for the starting capital to be defined based on a specific size, such as a 512x512 map. If the map is twice as large, the starting capital should increase accordingly. Determining the appropriate scaling factor is the tricky part, unless it can be defined via `simuconf.tab`.

Since the paksets have quite different starting capital amounts, defining this via simuconf.tab would make a lot of sense.

[prissi]

Also, I think having the internal waybuilder accessible to the AI would halp. Like the itnernal waybuilder calaculating a route (includign tunnel and bridges) and the AI can tweak it and finally it is build in one run. Like the internal AI and the player does it when click on two far away points. The AI woudl even profit from the parallel track feature for humans ...

[Andarix]

.... Projects like this could add a lot of life to single-player games and could also be very useful for testing paksets and detecting unusual situations in the engine.

...

By the way, the script AI also sets up traffic lights to manage traffic on the road.

pak128


For the foreseeable future, pak128 will not be a pakset suitable for the scripted AI. The reason for this is that the pakset appears to be designed around the mass transport of passengers; it is difficult to make any real progress relying solely on freight transport.

Factors include high vehicle prices and the reference speed used for the speed bonus a threshold that many freight vehicles barely exceed, if at all.



Attached are my current test cards.
Simutrans 124.5
p64 = pak64
p64g = pak64.german
p128 = pak128

[victor_18993]

Also, I think having the internal waybuilder accessible to the AI would halp. Like the itnernal waybuilder calaculating a route (includign tunnel and bridges) and the AI can tweak it and finally it is build in one run. Like the internal AI and the player does it when click on two far away points. The AI woudl even profit from the parallel track feature for humans ...

I followed up on the idea of reusing the internal way builder.

It does look viable, but there is one important complication: the builder does not keep calculated routes safely between separate calls, and it relies on global, non-reentrant resources. That makes exposing it directly to scripts a larger and riskier change than it first appears.

Before attempting a general API for it, there is a much smaller issue that may already explain part of the current problem: the bridge-planning API limits its search to ten tiles and does not allow the bridge to end on flat ground.

I think the best next step would be to address that limitation first and add reproducible tests around it. Tunnels and a more general route-planning API could then be handled separately, in smaller and easier-to-review patches.

[victor_18993]

Script API: bridge planner limited to 10 tiles
While looking into why

Code Select Expand

sqai_rail sometimes struggles to cross obstacles, I found a limitation in the Script API rather than in the AI itself.

Code Select Expand

bridge_planner_x.find_end() currently calls the internal bridge planner with two fixed values:

Code Select Expand

max_length = 10
also_flat_ends = false
Because of that, scripts cannot find a bridge endpoint more than 10 tiles away, and they cannot end a bridge on flat ground, even when the bridge descriptor would allow it.
Looking at the history, the 10-tile limit seems to have been introduced when the bridge builder was rewritten in r11608 and the binding was updated with a literal value. It does not look like an intentional API restriction.
This only affects scripts. The normal bridge tool used by players does not go through this function.
I have prepared a small patch that adds two optional arguments:

Code Select Expand

bridge_planner_x.find_end(pl, pos, dir, bridge, min_length)
bridge_planner_x.find_end(pl, pos, dir, bridge, min_length, max_length)
bridge_planner_x.find_end(pl, pos, dir, bridge, min_length, max_length, flat_ends)
The existing call keeps exactly the same behaviour, so current scripts are not affected unless they choose to use the new options.
A

Code Select Expand

max_length of 0 means "as far as the bridge descriptor and game settings allow". The value is still safely capped to avoid problems with the current

Code Select Expand

uint8 loop counter.
I have kept this first patch deliberately small. It only changes the planner API; it does not modify

Code Select Expand

sqai_rail yet and it does not change bridge construction itself.
The new tests cover bridges below, at and above 10 tiles, flat endpoints, descriptor limits, invalid ranges, scenario restrictions and compatibility with the old call.
The full automated test suite passes: 206/206.
The diff is 4 files, +252/-3, with only 53 lines of C++; the rest are tests.
To keep the discussion and review focused, I have opened a separate thread for the patch here:
https://forum.simutrans.com/index.php/topic,24008.new.html#new
I have stopped here so the API change can be reviewed independently before adapting

Code Select Expand

sqai_rail.