[PATCH] Reject excessively long transport routes

[maxim13]

Hello!

I would like to propose a patch for Simutrans Standard that prevents passengers, mail and freight from choosing transport routes that are excessively long compared with the direct distance to their destination.

The problem

Consider four stops positioned roughly in a straight line:

Code Select Expand

A — B — C — D

Now create a circular schedule:

Code Select Expand

A -> D -> C -> B -> A

Passengers travelling from A to nearby B may board the vehicle and first travel in the opposite direction through D and C.

This is not only counter-intuitive. Depending on pay_for_total_distance, the same route may also increase revenue by artificially inflating the distance travelled.

The problem is particularly noticeable with freight. It was possible to build a chain of lines and transfers that carried cargo back and forth between distant parts of the map several times before finally delivering it. In payment modes based on the distance actually travelled, this made it possible to earn revenue from a deliberately lengthened journey.

Filtering a single schedule is not enough: the same artificially long journey can be split between several lines, for example A -> D and D -> B. Individual services and the complete chain of transfers therefore both need to be checked.

With the new limit enabled, such a journey is rejected. The total length of the entire route is checked, so splitting it between several lines no longer bypasses the limit.

Proposed behaviour

The patch adds a new world setting:

Code Select Expand

max_route_detour_percent = 250

A value of 250 means that a transport route may be no longer than 250% of the direct distance between the selected origin and destination stops. Setting the value to 0 disables the check completely and preserves the previous routing behaviour.

Both distances use Simutrans' existing Manhattan distance:

Code Select Expand

abs(x2 - x1) + abs(y2 - y1)

The route length is the sum of the distances between successive schedule entries, including waypoints.

The 2.5x default includes headroom for circular routes. On a square loop with side length a, the direct Manhattan distance between stops at the midpoints of opposite sides is a, while either half of the perimeter is 2a. The resulting ratio is 2.0; a limit of 2.5 adds 25% headroom above that baseline for moderately rectangular or imperfect loops, tile geometry and small diversions.

Very elongated rectangular loops may legitimately require a higher value, so the setting can be increased or disabled. Feedback on an appropriate default based on real player-built networks would be especially useful.

What the patch changes

• Checks the ratio both within an individual service and across a complete chain of transfers.
• Continues searching for a geographically shorter alternative even when its ordinary routing weight is higher.
• Returns a separate ROUTE_TOO_LONG result when a transport path exists but every candidate exceeds the limit. A genuinely disconnected destination continues to return NO_ROUTE.
• Prevents a convoy whose path to a transfer is excessively long from collecting a packet whose route was made possible by another, shorter service to the same transfer.
• Calculates outward and potential return passenger routes independently. This matters for one-way circular services.
• Recalculates packets already waiting at stops after the transport network changes.
• Rebuilds the routing graph and reroutes waiting packets when the setting is changed in a running world.
• Adds a separate Route too long passenger statistic to stops. Mail and freight receive the same routing result but are not added to this passenger counter.
• Registers an optional RouteTooLong skin symbol. Existing paksets continue to work with a text fallback; applying the patch does not require a new graphical resource.

The patch does not change the revenue calculation itself.

Savegame compatibility

The setting and the new halt history slot are saved from savegame version 124.6 onwards. Existing savegames continue to load. Packets waiting at stops are recalculated: they are assigned a valid alternative or removed if their remaining route is no longer available or has become excessively long.

Packets already on board are not removed in the middle of a journey. Their remaining route is checked the next time they are unloaded.

Validation

The patch was prepared against the official SVN trunk at r12238.

• The SDL2 build completes successfully.
• The complete automated scenario suite passes: 309/309.
• The standalone .diff was checked with svn patch --dry-run in a second clean r12238 working copy.

The added regression tests cover:

