1 route per type, regardless of destination
The routes efficiency is dependent of the type, and the code set the most efficient route available, but the problem is that road and river routes are much faster to get than sea routes, if we allow 3 undefined routes per city, all coastal cities will use 3 sea routes as they are far more efficient.
Excellent, that would make coastal cities far more important, which makes sense since they're having access to more cities and probably access to more unique/exclusive goods*. You could choose to prioritise river routes over coastal/oceanic (I don't know which of these are most efficient really). If you want to, you could let each city start with 1 land trade route, connected to the capital city, or the closest friendly city.
Instead of a limit of 1 trade route per type, or 3 per city, why not just add "trade buildings" and award 1 trade route of a specific type, per building?
For e.g:
- Riverine traders (requires city to be adjacent to river) = Gives 1 river trade route
- Maritime traders (requires coastal city/harbour) = Gives 1 coastal/ocean trade route
- Caravansery (requires adjacent land tile or city?) = Gives 1 land trade route
Just like housing, you'd be able to construct a higher tier trade building to get an additional trade route of the same type. However, it shouldn't be more expensive to get an additional trade route of the same type, instead of a different type. Land routes are inherently less effective, so you wouldn't want to build a caravansery unless it gave access to a unique/special goods that are unobtainable from naval routes. Of course, you could always limit the number of trade routes (and trade route buildings) by the city size.
On the other hand, a possible benefit of land routes would be to get roads, which would make it easier to establish effective systems of couriers (messengers on horseback), since such couriers could be faster than ships.
If possible, it would be good if river trade routes could be combined with naval routes, meaning that you could trade between cities on different rivers, connected by a common sea. But since you say that sea routes take longer time to get, this suggestion would require even more processing. Also, this depends on the ships used, since only flat-bottomed ships with a low draft can (safely) navigate shallow rivers, while they would be disadvantaged on the sea where you'd want more freeboard. One solution to this would be to only let the city that is furthest downriver trace coastal routes from the mouth of the river to coastal cities/harbours.
I'm already keeping track of the current routes, so it's only the length of the route that need to be tested for enemy units before recalculating, but keeping track of the most efficient route between two cities is a good idea, and try to update a current route to that one first (after being changed because of enemy units) will make things faster. Still have to be updated from time to time for sea routes (because of canal cities that can be added and, obviously, roads)
Yes, I suppose that new sea trade routes would need to be updated every time a new coastal city / harbour is founded. When it comes to choosing which city to trade with, for coastal/riverine trade routes at least, proximity isn't as big of a deal as it is for land routes. Rather, it is the resources that your city demands, and the resources that the other city wants, that should determine the destination.
We'll need the routes to/from capitals for stability at one point or another. A centralized network was my first idea, we could go back to that. I'd need a step by step description for multiple center in the same civilization.
This would depend on whether you choose to introduce trade buildings (suggested above), and if so you could simply start with the city that has the most trade routes (being a commercial center), and if tied, you can go by total stock, then by population size, and so on. I'm not sure I can suggest something that would be easy to code or more efficient to execute than the current code, but I'll share my thoughts anyway:
You could either restrict trading to internal trade first, and then do a second run with external trade (like the current system), or you could resolve all trade simultaneously. For each turn you'd need to check which cities that are connected to the trade network, and exclude those cities whose access are dependent on a blocked route. The excluded cities would form a separate trade network, until the blockade ends in a following turn. Within each network (whether internal cities first, or all cities combined) you could use one of the two following ways of matchmaking:
Either go by:
a) available goods (ability to supply) or,
b) purchasing power (ability to consume).
a) Ability to supply:
1. Start by summing up every city's total stock, all goods combined. At the same time, sum up the total stock of goods that the cities demand*, i.e. the amount of goods that each city has capacity to store and use.
2. Start with the city that has the highest total stock, all goods combined, resolve ties by starting with the city that have the least goods demanded*, otherwise pick the one with largest total population.
3. Match the current city with the other city that have the greatest demand* of its goods. And mark those types of goods to be transferred as "locked" for further trade in both cities. (E.g. Wheat is locked in city A and B)
4. Continue matching with other cities until all goods of the city are "locked" or can't be traded.
5. Then go on to the next city, that has the second highest total stock (minus locked goods), and continue matching cities.
6. Once all cities and their goods are matched, or no trade routes are available, then:
7. Transfer goods and update stock.
b) Ability to consume:
1. Start by summing up every city's total stock, all goods combined. At the same time, sum up the total stock of goods that the cities demand*, i.e. the amount of goods that each city has capacity to store and use.
2. Start with the city that has the highest total demand, all goods combined. Resolve ties by starting with the city that have the highest population or goods available for trade.
3. Match the current city with the other city that have the greatest supply of goods demanded. And mark those types of goods to be transferred as "locked" for further trade. (E.g. Wheat is locked in city A and B)
4. Continue matching with other cities until the city's type of goods are all "locked", unavailable for trade OR if the total demand of goods is now lower than the next city in line (OR lower than the city that started out with the lowest demand).
5. Then go on to the next city, that has the second highest total demand (minus locked goods), and continue matching cities.
6. Once all cities and their goods are matched, or no trade routes are available, then:
7. Transfer resources and update stock.
AFAIK automated units are impossible with the current modding access.
So trader units can't be modified? That sucks, but then we can disregard my suggestions regarding automatic units. Less possibilities make for easier choices.
Some computers won't like to process every players at once at then end of the game's turn, better to process each player during their turn, start is easier from a coding perspective with the available events.
Good to know! I'm so used to playing with simultaneous turns in multiplayer, and I thought that maybe all CPUs did their turns simultaneously or something.
*
Goods. I use the word goods for the items that a city have in stock, or which they can stock should they acquire them through trade. I avoid using the word resources to avoid confusion with resources gained from tiles.
*Demand. I use the word demand to mean items that a city have capacity to store and use, minus the current stock. E.g. if the stock of Item A = 20/100. Then demand of item A = 100-20 = 80.
