[patch] Customization: Balance payments ("logarithmic" More money for short distances, less for long distance)

[EarthlingKira]

When playing OpenTTD (I play it on as hard as possible, maximum inflation / loan interest / maintenance cost, activated infrastructure maintenance and 16x base costs for some stuff) it always annoyed me that short trips are loosing money. Literally loosing money, and this is already the case without much infrastructure maintenance.

Later on it's even worse and most trips with less than 20 tiles are absolutely loosing money, and I hate that you are always incentivized to build the stations as far apart as possible (shouldn't you rather try to have them closer together?)

Finally I despise that are even incentivized to not deliver your cargo to the closest industry but you rather want to transport it to the other side of the map to make much money.


With this patch it's balanced, short paths (even 3 or 4 tiles apart!) are finally worth it and nearly always make money (yes, you can do a small city bus line and earn good profits) while transporting your cargo further away is penalized.

I have 3 versions, with differing penalties for long distances

small penalty: bonus until 75 manhattan distance, and then the profits grow only 2 / 3 compared to vanilla

medium penalty: bonus until 50 manhattan distance, and then the profits grow only 1 / 2 compared to vanilla

big penalty: bonus until 37 manhattan distance, and then the profits grow only 1 / 3 compared to vanilla


And in all 3 versions: the first 4 tiles give 5 times the payment, the following 5 tiles give double payment, the following 20 tiles give 0.75 times the payments and starting from tile 30 the aforementioned penalty kicks in (and the total payment hits break-even on the mentioned distances 75, 50 and 37) => This means the bonus for distances below 30 is always the same


rgds,
Kira

[Alberth]

A problem with each of your fix patches is that they only address your ideas of how it should be. Unfortunately, you are not the only player.

Obviously, you can add a zillion option settings to tune everything to whatever one desires, but perhaps it's more useful to open up these calculations to NewGRF or game scripts? (I'd prefer the latter, as scripts can have a better idea of the entire game.)

You don't want to run the actual payments through newgrf or the scripts, but they should be able to set some policy (or set some parameters or so) as to how to compute the value.

That way, everybody can have his/her favorite way of payment, etc.


EDIT: Note that backwards compatibility is required here, just changing a computation is going to break all existing savegames, which should not happen.

[EarthlingKira]

A problem with each of your fix patches is that they only address your ideas of how it should be. Unfortunately, you are not the only player.

You are right, I just decided to publish my personal patches with which I played OpenTTD in the last years

perhaps it's more useful to open up these calculations to NewGRF or game scripts? (I'd prefer the latter, as scripts can have a better idea of the entire game.)