• an excessively long journey within one schedule;
• a long journey split between several lines and transfers;
• a locally excessive leg;
• selection of a valid alternative with a higher routing weight;
• the exact 2.5x boundary and waypoint distances;
• freight routing;
• short and excessively long services between the same pair of stops;
• removal of a packet that was already waiting when the network changed.

Known limitations of the first version

The complete route from origin to destination is checked when a new passenger or cargo packet is created. However, if the transport network changes after the journey has begun, the next recalculation can only check the remaining route from the current stop. A packet does not remember where its journey began or how far it has already travelled.

A packet also remembers its next transfer stop, but not a particular line or convoy. If several lines serve the same transfer and each of them individually fits within the limit, the packet may be carried by any of them rather than necessarily the one originally selected by the route search.

Comments on the patch, suggestions for improvement and test results from real player-built networks would be very welcome.

For easier code review and discussion, the changes are also available as a GitHub pull request.

The forum is currently not allowing me to upload the SVN patch, even after I split it into files smaller than 64 KB. I have therefore temporarily made the complete patch for trunk r12238 available as a GitHub Gist.

Download the complete SVN patch directly.

I would be grateful if a forum administrator could enable this patch upload for my account or increase my attachment limit. I could then also attach it directly to this topic.

[prissi]

Personally, I think the pay for distance setting take care of that. Also, detour three times longer than a straight route are nothing special in reality. Like oil from Saudi Arabia to Europe around South Afrika ...

If a server admin wants to forbid such routes, setting pay_for_distance on actual distance reduced could take care of this.

Also, NO_ROUTE does not search the entire network but gives up after an amount of transfers. It cannot really tell if a route is too long or there is actually nothing.

However, I think taking your idea further can give the right output. Current routing is not very good. The weights are just counts stop distances in integers. Replacing by distances is not enough, as 100 tiles by airplane is certainly different than 100 tiles by ship. If the weights would be related to an effective distance (maybe the averaged loaded max speed of the lines/vehicles of a segment or, as a start, just the speedbonus speed of the current mode of transport of that link), or the theoretical free capacity (total capacity times the "speed" from before), then competition in servergames would become feasible. These two values require very little extra bookkeeping.

Experimental has something like this, actual travel time routing, at the expense of a lot of CPU and memory. Unfortunately, the table based routing does not work with weak virtual servers on large maps as the tables are not updated fast enough. The gradual update of standard could run continuously, also reflecting changes in connections (or even based on actual capacity or transported volume with more bookkeeping). However, this is only of interest for pax (passengers and mails). Hence, the calculations of weights is probably best be separated from the other goods.

[maxim13]

Thank you for the feedback. I think I did not explain the main purpose of the patch clearly enough.

The goal is not to make routing more realistic or to claim that long detours never exist in reality. The goal is to prevent a gameplay exploit where deliberately making a transport network worse can make it more profitable.

With the current routing and distance-payment rules, a player can deliberately send cargo back and forth across the map before delivering it. The same detour can be split across several lines and transfers. In payment modes based on travelled distance, the player can then earn more money precisely because the route is unnecessarily long.

This creates an undesirable gameplay incentive: an intentionally inefficient network can be more profitable than an efficient one. That is the behaviour the proposed setting is intended to prevent.

`pay_for_total_distance=2` is one possible way to remove the financial incentive, but it changes the payment model for the entire game. A server administrator may want to retain payment based on travelled distance while preventing players from exploiting it with deliberately inflated routes. The detour limit provides this control independently of the payment mode.

From the gameplay perspective, `ROUTE_TOO_LONG` has the same practical outcome as `NO_ROUTE`: the passenger, mail or cargo packet is not assigned that route. It is a separate result primarily to provide useful feedback to the player.

If the station statistics only reported `NO_ROUTE`, the player could assume that no transport connection had been built to the destination. `ROUTE_TOO_LONG` instead tells the player that a structural connection was found within the normal routing limits, but that the existing line or chain of transfers was rejected for being excessively long. The player can then inspect the network and optimise the relevant line or transfers, or adjust the detour setting if such routes are intentional.

