News:

Congratulations!
 You've won the News Item Lottery! Your prize? Reading this news item! :)

Space, time and money

Started by MCollett, April 22, 2013, 02:17:22 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

MCollett

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, i.e.
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:

  • Animation scale for depiction of vehicle movement. Ideally, t1 = T * t0, where T is the user-changeable game speed, and t0 is the real elapsed time, but whether this is even approximately true depends on pak settings, since as far as I can tell the program has no explicit knowledge of this scale.
  • Physics scale for underlying simulation of vehicle movement; t2 = D * t1 .
  • Production scale for daily generation of passengers and goods; t3 = P * t2 = P * D * t1, where
    P = real_day_length/simulated_(physics)_day_length .
  • Historical scale for monthly accounting, town and industry growth and technological progress; t4 = M * t3, where
    M = real_days_per_month/simulated_(production)_days_per_month .
    Currently the denominator is always 1 in both Standard and Experimental, giving M = 30.
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 for goods.

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.

jamespetts

Thank you for this very interesting discussion - this is a most helpful contribution. A number of miscellaneous points. Firstly, are you aware of the discussion related to calibrating the passenger factor here? The aim is to modify the code and the relevant simuconf.tab settings so as to make the passenger production scale with what you call the "physics scale" (assuming an average of all passenger trips in the 16 busiest hours of a day, based on the average number of per person trips per year). This is intended to go with a number of other significant changes to the way in which passenger trips are generated (differentiating trips to work from other trips, different proportion of passengers going from residential to commercial/industrial buildings, etc.) to increase the overall realism of the generation of passengers. As to goods, this also needs some attention in terms of calibration, although this should be simpler in principle. The aim would be to make the production and consumption of goods also reflect real life values of time in what you call the "physics scale". Currently, I have little information as to what those values actually are - any research that you are able to offer on this would be most helpful. (Incidentally, you write as if things were already calibrated to be set as against realistic production in Standard assuming one month to be one day - is that correct? If so, I was not aware of this. May I ask - where does this come from?)

Secondly, in Pak128.Britain, at least, what you describe as the "model scale" is not internally consistent (intentionally): road vehicles are about twice the size of rail vehicles, and ships over 15m long scale in proportion to the log of that part of their length that is in excess of 15m. Buildings are also in a different scale. There is no attempt to tie any simulation parameter directly to any of these scales: they are intended for appearance and ease of use only. What is, however, tied together is the speed of vehicle movement in the game, the displayed time and the distance scale (e.g., 125m/tile).

As part of the passenger calibration exercise discussed above, the aim is to ensure that each single tile city building represents a realistic level of population density given its size (e.g., 125 m^2) and the proportion of a town that is occupied by things other than buildings (e.g., roads). This is likely to involve a greater range of levels of buildings (a skyscraper is much more than six times as dense as a bungalow), which in turn will need adjustment of the city generation code to allow non-consecutive progression of building levels.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

The Hood

Quote from: jamespetts on April 22, 2013, 11:51:00 AM

Secondly, in Pak128.Britain, at least, what you describe as the "model scale" is not internally consistent (intentionally): road vehicles are about twice the size of rail vehicles, and ships over 15m long scale in proportion to the log of that part of their length that is in excess of 15m. Buildings are also in a different scale. There is no attempt to tie any simulation parameter directly to any of these scales: they are intended for appearance and ease of use only. What is, however, tied together is the speed of vehicle movement in the game, the displayed time and the distance scale (e.g., 125m/tile).

Not true. Road and rail (should) use the same scale, set to 30m/tile. Ships do not use a log scale but, for ships longer than 15m, they are scaled to the square root of their length.

MCollett

Quote from: jamespetts on April 22, 2013, 11:51:00 AM
are you aware of the discussion related to calibrating the passenger factor here?
Presumably, since I posted in the thread.  8)

QuoteThe aim is to modify the code and the relevant simuconf.tab settings so as to make the passenger production scale with what you call the "physics scale" (assuming an average of all passenger trips in the 16 busiest hours of a day, based on the average number of per person trips per year). ... The aim would be to make the production and consumption of goods also reflect real life values of time in what you call the "physics scale".
Done consistently, that would effectively merge the physics and production scales into one, by putting production on an hourly instead of daily basis. That would neatly remove the need for the scaling factor I called R in my opening post.  The relative speeds of physics and historical timescales would then be determined by the ratio of the number of (working) hours in a real month to that in a simulated day/month.

QuoteIncidentally, you write as if things were already calibrated to be set as against realistic production in Standard assuming one month to be one day - is that correct?
This would be pakset dependent, and as I said at the start of the post, I was considering what a realistic balance requires, not what any particular set actually does.  pak64 in Standard is doubtless a more carefully balanced game than any pakset has yet achieved in Experimental, but I don't think that there is any real-world basis for the production rates it uses.

Quote
Secondly, in Pak128.Britain, at least, what you describe as the "model scale" is not internally consistent ... There is no attempt to tie any simulation parameter directly to any of these scales: they are intended for appearance and ease of use only.
I recognise that none of the simulation parameters depend explicitly on the model scale (or the associated animation timescale), but that doesn't mean it is purely a matter of appearance.  The length of convoys is fixed in the model scale, and this in turn determines the length of platform required to accommodate them and also (at least for longer convoys) influences the traffic density at which significant congestion sets in.

QuoteAs part of the passenger calibration exercise discussed above, the aim is to ensure that each single tile city building represents a realistic level of population density given its size (e.g., 125 m^2) and the proportion of a town that is occupied by things other than buildings (e.g., roads).
The overscale width of roads and railways (even at model scale, let alone world scale) is a nuisance here of course, even allowing for the assumption that minor streets are not depicted. 

Anyway, thanks for the positive discussion.

jamespetts

A very useful discussion indeed - stickied as a resource for pakset maintainers.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.