It is actually possible to change the payments in a NewGRF (I've seen 2 NewGRFs which do this), but that just seems to be a fixed calculation in there.

Regarding game scripts: Isn't it only possible to run only one game script at the same time? At least it seemed like you could only run a single game script at the same time

Obviously, you can add a zillion option settings to tune everything to whatever one desires,

Well, adding settings with parameters for my patches is easy, I could do that. Why are NewGRFs preferred to settings? Or well, like you said, game scripts, but AFAIK you can only run a single game script at the same time

You don't want to run the actual payments through newgrf or the scripts, but they should be able to set some policy (or set some parameters or so) as to how to compute the value.

That sounds like a good idea (although I don't understand yet why these policy and parameters would be worse as setting options)




rgds,
Kira

[Alberth]

You don't want to run the actual payments through newgrf or the scripts, but they should be able to set some policy (or set some parameters or so) as to how to compute the value.

That sounds like a good idea (although I don't understand yet why these policy and parameters would be worse as setting options)

Settings would work if you make them static, ie the entire game you have the same payment strategy. At least I wouldn't expect many users to change the settings during the game.

NewGRF and script however have CPU time, and they can monitor what happens (to some extent). They can dynamically change the pricing based on what they observe. That's an entire new dimension of game play opening up. Obviously, this can be further extended in several directions.

You are however correct in the fact that few users can program a script, which would mean the settings would not be available for many users. I am not sure how to deal with that problem, and open for suggestions.

[ic111]

Settings would work if you make them static, ie the entire game you have the same payment strategy. At least I wouldn't expect many users to change the settings during the game.

Hm, I personally probably wouldn't use exactly the patch suggested here, but yes, in a single player game changing the pricing (or at least a scaling parameter influencing it) in-game sounds senseful to me --- just because the parameters chosen are no exact science, and you always are somewhere in the range between "I go bankrupt" and "I am overflooded with money" - and this is not necessarily related with the question wether you play good or bad (whatever this means).

For example, on a somewhat bigger map, you can have well-used long-distance trains, and loose money nevertheless, just because the pricing algorithm makes the people pay you hardly anything for this. But: Is a distance of one, two, six or twenty months "long-distance" in game-sense?
The answer is, you can't decide that question, just because there is no clear concept of distances related to real world in OpenTTD.

So: When I identify such a problem, changing the concept of "what is a long distance" by adjusting one single numeric parameter sounds much more senseful to me than throwing away a game that I built up in a lot of real-world-time.

(and this, IMHO, is a disadvantage of NewGrfs here --- because you can't change the NewGrfs in-game, whereas some scaling parameter conceptionally of course can be changed safely in-game)

NewGRF and script however have CPU time, and they can monitor what happens (to some extent). They can dynamically change the pricing based on what they observe. That's an entire new dimension of game play opening up. Obviously, this can be further extended in several directions.

Honestly, sometimes in OpenTTD I would be glad to be able to customize conceptionally much simpler things ("how many passengers are produced per month?") in an easy way.

NewGrfs and scripts are nice, but sometimes as I player I just want to be able to disagree with respect to some scaling decision of a NewGRF author; in a sense like "do what you do, but multiply / divide it with a factor X".

You are however correct in the fact that few users can program a script, which would mean the settings would not be available for many users. I am not sure how to deal with that problem, and open for suggestions.

IMHO the answer is that some basic scaling parameters should be managable by using settings --- just because this is the place, where everyone can tune things based on the personal taste with minimum work required. And because this is the place, where settings that only influence calculations in a non-permanent way conceptionally can be changed in single player games in-game, without having all the trouble that are involved with replacing NewGrfs in-game

For example, already the question how much cargo is produced can alter the feeling of a game completely. And for influencing that one, you don't need to introduce "a zillion of parameters", one or two already can do a lot.

Or - the motivation of this patch: Some time ago, I analyzed why my trains don't earn money once the networks is enlarged (you see, the opposite problem the thread starter had ), and I ended up at the topic of cargo aging.

Of course, the 8-bit-Integer-arithmetic used there just has its limitations (i.e., the counter cannot have values > 255), but once I modified that by some factor, the problem was gone, and I actually could serve longer distances on a 512x512 map with trains of 1915 of the SBB set.
(what I did was more or less influencing the amount of days that are equivalent to "255", if I remember correctly)

Of course, what I did probably doesn't translate into a patch 1:1, but my point is that a few (*not* a zillion) well-chosen parameter settings in that regions of the game could give you a lot of influence on how the game feels.

(actually, collecting some changes like that into a patch is something I have in mind, but (real live...) not in the near future...)

[EarthlingKira]

Some time ago, I analyzed why my trains don't earn money once the networks is enlarged (you see, the opposite problem the thread starter had ),

[...]

trains of 1915 of the SBB set

That's because they were too slow: https://wiki.openttd.org/Cargo_income#Visualization

There you can see the curve for different speeds

[ic111]

Some time ago, I analyzed why my trains don't earn money once the networks is enlarged (you see, the opposite problem the thread starter had ),

[...]

trains of 1915 of the SBB set

That's because they were too slow: https://wiki.openttd.org/Cargo_income#Visualization

There you can see the curve for different speeds

Well, yes, that's the reason. And as I wanted to play a bigger railways network with vehicles of that time (on a 512x512 map), the way things are parametrized didn't fit for my playing style, which is what I corrected in my private source code copy.

[EarthlingKira]

Well, yes, that's the reason. And as I wanted to play a bigger railways network with vehicles of that time (on a 512x512 map), the way things are parametrized didn't fit for my playing style, which is what I corrected in my private source code copy.

I understand this, and now let me offer a potential plot twist: In later game years (let's say 2020) longer cargo routes give *MUCH* *MUCH* more profit than short routes, because you lose so much money while un/-loading and accelerating. The problem is that you will even lose money with short routes (<10 tiles), probably make only a few bucks between 10 and 30 tiles but then you suddenly make MILLIONS with a single long route (>= 500 tiles). But this is only true when the trains are fast enough *later* in the game, like 2020.

So....... WHAT IF....... the original developers never intended it to be this way. They wanted long routes to be only equally profitable and so they introduced the time factor and balanced it based on the vehicles in the first decades in the game

If this was true it would mean that trains starting from 200 or 300 km/h break the introduced time factor which was meant to balance the profit of long routes...

[ic111]

I understand this, and now let me offer a potential plot twist: In later game years (let's say 2020) longer cargo routes give *MUCH* *MUCH* more profit than short routes, because you lose so much money while un/-loading and accelerating. The problem is that you will even lose money with short routes (<10 tiles), probably make only a few bucks between 10 and 30 tiles but then you suddenly make MILLIONS with a single long route (>= 500 tiles). But this is only true when the trains are fast enough *later* in the game, like 2020.

Maybe what you would need would be:
- very few passengers travel long distances (compared to the number of passengers on short distances)
- income per passenger is quite a lot higher than today

(the former as far as I remember can be parametrized using a CargoDist parameter).

Then, you should have the situation, that the passengers within your cities earn money, but the number of long-distance passengers is low enough to prevent being overflooded with money there.

If one wants to further lower the income from long-distance passengers, maybe increasing cargo aging (the opposite thing than I did) would be an option either, I mean for a distance of just 10 tiles, even when using road vehicles, cargo aging shouldn't play such an important role; I imagine that your problem is more the low absolute income from the passengers, and less the cargo aging.

So....... WHAT IF....... the original developers never intended it to be this way.

Basically, this is my point here: You cannot forecast all combinations of NewGrfs, and all playing styles people use, at different stages of a game (1915 vs. 2020).

And here, my feeling from the perspective of my single-player-games is: Often, in such situations it just would be convenient, if there would be a well chosen set of scaling parameters I can use to correct those things according to my taste.

[EarthlingKira]

Hm,

I agree with your points, players need different things and have different play styles

And here, my feeling from the perspective of my single-player-games is: Often, in such situations it just would be convenient, if there would be a well chosen set of scaling parameters I can use to correct those things according to my taste.

I'd be more than willing to implement these scaling factors as settings if I knew that my patches have a chance to be merged


rgds, Kira

[ic111]

It's not at all up to me to decide about such things, however my experience is that not too much thinking about trunk is the better approach.

Although with respect to this topic, my personal opinion is that some setting extensions should be possible without breaking things in a technical sense, the question what will happen actually with a potential patch is a quite different one.

So, maybe a scaling patch dedicated to

- patches that more or less alter or maybe introduce numeric constants
- making such parameters accessible via the settings
- not introducing complicate game logics

would be a interesting thing with respect to what I personally might use, but the chances with respect to trunk are a completely different story...

As I have said, I personally have thought about implementing a small patch queue like this as well, however, real world time constraints currently prevent me from actually doing so. What I would have included would be something like:

- factor on top of passenger / cargo generation; a division by more than four seems to be impossible due to integer arithmetic (tested in my games)
- for higher factors maybe a factor to more seldom generate cargo (just an idea, never inspected or tested)
- something about cargo aging
- factor regarding the speed, with which station ratings decrease (tested in the sense that I applied the approach for ships (slower decrease) also for trains --- this allows me to more seldom service stations that (see division of cargo generation above) generate just a few passengers)
- limit population increase (there is a working patch queue of me in the forum, which (1) introduces a global population limit, and (2) a factor by which it will be periodically adjusted; both values fully adjustable in-game)

As that list maybe suggests, the main problem with game balancing I have is that I gain too much passengers, and that long-distance passenger routes with relatively few / slow vehicles behave bad in my experience.