This distinction does not claim that `NO_ROUTE` exhaustively searches the entire network. Both results remain subject to the existing transfer and routing limits. It only distinguishes a route rejected specifically by the new detour rule from a route not found by the normal search.

The oil route around Africa is a legitimate detour caused by real-world constraints. That is not the situation this patch is trying to simulate. The target is a player deliberately constructing an unnecessarily long route because the game rewards that behaviour. The limit is therefore a gameplay rule, not an attempt to determine which real-world routes are realistic.

Administrators who consider large detours appropriate for their map can increase the limit or disable it by setting it to `0`.

More broadly, this reflects the general direction of my contributions. My previous vehicle-specific speed bonus patch, which has not yet been accepted, addresses another case where the game mechanics can encourage an unintuitive decision: ordinary urban transport used for its intended purpose may be less viable than building unnecessarily fast tunnels or elevated infrastructure. This patch addresses the opposite-looking but related problem, where an intentionally inefficient route can be rewarded with greater profit.

The common goal of that earlier patch, this patch, and possible future work is not realism for its own sake. It is to make the game more intuitive and playable: sensible and efficient player decisions should lead to sensible results, while deliberately exploiting abstractions in the simulation should not be the more profitable strategy.

[prissi]

I personally think a routing cost based on link capacity would prevent that as well. Also, for passengers, this is sometimes rather accidental. Imagine two continents, linked by a single ship or airline. Half of the passengers would not go there, even though it is the only way and quite realistic, again. The patch would force players to make more links.

The same problem would happen on a server with different regions assigned to different players.

The root cause of simutrans game economics is that money from a network with growth almost exponentially, as every extra station opens up new connections and thus new trips. At a certain point (rather quickly, typically after less than 5 game years) money is of no concern but overwhelming of available transport capacity becomes the main challenge.

Capping the transport link lenght, will cause less travellers, and thus reducing the second challenge after money has become no concern whatever.

[maxim13]

I think our disagreement comes mainly from looking at the problem from different players' perspectives. You are describing a mature multiplayer game in which money is no longer a meaningful constraint and network capacity has become the main challenge. I am primarily concerned with the experience of an ordinary player starting Simutrans with its default settings.

By default, Simutrans uses `pay_for_total_distance = 0`, so revenue is based on the distance actually travelled. A player may therefore see someone travelling to a nearby stop via a large part of the map, occupying capacity on several services and generating more revenue precisely because of the detour. To someone unfamiliar with the internal routing rules and alternative payment modes, this is likely to look like a routing bug that rewards an inefficient network.

The other payment modes are not complete substitutes for the proposed limit. With mode `1`, payment is calculated relative to the next transfer, so an artificial detour can be split across several lines and each leg will once again be paid separately.

Mode `2` removes most of the financial incentive, but it does not correct the route itself. A fully loaded line may even record negative transport revenue while temporarily carrying passengers away from their final destinations. An ordinary player may struggle to understand why full vehicles not only incur running costs but are also paid a negative amount for transporting their passengers. This is likely to appear as an error in the revenue calculation. In a multiplayer game, it becomes even less intuitive because the negative and positive parts of the same journey may be assigned to different players.

The proposed patch addresses the problem during route selection. If the initially preferred route is excessively long, the search can continue and select a more reasonable alternative, even if that alternative requires more stops or transfers. The passenger then reaches the destination sooner without occupying vehicles on unnecessary parts of the network.

This does not merely remove a financial exploit; it can also help relieve congestion. A passenger taking a fivefold detour generates far more passenger-kilometres and occupies transport capacity for much longer than the journey requires. If no acceptable alternative exists, the excessive journey is not generated and therefore does not burden an entire chain of services.

In my view, the late-game capacity challenge should come from carrying growing demand over reasonable routes, rather than from unnecessary traffic created by routing behaviour. A well-designed network should make better use of its available capacity instead of being disadvantaged compared with a deliberately elongated one.

