Author
Topic: balancing the pakset (Read 21755 times)

so I took the liberty! of playing a bit with the dat files. I'm mostly working on trams now - trying to get them profitable, earlier in the 19th century (horse cars), and also the electric cars. I've reduced track costs to 4/km now, horsecars to 25 horse/75 wagon (wagon increased to 55 capacity and limited to one wagon per convoy, as horses can't take much more than that). Also the late trams, e.g. TB24 lowered to 50/31, etc.

Also modified factories to spread them out a bit more, over the years.

My fear is that I'm balancing the game to my favor (so what I think is a reasonable line/combination of lines should make moderate profit taking infra into account), but since I'm not an experienced or very talented player, this may become too easy for other players, which is a concern since I want to play this pak online. For the trams, so far I've found them to be way too expensive at any stage of the game.

I'd love to hear any thoughts, advice or guidance, also if it's of any value I can post the files here when I'm finished.

There are a couple of topics in this forum that talk of specific balancing issues: check out jk271's comments in the 0.4 release thread. Beyond this, I have little experience of balancing paksets. One approach would be to take a look at pak128.Britain-ex and the balancing issues that have arisen there. The same issues will likely be important here too.

I think it's best to play it online and make notes of which vehicles make excessive or not enough income. Trying to aim for a margin of around 15~25% should be good, I think.

It's probably best if you try figuring out what would be too high or too low first. Then you can hone the figures in.And don't forget you can always add more items if you find that there's not enough variety in infrastructure or vehicles.

I think train tracks could use one more increment between 50km/h and 120km/h. Maybe 80km/h?

the current default setting is (4-1600km) for min/max distance for speedbonus. This, I think, will work on huge maps, but on standard or large size (100-400km² length) it's way too much, and thus speed bonus is hardly felt when comparing trains, while comfort plays a more major (perhaps too major) part. I would think that speed and comfort should play at least an equal part in pricing, if not more for speed.

I don't feel I have a very good understanding on the works of speed bonus yet, so I'd like to hear your thoughts on what should be the default values here, assuming a player likes to play on a map of about 400km length, or for reference purposes, when comparing trains to balance pak.

so my research goes deeper into the revenue system. In all my inquiries so far of historical and current data (one of particular interest is http://www.airlines.org/Documents/economicreports/1971.pdf p. 42), I have found that the very high rate of speed bonus in simutrans in general is not realistic (and also on the side I've found that airlines have never been a very profitable industry). So I plan on reducing that drastically in the works of balancing the pakset.

I guess speed bonus is too much of an important aspect of the game to simply forgo, so I wouldn't reduce it to a meager effect, but currently speed bonus (for 100 speed bonus, that is, double the expected speed for the era), in default settings can be up to 5 times the base fare, which is quite extreme. What do you think?

Of course, other ways will have to be found to balance things out and provide incentives for fast and reliable service, but such way already exist to a very good extent in experimental, mainly the journey time tolerance, but also time/space/engineering constraints when carrying large volumes of passengers, and even comfort rating. Also, maintenance levels will probably have to be fitted to this change. Other than that, I don't see any simulation-wise or game-fun-wise reason that air travel should pay 3-4 times more than train or bus in experimental.

That is interesting, especially as to the speed bonus. May I ask - where in the document did you get the figures on which you base the conclusion that 6% is the best speed bonus? Some brief research that I undertook into comparative pricing between rail and coaches between London and Oxford in a transport economics text book showed the existing figure of 18% to be about right (one might say that the comfort is different, but I suspect, and I should add the caveat that comfort is an inherently subjective thing, that the coaches running from London to Oxford are very comfortable for coaches, whereas I know that the trains are often not the most comfortable types (often outer suburban 3+2 seater diesel multiple units), so the actual comfort of the two is probably broadly comparable).

james - I made some comparisons on a larger scale between flight prices (now and back then) and rail and coach prices, and found that today, in various regions of the world, rail and plane prices are not very different, and in some places like Europe, flying is much cheaper actually. Even in India, a plane ticket from New Delhi to Goa will not cost more than double the train fare, I have found. So on a bigger scale of transportation, speed (given the extremity of flight speed) just doesn't seem to be rewarded so much, not now and not in the past. On the other hand, trains indeed more expensive to ride than buses, which is something I haven't investigated, but as you can see in the table, it's not by much.

The other thing is that from many many different test scenarios I've played in pak64 (and according to goods list, in pak128 as well), I can say that a speed bonus rating of 18% or 15% gives well over that figure in percentage from the base revenue - more like 500% from what I've seen. So with speed bonus rating 6% I'm currently testing, I can get the bonus to be 50% on a 91km trip at a 100 speed bonus value. This still is too much I think, if you take into account a 400 km journey will get over 100% speed bonus, so I'm trying to figure out another way to reduce this percentage, perhaps playing with the median/max speed bonus distance factors.

Interesting indeed. Hmm - perhaps the single set of figures that I took was anomalous. Can you give the figures and specific sources for your comparisons so that we can compare the raw data and computational methods?

Perhaps the answer lies in adjusting the min_bonus_max distance (etc.) values as you are looking into. In Pak128.Britain-Ex, the values are:

Interesting indeed. Hmm - perhaps the single set of figures that I took was anomalous. Can you give the figures and specific sources for your comparisons so that we can compare the raw data and computational methods?

Not sure I understand the question about computational methods? I looked into rail and flight tickets in Europe (Paris to Rome - 70-120GBP on train second class @ http://www.raileurope.co.uk, and on plane you can find Ryanair tickets from 15€),

the last one doesn't have any effect that I can account for. Before, I was trying to increase these distances, but now I think maybe low values (shorter than the map) are the way to go, but still, given the immense revenue bonus I get from even just 6%, I don't see how this is viable with 18% speed bonus rating. Trying these values, I get in the goods list 5$ pax rev in speed bonus 0, and 49$ (almost 1000%) with speed bonus 100.

Maybe I'm missing something?

The last setting I was trying on pak64 was 16/434/868, and then just before I went out I tried some 1736/868/1, but got some strange results there... Anyway I thought that increasing mid/max distance would reduce bonus for normal distance, but you're saying it's the other way?

The values are the defaults from the simuconf.tab file of Pak128.Britain-Ex, not Pak128 (which is a different pakset). To get a full idea of the function of this part of the code, have a look at the comments in simuconf.tab:

# These settings calibrate the speed bonus. Note that, with Simutrans-Experimental, unlike# Simutrans-Standard, the speed bonus is based on the convoy or line's *average* speed, not# the convoy's maximum speed. ## All distances in these settings are measured in kilometres and calibrated using the# meters_per_tile setting.## min_bonus_max_distance is the distance below which the speed bonus (or penalty) does not# apply. Below this distance, goods pay the same no matter what the average speed.## median_bonus_distance is the distance at which 100% of the speed bonus/penalty applies. # At anything between min_bonus_max_distance and median_bonus_distance, a scaled proportion# of the speed bonus applies. For example, if the min_bonus_max_distance was 10, and the # median_bonus_distance was 110, then, for a journey of 50 tiles, 50% of the speed bonus or# penalty would apply. median_bonus_distance is optional: if it is not specified, or set to# 0, it will be calculated as the mid point between min_bonus_max_distance and# max_bonus_min_distance.## max_bonus_min_distance is the distance above which the rate of the speed bonus increases# no further. In other words, the rate of the speed bonus (or penalty) keeps increasing with# the distance, until it reaches the max_bonus_min_distance, after which it remains steady.## max_bonus_multiplier_percent is the percentage of the speed bonus that applies at or above# the distance specified in max_bonus_min_distance. So, if the speed bonus rating was 10%, the# distance exceeded the max_bonus_min_distance value, and the max_bonus_multiplier_percent was# set to 200, the speed bonus rating would effectively be 20% for that journey.# Between the median_bonus_distance and the max_bonus_min_distance, a scaled proportion applies.# So, if, for example, the median_bonus_distance was 100, the max_bonus_min_distance was 1,100# the actual distance 500, and the max_bonus_multiplier_percent 200, the speed bonus rating# would be increased by half of the multiplier, or 150%.

Ahh - these were taken from the latest on the Github repository, the forthcoming 0.9.0, which might explain why they differ from the values on 0.8.4. Perhaps you could try with those values and see whether it works any better?

Hmm, I think that this is working as intended. (The figures, incidentally, are different in 0.8.3 to 0.9.0, but that is another matter). The max_bonus_min_distance is 250km, so the effect of the speed bonus continues to increase until the journey gets to 250km, at which point the effect reaches its zenith and remains there for any longer journey.

At its maximum effect, the speed bonus is multiplied by max_bonus_multiplier_percent. So, for a speed bonus of 18%, for journeys at and over 250km, this is multiplied by 300% (in other words, multiplied by 3) to get an effective speed bonus rating of 54%. At median_bonus_distance, the speed bonus rating works at its default value 0f 75. At below min_bonus_max_distance (in this case, 4km), no speed bonus applies at all. For journeys of 4km or less, in other words, passenger revenues are not affected by speed. At points between those three set points, the level of the speed bonus is scaled in a linear fashion. So, for example, half-way between the median_bonus_distance of 75km and the max_bonus_min_distance of 250km, being 162.5km, the speed bonus (18%) is multiplied by half the max_bonus_multiplier_percent (being 150%, or 1.5), to get an effective speed bonus rating for that distance of 27%.

So why do I get, in a situation like the screenshot I uploaded, almost 1000% speed bonus? If I change the '100' value in speed bonus there to '0' (base revenue, if I got it right), it will become 5$, instead of 48$...

For this calculation I would expect: base rev 5$. at 100km distance (25km more than the median 75, which is 16% from the difference between 75 and 250), I should get base_rev (5) + bonus (5 * 0.16 * 3) = 7.4 (or slightly more as makes no matter), and not 48...?

Hmm, this is very odd - I can't reproduce your base figures. With 0.8.4 and 10.18, I get 23.95c with distance of 100, comfort of 75, catering level of 1 and speedbonus of 100. Have you made any changes?

But in any event, the speed bonus calculation. In 1825 in Pak128.Britain-Ex 0.8.4, a distance of 100 gives an effective speed bonus rating of 21%. The base fare for that distance is 48.74c. However, a 100km journey at 20km/h takes 299 minutes. For a 299 minute journey, a comfort rating of no less than 189 is tolerable, and so a substantial discomfort penalty is applied.

At a speed bonus of 0, and a speed of 10km/h, the journey takes 599 minutes. The minimum tolerable comfort for a journey of that duration is 225. An enormous discomfort penalty is applied for making passengers spend nearly 10 hours in conditions equivalent to a commuter train from the 19th century.

The effects that you are seeing are due to comfort, not due to the speed bonus, I think.

thank you for your patience james - sorry for being difficult on this issue.

I tried now with 255 comfort rating, in the year 2012, also I changed 'max discomfort penalty' to 0 & 0 in the pre-game settings, and still, for:distance 75, comfort 255, catering 1, I get 13.63$ with speedbonus value 0, and 85.67$ on speedbonus value 100%.

Playing with comfort level seems to have little effect.

Also in 1825 without reducing max_discomfort_penalty, and setting distance 100, comfort 225, catering 1, I get 16.95$ on 0 and 132.25$ on 100. No matter what comfort I set 1-255, I still get a 700-1100% increase in fare, between 0<>100 speeds.

Hmm. There does seem to be something of an oddity with this: the issue seems to be around the calculation of the fare when the speed bonus is at zero. I am afraid that I don't have time to look into it fully at present, as I need to wrap my Christmas presents before I go to visit my parents, but, for reference, here is the chunk of code that calculates the revenue (this is the part that calculates it for display in the list of goods window - the code is duplicated, with some alterations, for use in calculating the revenue for actual function in the game):

So, suppose that the base fare is 100. If the speed bonus speed is, say, 15km/h, and the convoy actually travels at 15km/h, the percentage deviation from the speed bonus is 0. 0 multiplied by 18 is zero, so we end up with 100,000 (being 100 * 1,000), to which we add 1,500 (101,500) and then divide by 3,000 to get 33. (This division of fares by a third is historical from Standard and I am not quite sure the reason for it).

Alternatively, suppose that the base fare is 100, but now the convoy travels at 30km/h. The percentage deviation from the speed bonus is now +100%. The formula then works out as follows: 100 multiplied by 18 is 1,800, to which we add the 1,000 to get 2,800 then multiply by the base fare of 100 to get 280,000. We then add the 1,500 and divide the whole thing by 3,000 to get 93.

In Experimental, we add comfort and catering (but after the speed bonus calculation), and we also vary the speed bonus rating depending on the distance, but the basic calculation of the bonus itself is the same.

Does this make sense now? The reason that I was initially confused is that I had forgotten that the fares were divided by three.

It still doesn't match the numbers I got, even when I seemingly neutralized comfort effects (I bet I didn't really though).

And anyway, even in Simutrans standard, the final result of SB deviation 100 still gives a bonus twofold greater than the base fare, and in experimental (with the 0.8.4 settings) a great deal more than that. Would you agree that in any case, this is way too much, so either fixing the code, or greatly reducing SB rating is called for?

I've also noticed in my tests that using the old default settings at least (where max/median SB distances are set 1000/1600, multiplier 300), this is much more sensible - if comfort is 255, at 100km journey, the <+100> fare shows to be only 27% greater than the <0> fare. Still a bit too much but much more sensible. However in 200km journey, this grows to 69%.

I don't understand, I have to say, why you are getting different figures to me - we are using the same pakset and the same executable (you are using 10.18?). Can you run again with a clean install of the pakset to see whether you have any rogue entries in simuconf.tab?

When you refer to "fixing the code" what do you mean exactly here? It is working as intended; do you mean that the system for calculating the speed bonus needs to be changed? If so, to what do you suggest that it be changed?

As to the distances for the speed bonus, the best solution might indeed be substantially to increase these so that the maximum speed bonus is only achievable at much longer distances. Do you have any particular figures in mind for this?

So these are the numbers I get. If these numbers are correct, and if the game indeed behaves like this, the final result seems to be that a journey that's twice as fast will gain almost tenfold the revenue. Even in the numbers you've given, there seems to be a very large increase in revenue, much more than 18% (93$=33$*2.81).

So if this is the case (and I must say I've never really witnessed this distinctively in real play, only in testing), then something is wrong I think - the revenue increase should not be so great. Should it? So the system should somehow be changed to reduce it, either by working the code if necessary (not sure how), or fixing the variables to get the desired effect (sb distance/rating). This is to my understanding.

Again I have to say, in the game itself, especially in BW, I've noticed no such problem that requires fixing... but that doesn't necessarily mean it's not there.

Hmm. I am trying this from a different computer where I am staying at my parents' house, which runs Linux. The 16/300/1000 values, which are the default for 0.8.4, give the figures that I had reported previously. The numbers that you gave give 107.10c just as you have it, so we seem at least to be able to reproduce the figures consistently now.

Quote

So these are the numbers I get. If these numbers are correct, and if the game indeed behaves like this, the final result seems to be that a journey that's twice as fast will gain almost tenfold the revenue. Even in the numbers you've given, there seems to be a very large increase in revenue, much more than 18% (93$=33$*2.81).

So if this is the case (and I must say I've never really witnessed this distinctively in real play, only in testing), then something is wrong I think - the revenue increase should not be so great. Should it? So the system should somehow be changed to reduce it, either by working the code if necessary (not sure how), or fixing the variables to get the desired effect (sb distance/rating). This is to my understanding.

Again I have to say, in the game itself, especially in BW, I've noticed no such problem that requires fixing... but that doesn't necessarily mean it's not there.

I don't think that the speed bonus rating figure was ever intended to be a percentage by which the fare increases if the speed reaches a particular amount: the basic formula is the same as in Standard, and is set out in my earlier post as below. It should be noted that, until about 2007, I think, the speed bonus speed was based on either the fastest speed actually obtained by a convoy of that way type (note the speed records that are still mentioned in Standard) or the average of the maximum speeds of all of the various vehicles available for that waytype at the relevant time. This was changed to a .tab file based system when somebody made a Concorde vehicle for pak64 which was excessively profitable.

What ought the differentials in the fares be, do you think, for speed? Might a solution be simply to add another parameter capping the effect of the speed bonus at x % of the base fare?

I would think so. End-users often don't really mind formulas and how stuff works exactly - all we see is the end result, which it seems here, is that a faster convoy = much more money. Also, although I'm not a native English speaker, my intuitive interpretation about "18% speed bonus rating for pax" was that a faster convoy would get (at a certain proportion of base speed) 18% bonus to the fare. It seems that this is not the case, though I'm still not really getting what is the case - what is exactly the effect that speedbonus has/should have, if not a percentage by which the fare increases if the speed reaches a particular amuont?.

So I think some measure should be taken to counter this - the one you suggest sounds good enough Question is, what will be the cap? Perhaps we should take this to the EXP Discussion forum? My own opinion is that maybe 18% will suffice, but I can't really determine without trying