Here are some thoughts on scaling and balance in Simutrans paksets, mainly aimed at Experimental, but mostly also applicable to Standard. Note that I am considering what a carefully balanced pakset should
do, not what any existing set actually does.
There are two main distance scales:
- Model scale for vehicles and transport facilities; 15 m - 40 m per grid square.
- World scale for point-to-point distances; nominally (but not very convincingly) 1 km/square in Standard; a more believable 120 m - 250 m in Experimental.
Call the ratio of these two D
D = world_scale_grid_size/model_scale_grid_size .
Other buildings may be depicted at model scale, but with each representing D2
real instances, or at world scale, each representing just one instance, or at any consistent intermediate combination of scale and number.
For example, in Pak128.Britain-Ex, the model scale is 30m/square and the world scale 120m/square, so D
is 4. A single ordinary house occupying one square should represent a cluster of 16 similar houses, each 30mx30m; a small park occupying one square represents one 120mx120m park; a single square commercial or industrial building might represent 1 large one, 4 medium (60mx60m) ones, 16 small ones, or any any mixture of medium and small that covers the 120mx120m site.
There are no fewer than four distinct time scales:
Note that Standard allows the game clock to show either the production timescale (1 24-hour day per month) or the historical timescale (30 days per month); Experimental also adds the option to show the physics timescale (1 short day per month), which is particularly helpful when using fixed timetabling for lines.
Presuming that the aim is convoy frequencies comparable to those of real-world offpeak weekday daytime, the daily rates of production of passengers and goods need to be reduced from their real values by a factor
R = P*24hr_7day_average_traffic/offpeak_weekday_daytime_traffic .
This will be significantly different for passengers and goods. For goods (including mail), the great majority of trips will be during working hours, giving R~0.3*P
. For passengers, we also have to add the morning and afternoon rush hours, a small amount of evening traffic, and a moderate amount of weekend travel, giving R~0.7*P
; this is effectively equivalent to setting R=P
, and calculating P
using a operational day length of 16 or 18 hours (6am to 10pm or midnight) instead of a 24-hour day.
For example, a physics day length of a little over 3 hours (P~7.5
for a 24-hour day) gives R~5
for passengers and R~2.5
Even with this reduction, there may be significant congestion if D is too large: each convoy takes D times as much way length as in reality, so that nose-to-tail gridlock sets in at a correspondingly lower traffic density.
For economic balance, the aim is a roughly realistic rate of return on capital at the historical timescale t4
. Without the multiple time and distance scales, this could be achieved by setting all costs and incomes to something close to real-life values. To correct for the multiple game scales, some financial scaling must also be made; in particular, we must allow for the fact that each simulated trip represents R
trips per day for a month.
A simple scheme that yields an approximately correct gross cash flow per month is:-
- Use real construction and monthly operating costs for ways, transport facilities, and vehicles.
- As already discussed, reduce generation of passengers and goods by a factor R from the real daily rate.
- Increase all fares and per km operating costs by a factor R*M from the real values.
This favours the player slightly compared to the real world, in that rush-hour patronage contributes to overall income without needing the provision of extra station and vehicle capacity; a moderate reduction in passenger R
(effectively ignoring some of the rush-hour traffic) would offset this.
Unfortunately, a small problem does arise from having different values of R
. Having two different factors for generation is fine. Having two different factors for fares and costs would also be fine if all vehicle types were specialised to carry just one or the other (as most road vehicles and smaller boats are), but leads to a pricing ambiguity for those that can move either or even a mixture (e.g. railway locomotives or larger ships). For want of any better idea for the moment, the easiest workaround is to forget having a separate factor for goods, and just to use the passenger factor for everything. Again this favours the player slightly, since the same gross income will result from fewer convoys, and hence strengthens the case for using the lowest plausible value for the passenger R
. For example, for the 3-hour day illustrated earlier, a good overall compromise value would probably be around 4: this ignores most of the extra rush-hour passengers, but allows for a significant minority of goods movement to occur during evenings and weekends.