The patch does not impose an absolute limit on the length of a connection. A ship or aircraft may cross the entire map. It only limits an excessive detour relative to the journey's origin and destination. On networks where large detours are unavoidable, including servers divided into regions controlled by different players, the limit can be raised or disabled.

The purpose of the patch is therefore neither to force players to build more connections nor simply to reduce passenger numbers. It is to avoid assigning clearly excessive routes, free lines from unnecessary traffic, and prevent deliberately inefficient transport from being more profitable than a sensible alternative.

[victor_18993]

The problem I see is that you're proposing a solution that limits the player's freedom in how they build their network.

I agree that Simutrans is complex for a new player, but that's why we're working on improving the tutorials and advanced mechanics with contextual information.

Regarding the possible improvements to passenger distance and tolerance, Extend has implemented mechanics that calculate trips differently. Have you reviewed it?

Not all new mechanics necessarily fit the standard. That's why forks like Extend and OTRP exist. If you review them, you'll see that they incorporate other mechanics that differ from the standard.

[makie]

I haven't tested the specific patch yet, but I like maxim13's approach.

This might also resolve the issue many players face regarding goods—such as meat—being delivered to markets via fishing grounds at sea, or similarly absurd, convoluted delivery routes. Players often ask for an "unload-only" stop because goods end up being transshipped at unwanted locations.
Our forum is full of threads and posts about this problem.

[maxim13]

The problem I see is that you're proposing a solution that limits the player's freedom in how they build their network.

Not all new mechanics necessarily fit the standard. That's why forks like Extend and OTRP exist. If you review them, you'll see that they incorporate other mechanics that differ from the standard.

I would like to start by saying that I genuinely regret that projects such as Simutrans-Extended exist as separate forks, because they fragment an already small community. This does not mean that their ideas have no value. I would simply prefer different approaches to coexist within the same project whenever that is technically possible.

I have tried to understand the philosophy of Simutrans-Extended. My impression is that it generally aims for a greater degree of realism. Standard, as I understand it, treats Simutrans primarily as a game, with its own abstractions, limitations, and optimization challenges.

Some decisions in Simutrans-Extended that are intended to increase realism raise questions for me personally. For example, using a more geometrically realistic distance calculation may sound reasonable, but the game engine still does not allow diagonal slopes. As a player who enjoys optimization, clean straight lines, and efficient routes, I am not convinced that making one isolated part of the simulation more realistic necessarily makes the game as a whole more coherent or enjoyable.

Regarding the concern that my proposal limits the player's freedom, I believe meaningful constraints are an essential part of game design. Without them, a meticulous player will eventually discover that one of the most efficient strategies is to build a single hub, perhaps near the centre of the map, and connect practically everything through it. Passengers travelling to a neighbouring town may then take a high-speed train hundreds of kilometres to that hub and travel all the way back, instead of taking a direct but less profitable local bus. This generates much more paid distance and therefore much more profit for the player. Building a coherent network of reasonably direct connections is considerably harder, yet the game currently does little to encourage it.

My proposal does restrict this strategy, but I consider that a useful gameplay constraint. Players will still be able to use hubs, transfers, and indirect routes, but passengers will not choose a route if it requires an excessive detour relative to the direct distance to their destination. Yes, `pay_for_total_distance` can make this strategy less profitable. However, as I mentioned earlier, that setting creates its own unintuitive consequences for the player. The community has still not chosen to enable it by default, which suggests that it is not a satisfactory general solution.

More broadly, I see nothing inherently wrong with having many settings. What matters is that the defaults provide the most logical, intuitive, and enjoyable way to play.

Particularly important settings that reflect genuinely controversial game-design choices could be placed directly in the game-creation dialogue. One example of such a choice is the already mentioned question of whether Manhattan distance should be used by default. Making these fundamental alternatives visible and accessible might allow substantially different approaches to coexist within a single project and perhaps even make it possible to reunite Simutrans and Simutrans-Extended.

