Because this is a long post, it might be helpful to summarise the post for those who do not want to read it all in depth. In short, to make the most out of Simutrans-Experimental features that use the absolute values of journey times (in particular, comfort, catering and journey time tolerance), as well as to make long-distance rail and any sort of aviation viable, it is necessary to use much larger maps and to adjust other aspects of the scale used in Simutrans accordingly, abandoning the 1 tile = 1km rule that has previously obtained, replacing it with something closer to 1 tile = 200m. The advantages of and challenges in doing so are explored further below.Note
: This feature has now been implemented in Simutrans-Experimental version 6.0 (and later). See here
for a description of how the feature now works as implemented.Introduction - why change the scale?
In my work to separate different types of vehicles for different uses (for passengers: local/rural; inner suburban; outer suburban; and express), as well as testing the new journey time tolerance feature, it has become apparent that the current scale in Simutrans does not work well for such separation. Simutrans (deliberately) has two, inconsistent scales used at once: the graphics scale and the distance scale. In the graphics scale, one tile represents about 40m (in Pak128.Britain, at least - other paksets may vary). Traditionally, in the distance scale, 1 tile represents 1km, or 1,000m.
However, when I first put journey times and average speeds into Simutrans, I realised that the 1km/tile scale was unsatisfactory. Extrapolating from the vehicles' speeds as displayed assuming 1km/tile meant that, at ordinary speeds, a 'bus journey a few tiles accross a small village would be presumed to take 30-45 minutes. A train ride between two neighbouring towns would be assumed to take hours. Since I was keen to introduce a system whereby different vehicles had different levels of comfort, and passengers would tolerate certain comfort levels for only so long, and that I wanted to use realistic time scales for that tolerance, I had to make an alteration to the time scale. At the time, I decided simply to multiply all the times by 30% (the figure is adjustable in simuconf.tab). That gave values much closer to reality.
In version 5.0, I introduced the journey time tolerance feature. This means that passengers will not travel at all if their journey takes too long. Different passengers have greatly different journey time tolerances, which is partly random and partly based on how far that they want to go (at default settings, fewer passengers are generated for longer distance travel), anything from one to twelve hours at default settings. When I tested this feature with the 30% figure and existing saved games, I found that there was an enormous drop-off in the number of passengers willing to travel, and many previously profitable saved games plunged heavily into loss. After eliminating a few bugs and further testing, I found that the problem was that the journeys were simply being registered as being too long. Further reducing the 30% to 20% made journey times make much more sense relative to the size and position of towns and the size of vehicles.
However, the consequence of this was that, even on what has so far been considered a fairly large map of 512x512 or so, there is little scope for fast, comfortable travel. Express trains would be of limited benefit and aircraft of little use at all. With the 20% multiplier, journey times are based on the assumption that each tile represents 200m. 512 tiles at 200m is 102.4km, or 64 miles (assuming that 1 mile = 1.6km). Even with the old 30% multiplier, that would still be equivalent to a map side of only 96 miles.
Real-world long distance transport, however, involves much greater distances than that. Even setting entirely aside international aviation that will probably always be beyond what Simutrans can cope with, short-haul aviation is not generally considered worthwhile unless the equivalent land journey takes longer than three hours. To take three hours, a 64 mile journey would have to be undertaken at an average speed of only fractionally over 20mph. That clearly makes aviation entirely pointless on a 512x512 map.
Even taking more generous circumstances: a 1024x1024 (or even 1024x512) map, and long-distance rail travel instead of aviation. There, the longest side would be the equivalent of 128 miles. At fairly lax timings, long-distance trains often average around 75mph (this is the average speed assumed for the deliberately ponderous Night Riviera sleeper service from London to Cornwall: if they made it any faster, the train would arrive far too early in the morning). High-speed rail of the sort prevalent in continental Europe may well produce average speeds of well over double that. Even assuming an average speed of 75mph, however, a journey of 128 miles would take less than one and three quarter hours. That is only just inside what might, in railway terms, be considered "long distance". Most long distance rail journeys even in a small country such as the UK take far longer than that. (For reference, the distance between London and Bristol is 106 miles. The distance between London and Edinburgh is 332 miles). Even on a 1024x1024 map, therefore, aviation would be nearly useless, and most railway journeys would be either in the "local" or the "outer suburban" distance bracket. The solution - larger maps
The only solution to that problem is to have much larger maps. Consider, for instance, a 2048x4096 map. The longest dimension - 4096 tiles - is equivalent to 512 miles, and there is the possibility of diagonal journeys. Aviation, at least short-haul (and possibly into the realms of medium-haul), becomes sensible, and long-distance railway journeys are a realistic possibility. Even a slightly smaller map than that: say, 3840 x 1792 would give a maximum dimension on the longest side equivalent to 480 miles, again, with the possibility of diagonal journeys. That would also be sufficient for at least short-haul aviation and long-distance rail travel.
The advantages of such an approach are more than just having a larger area on which to play: there is also far more incentive to use appropriate types
of vehicle and network. There can be a real separation between outer suburban and long distance, which is not possible with the current scale, with large, complicated networks of suburban rail or 'bus routes in larger urban areas that, with the previous scale, would be confined to one or two simple 'buses or trams. The impact of different levels of acceleration, comfort, and loading time for different types of routes will interplay delicately with each other and produce networks with very different characteristics depending on the circumstances. ChallengesEconomic balancing
However, increasing the scale in one place must be balanced by increasing it in others, or else the delicate balance of the game will be upset. I list below all of the things that I have thought of that will need commensurate changes to match the scale. I should be very grateful if anyone else could point out any other things that also will need to be changed.
- Passenger/goods revenue per tile will need to be decreased
- The building and maintenance cost of ways will need to be decreased
- The per tile running cost of vehicles will need to be decreased
- The use of "km" in the UI will have to be discontinued everywhere where "km" is said to represent a tile
- Towns will need to be made larger
- The coverage radius of stops will need to be increased
- The passenger level will need to be decreased (although the journey time tolerance feature might have this effect to a sufficient level in any case)
* Further consideration is required as to whether or not this should include tunnels and bridges - one might say that the existing tunnels and bridges are more in proportion with the graphics scale than the distance scale, and therefore that increasing the scale will help their cost to balance better with that of ordinary ways. A similar consideration applies with aircraft runways.
All of these things can be achieved by changes in the paksets and/or simuconf.tab
, but changing, for example, the running cost of each and every vehicle is enormously laborious, and not all players who play that particular pakset might want to use the larger scale; their computers might not be capable of such large maps. In relation to the vehicle and way costs, it would be very helpful to be able to divide them by a certain amount specified in simuconf.tab
, so that all of the scale settings could be set in simuconf.tab
and apply without having to recompile the pakset. I am currently working on just such a feature for the next version of Simutrans-Experimental, and would be grateful for any suggestions on how best to do it or (and in particular) whether there may be any pitfalls of this system or any easy mistakes to avoid.
I should also very much like feedback about what to do about all the instances of "km" being used in the UI. Should the term "km" remain, but the values be converted to mean actual kilometres, rather than tiles (so, the price for ways, for example, would give the price for five
tiles, rather than one tile when it quotes a "per km" price), or should the reference to "km" be expunged entirely and replaced simply with a reference to "tiles"? Edit
: Also, ought the divider necessarily be the same as the journey time multiplier (by default, 20%), or ought it be possible to set it to some other figure? Technical issues
Larger maps take longer to generate and consume more memory. Running in a debugger, 2048x4096 map in Pak128.Britain without any transport network, but with 512 towns and 256 industry chains took just over 400Mb, although a release build should take much less. Older computers cannot readily cope, which is why the larger scale needs to be optional, as discussed above. However, even on a relatively powerful computer (my 3.0Ghz Pentium IV is a little old now, but it does have 2Gb of dual channel RAM), map generation of larger sized maps with many cities (and, to get a sensible city distribution, it is necessary to increase greatly the number of cities when the map size is increased) can take an unreasonable amount of time (well over ten minutes, albeit with a debug build - I ran it overnight). That topic is discussed in more detail in this
thread, and I should be grateful for any further suggestions as to how map generation times might be optimised.
Further, as discussed in this
thread, automatically generated larger maps do not give a plausible terrain because of the settings. In that thread, VS intimated that he had found good settings for larger maps, but that they did not work for smaller maps. The easy solution would be to use different settings depending on the desired map size, but I do not know what settings VS had found that worked for the larger maps. If anyone can assist with that topic, I should be very grateful indeed.
One possible workaround is to use height maps, although the difficulty there is the relative lack of variety. A good range of height maps can be downloaded here
, but none have a largest dimension of much over 1280 tiles. One thing that would be very helpful, therefore, is a set of higher resolution height maps, of both real and fictional locations.
Finally, the performance of such a large map under game conditions is somewhat uncertain. In earlier versions of Simutrans-Experimental, the path searching algorithm would have been excessively slow on a large and complicated map and would have made playing unpleasant, with frequent pauses every month. Knightly's optimised centralised system has largely abated this, but other issues remain. Trees, for example, are a big drag on performance, and this gets worse the larger the map. I do not know whether any optimisations are possible with respect to trees (which I find a problem even on smaller maps), but, in the meantime, the solution is probably to edit forestrules.tab
to reduce tree density. Running a debug build on the 2048x4096 map, with Firefox and the debugger running in the background, made the game somewhat unresponsive, although this was largely intermittent.
I should be very grateful for any input on any other performance issues that might affect reasonably modern but not necessarily cutting edge hardware running maps of the sizes that I describe, and possible solutions or workarounds to those issues. I am very keen, if at all possible, to make Simutrans playable in a larger scale, and will be extremely appreciative of any input, either on the techincal or game-play aspects.