[prissi]

Regarding the concern that my proposal limits the player's freedom, I believe meaningful constraints are an essential part of game design. Without them, a meticulous player will eventually discover that one of the most efficient strategies is to build a single hub, perhaps near the centre of the map, and connect practically everything through it. Passengers travelling to a neighbouring town may then take a high-speed train hundreds of kilometres to that hub and travel all the way back, instead of taking a direct but less profitable local bus. This generates much more paid distance and therefore much more profit for the player. Building a coherent network of reasonably direct connections is considerably harder, yet the game currently does little to encourage it.

Never been to France? The TGV network is very much hub (Paris) with spokes with very little lateral connections. The quickest way from Nantes to Bayeux is over Paris, nearly doubling the distance travelled.

Or from Cambridge UK to Oxford, UK, you have to travel trought London with a train, nearly twice the distance and slower than local busses.

However, everyone does it for planes. I flew happily over Paris to Berlin from Warsaw, even though I saw Berlin already halfway before touching down in Frankfurt, again 3x the actual distance.

Additionally, such detour routes require a lot of capital to build them as they need to have high troughput or the congestion will make them low profit quickly compared to normal routing. At the point when one can built long distance highspeed lines, money is usually of no concern anymore.

The money argument is very weak: The different pay for distance modes had been added for exactly that purpose. Use 2 and no money is made anymore.

Then there are player who prefer ring lines, at least for larger cities. These would be also penalized a lot even though they are quite common in practice.

And in network games, passengers rely on few exchange hubs, needing detours. (Since important hubs are not clear from the start.) Your patch would need to be disabled for network games or it would be very hard for a new player to connect to an existing network.

Makie's argument

This might also resolve the issue many players face regarding goods—such as meat—being delivered to markets via fishing grounds at sea, or similarly absurd, convoluted delivery routes. Players often ask for an "unload-only" stop because goods end up being transshipped at unwanted locations. Our forum is full of threads and posts about this problem.

carries most weight, in my opinion. For this, a maximum detour in transfers makes sense, as it would still allow for oil tankers to go around the cape to Europe as long as the oil is not transferred. So a transfer limit different for goods which coudl be different from pax. Also in real life, goods are seldomly transferred.

If the routing of pax takes into account the actual speed of connection (weight from distance and bonus speed + stop penalty) then detour routes would be less used if a more direct route exist unless the detour make them arrive faster, like in real life. This makes it much harder to make artificial detours without limiting the freedom of the player to use ring lines or build a world with airplanes as the major mode of transport.

[victor_18993]

I would like to start by saying that I genuinely regret that projects such as Simutrans-Extended exist as separate forks, because they fragment an already small community. This does not mean that their ideas have no value. I would simply prefer different approaches to coexist within the same project whenever that is technically possible.
I have tried to understand the philosophy of Simutrans-Extended. My impression is that it generally aims for a greater degree of realism. Standard, as I understand it, treats Simutrans primarily as a game, with its own abstractions, limitations, and optimization challenges.
Some decisions in Simutrans-Extended that are intended to increase realism raise questions for me personally. For example, using a more geometrically realistic distance calculation may sound reasonable, but the game engine still does not allow diagonal slopes. As a player who enjoys optimization, clean straight lines, and efficient routes, I am not convinced that making one isolated part of the simulation more realistic necessarily makes the game as a whole more coherent or enjoyable.
Regarding the concern that my proposal limits the player's freedom, I believe meaningful constraints are an essential part of game design. Without them, a meticulous player will eventually discover that one of the most efficient strategies is to build a single hub, perhaps near the centre of the map, and connect practically everything through it. Passengers travelling to a neighbouring town may then take a high-speed train hundreds of kilometres to that hub and travel all the way back, instead of taking a direct but less profitable local bus. This generates much more paid distance and therefore much more profit for the player. Building a coherent network of reasonably direct connections is considerably harder, yet the game currently does little to encourage it.
My proposal does restrict this strategy, but I consider that a useful gameplay constraint. Players will still be able to use hubs, transfers, and indirect routes, but passengers will not choose a route if it requires an excessive detour relative to the direct distance to their destination. Yes, `pay_for_total_distance` can make this strategy less profitable. However, as I mentioned earlier, that setting creates its own unintuitive consequences for the player. The community has still not chosen to enable it by default, which suggests that it is not a satisfactory general solution.
More broadly, I see nothing inherently wrong with having many settings. What matters is that the defaults provide the most logical, intuitive, and enjoyable way to play.
Particularly important settings that reflect genuinely controversial game-design choices could be placed directly in the game-creation dialogue. One example of such a choice is the already mentioned question of whether Manhattan distance should be used by default. Making these fundamental alternatives visible and accessible might allow substantially different approaches to coexist within a single project and perhaps even make it possible to reunite Simutrans and Simutrans-Extended.

I think we're misunderstanding each other.

OTRP exists because the Japanese community requires very specific mechanics that are unique to them. Extend was born out of the need for some developers to further develop a more realistic economy.

What I'm trying to say is that the community isn't broken or divided; there are simply three development paths for Simutrans, and each one responds to a specific need, not whims.

If you look into it, you'll see that there's an exchange of knowledge and mechanics between the different development paths. They can coexist, but in Standard, mechanics must be adapted to Standard; in Extend, they adapt to Extend; and in OTRP, they adapt to OTRP.

I think you have a confused view of the Simutrans community.

If you believe this mechanic should be in Standard, you must adapt it to Standard to avoid breaking it. That's why I indicated that these types of mechanics fit better in Extend or OTRP.

I definitely encourage you to submit proposals, and above all, welcome to Simutrans and thank you for starting a contribution.

Best regards.

[maxim13]

One point that I would still like to emphasise is the experience of a new player encountering Simutrans for the first time.

A player who downloads the game from Steam will normally play with the default settings. They will probably not know that Simutrans-Extended exists, understand the history of the routing system, or know which alternative payment setting might compensate for its behaviour. They will judge Simutrans by the game presented to them and by how its default mechanics behave. If that player enjoys optimisation, route management and studying statistics, they will eventually notice that a deliberately inefficient route can sometimes be rewarded more than a sensible one. This is unlikely to feel like useful freedom. It is more likely to feel like an exploit that undermines the entire optimisation challenge. Many players will not search the forum for a configuration workaround; they may simply conclude that the game's systems are arbitrary and lose interest.

I want the default experience to give these players the greatest possible enjoyment from designing efficient networks, managing routes and understanding the numbers. This is precisely why I believe this patch belongs in Simutrans Standard: it directly improves the core optimisation experience that the game presents to every new player.

At the same time, I agree that large multiplayer maps may rely on a few major interchange hubs and require much larger detours. But the patch does not force those games to change. Their administrators can simply set

`max_route_detour_percent = 0`

and retain the current routing behaviour without rebuilding or reorganising the network.

I do not see a contradiction between improving the default experience for new players and preserving the established behaviour of specialised multiplayer maps. The default can provide a meaningful optimisation challenge, while maps with different requirements can disable the limit completely. The precise default value can, of course, be adjusted based on testing and feedback.

[prissi]

According to feedback, default players have big troubles in making money at all, and it gettign the first vehicle started. I have still to get the complain that making money is to easy from a beginner.

What come up is unintended routing of goods over too many transfers, that is true. However, your patch may not help as the coonections could be still very straight.

I still think you raise valid concern. But I feel that a cap is too simple and would lead to disappointment when long-distance air connections do not generate many passengers even though they seemed the fastes connections due to the detours. The proper way out could be a time-distance dependent routing and then an optional cap.

[danivenk]

According to feedback, default players have big troubles in making money at all, and it gettign the first vehicle started. I have still to get the complain that making money is to easy from a beginner.

What come up is unintended routing of goods over too many transfers, that is true. However, your patch may not help as the coonections could be still very straight.

I still think you raise valid concern. But I feel that a cap is too simple and would lead to disappointment when long-distance air connections do not generate many passengers even though they seemed the fastes connections due to the detours. The proper way out could be a time-distance dependent routing and then an optional cap.

That sounds a lot like the time based routing like it exists in OTRP (and I believe in Extended too).
I believe that this current implementation of this patch proposed seems a bit like a big axe to try and fix something that is a bit more nuanced. The way you'd want any good package to travel realistically/logically is completely dependent on the way type, good type etc. Air Cargo will wanna move differently than Truck Cargo, Tram pax different than Bus pax etc, altho in case of different way types the differences aren't as big as different good types as has been mentioned before.
Yes the routing could be better in some cases as it currently works in Standard, but just put a general cap on it feels a bit off.

[maxim13]

I agree that time- and distance-dependent routing would be a more complete solution. However, I also think the simplicity of the proposed mechanic is an advantage.

Even without knowing about the limit beforehand, a player could see in the stop statistics that some passengers consider the route too circuitous. They could then investigate the reason and understand the mechanic through small local experiments. For the kind of player who chooses Simutrans, I think this could be an interesting and understandable learning experience. More experienced players who know about the exploits described here may instead see it as a sign that the simulation is continuing to improve.

We can always postpone a relatively simple improvement in anticipation of a more sophisticated solution, but then risk never implementing either. If this patch later interferes with a better routing model, it can easily be made inactive by changing the default setting. I therefore see the cap as a practical intermediate step, potentially remaining as an optional safeguard after time- and distance-dependent routing is implemented.

Regarding new players having difficulty making money with their first service, I am only talking about passenger networks here. I think this reveals a more fundamental onboarding problem in Simutrans. Passenger networks become efficient when their different parts work together. However, building such a network from the start requires a large number of lines and bus stops, while the maintenance costs of those stops consume all the initial profit.

I have been thinking about some relatively inexpensive ways to improve this. They would need a separate discussion, but the main ideas are:
1. The default settings for a new game could generate genuinely small villages, where a single stop near the town hall covers the whole settlement. A beginner would then not immediately face a large city without knowing how—or with what money—to establish adequate service.
2. We could allow basic roadside stops on city roads with zero maintenance cost.
3. To prevent the exploit of covering an entire city with such cheap stops, these stops could not be joined with other stops to form a larger station.
4. Players could be allowed to build zero-maintenance city roads near attractions and factories, making it possible to place the same basic zero-maintenance stops there as well.

[victor_18993]

I agree with evolving the mechanics or making passenger and freight movement more efficient, as long as it's a natural evolution without unbalancing all the modes of transport.

As for the difficulty for new players, this is completely true; they have trouble when they come to Simutrans, but mainly related to building a subway or figuring out how to do certain things. I think we should address this by using more contextual information so that the mechanics the engine allows with certain tools are more transparent to new players and they have some guidance, so they don't get frustrated trying to set up a large transport network.

What Maxim13 points out is totally valid—it tries to tackle the barrier to entry for new players. Where I differ is in the way to approach the problem. For me, one of the hallmarks of Simutrans is the depth of its mechanics and the challenge of pursuing efficiency in transport networks. That's why I don't think lowering the difficulty level is the right way to go, because players aren't looking for OpenTTD—that game already exists—nor are they looking for Transport Fever—that game already exists too. We sit right in the middle of these products: we aren't 3D, but we aren't just the legacy of Transport Tycoon either. We are Simutrans, and we offer deep mechanics so you can build a highly complex transport network and, if players want, with nice aesthetics.

My question is, how do we balance this without breaking what veteran players are already used to?

[danivenk]

I agree that time- and distance-dependent routing would be a more complete solution. However, I also think the simplicity of the proposed mechanic is an advantage.

Even without knowing about the limit beforehand, a player could see in the stop statistics that some passengers consider the route too circuitous. They could then investigate the reason and understand the mechanic through small local experiments. For the kind of player who chooses Simutrans, I think this could be an interesting and understandable learning experience. More experienced players who know about the exploits described here may instead see it as a sign that the simulation is continuing to improve.

We can always postpone a relatively simple improvement in anticipation of a more sophisticated solution, but then risk never implementing either. If this patch later interferes with a better routing model, it can easily be made inactive by changing the default setting. I therefore see the cap as a practical intermediate step, potentially remaining as an optional safeguard after time- and distance-dependent routing is implemented.

Regarding new players having difficulty making money with their first service, I am only talking about passenger networks here. I think this reveals a more fundamental onboarding problem in Simutrans. Passenger networks become efficient when their different parts work together. However, building such a network from the start requires a large number of lines and bus stops, while the maintenance costs of those stops consume all the initial profit.

I have been thinking about some relatively inexpensive ways to improve this. They would need a separate discussion, but the main ideas are:
1. The default settings for a new game could generate genuinely small villages, where a single stop near the town hall covers the whole settlement. A beginner would then not immediately face a large city without knowing how—or with what money—to establish adequate service.
2. We could allow basic roadside stops on city roads with zero maintenance cost.
3. To prevent the exploit of covering an entire city with such cheap stops, these stops could not be joined with other stops to form a larger station.
4. Players could be allowed to build zero-maintenance city roads near attractions and factories, making it possible to place the same basic zero-maintenance stops there as well.

It also really depends on the pakset how hard or not the initial gameplay is. Also a lot of your points seem to me to go towards "abusing the system" when in reality it is mostly a single player sandbox game where you can set the rules of your gameplay yourself. Heck if going bankrupt is a problem for you you can put on free money (a kind of creative mode).
As for your points, the town sizes and amount can be set in the initial game setup window.
Most of your other points refer to possible halts/roads without any maintenance cost, which I feel is not the right option. But if that is something people'd want they could either contribute to or request it to the makes of the pakset. To me that doesn't seem like the game engine should be responsible for since well a lot is customizable already.

I do also agree with Victor in terms of that we shouldn't just gut out the difficulty of Simutrans. I think it is also moreso an play ethic difference. Players that complain about it being hard to make money, what did they expect? To make quick money at the start and not having to worry again? Isn't part of the game the challenge that comes with it? If the money is really a problem you can always turn on free money at the start and not worry about it. Maybe this is just me coming off as a player speaking off their high chair dictating how things should and shouldn't go, but as has been mentioned before maybe it is moreso the problem of there not being enough briefing off how the game works to new players than the tutorial/scenarios do. I mean you don't just let a kid jump into the ocean before you teach them how to swim do you?
But oh well I might just be ranting IDK.

Important note for you @Maxim, I'm not saying you shouldn't think about it, just that I question whether or not it is the right way. Importantly I can be wrong.

[maxim13]

I mean you don't just let a kid jump into the ocean before you teach them how to swim do you?

Of course, and when I say that we can offer new players a default starting point in villages, I'm talking about exactly what you're saying: don't immediately introduce a world that requires a comprehensive passenger transportation network. When I say that maintaining city bus stops should be free, I'm more talking about poor balance at the start of the game, where a bus stop puts the player in the red if it only fills up once a month. But for the player, it can actually be the mechanism for smoothly immersing themselves in the game's mechanics (cities roads, also free on start of the game). I understand that such free improvements can disrupt the balance, which is why I'm writing that it shouldn't connect to other stops. It should have a small capacity; its "free" nature comes at the cost of inconvenience and inefficiency later in the game.

But in general, this all requires a separate discussion.