Transport Tycoon Forums

The current method of calculating cargo payment rates is widely accepted as unrealistic (why would an industry pay lots to have its raw materials brought from miles away?) and game play unbalancing (you can make billions by supplying coal to a power station from the other side of the map). I suggest a patch option for the following:

* Cargo should not have "destinations" (in the style passengers or mail would)
* Secondary industries should accept as much cargo as is delivered (like the current behaviour, no stockpiling-like or maximum acceptance feature)
* Cargo payment calculation should be the same (pay more for travelling further faster) BUT:
* Cargo payment is calculated for the distance from the nearest supplying industry, not the distance the cargo has been carried.

This is a conceptually simple solution (that I haven't seen suggested before) and combined with a passenger/mail destinations patch would make a simple to understand but effective change to the economy for sadistic/realistic players. What do people think?

I tried to make it exactly as you said - the distance is now calculated from the closest industry producing that cargo, not from the originating station. I must say it needs something more komplex reflecting real material prices fluctuation depending on...I don't know what, I hust know this is not enough.

Patch against r14030 and ready to use win32 executable with demo savegame attached.

Try it and tell me if you are interested more in this, I would make a thread in dev section.

I tried to make it exactly as you said - the distance is now calculated from the closest industry producing that cargo, not from the originating station.

Wow, thanks for the quick work! I would like to see what other people think of this too...

reflecting real material prices fluctuation depending on...I don't know what, I hust know this is not enough.

In real life
IRL the price of material depends on supply and demand and has a global effect on the cargo value, therefore the base value of the cargo should vary in value according to:

V = B * D / S

V = base value of the cargo (varying according to economy)
B = actual base value of the cargo (constant)
S = units of the cargo carried in the last month
D = demand for the cargo

D would have to be arbitrarily calculated, eg:
D = N * K

N = number of industries accepting the cargo
K = constant, approximately 200?

Alternatively
D = total industry production of the cargo in the last month

However this has no effect on the payment rate for each industry individually.

What I think you meant
Every secondary industry has an individual demand of a quantity of cargo per month which varies like a primary industry's production. Payment rate is then calculated for the current month by:

V = B * D / S

V = price for current month (varying according to economy)
B = actual base value of the cargo (constant)
S = units of the cargo delivered in the last month
D = industry demand per month

*edit* Actually, those equations cant be right because if S is zero then V becomes infinite, i'll have a think.

Two possible solutions, either:

V = B * D / (S + C)

C = an imaginary supply rate (say 10?) - the price the workers get paid for walking and getting teh cargo - which sets a maximum payment rate.

or:
Cap the value of D / S to, for example, 10.

I will have to read this once more to fully understand it. I'm only afraid this is field covered by the rebalance of economy proposed quite long ago. It seems to be stall though, I was looking at it several days ago at SVN and last update there is in half of 2007 if I recall it well.

I must say I don't feel very competent to do all this...

The stalling of the economy branch is exactly why I posted this here, it seems a simple patch setting to a similar balance to the new economy could...

CommanderZ wrote:I must say it needs something more komplex reflecting real material prices fluctuation depending on...I don't know what,

Against: TTD is a transportation game, so we have to assume the industry actually want a delivery from the other end of the map. We don't get the money for the raw materials, only for transporting them, and thus should be paid for the full distance.

Pro: As it is too easy to make money (with most settings) it's never wrong to try to do something about that.

A suggestion: If possible, let the pay be depending on the distance to the closest raw material source that actually delivers to the industry. This way I can sandbox alone and earn lots of money on a long haul, but in a multi player game the shortest haul will more or less effectively bankrupt longer lines. Maybe just use the shortest delivering distance as a damper on longer hauls? Or rather "shortest delivery time" - a very slow service close to the industry should not get paid more than a faster one from far away.

In the real world, there are the supply/demand factors that govern prices, both for raw materials and for transportation. Factoring that into TTD is quite difficult, although the ECS vectors try on the raw materials.

As for getting this involved in transportation too, you might perhaps lower the pay rates depending on how many different companies are delivering to the same industry (Example: 1 company = 100%, 2 = 70%, 3 or more = 50%).

Zephyris wrote: ...
* Cargo payment is calculated for the distance from the nearest supplying industry, not the distance the cargo has been carried.

This is a conceptually simple solution (that I haven't seen suggested before) and combined with a passenger/mail destinations patch would make a simple to understand but effective change to the economy for sadistic/realistic players. What do people think?

CommanderZ wrote: ...
I must say it needs something more komplex reflecting real material prices fluctuation depending on...I don't know what, I hust know this is not enough...

I really want to see something being done to balance the game, so this discussion is needed!
Picture the following: there are 5 coal mines on a map, and one power plant located close to one of the coal mines. It will then maybe only be profitable to tansport the coal from the closest mine, and the other 4 will be unused. A way to correct this, is to do it the other way around:
* Cargo payment is calculated for the distance from supplier to the nearest accepting industry.
There is in general more supplying than accepting industry. Think of it as the supplying industry paying the transport.

Zephyris wrote: In real life
IRL the price of material depends on supply and demand and has a global effect on the cargo value, therefore the base value of the cargo should vary in value according to:

V = B * D / S

I am not an economist, but I think computing prices using a simple formula will be too simple no matter how advanced the formula is. Besides, what is interesting here, is the transport price, not the actual value of what is transported. When there is only one company transporting some goods, this company will usually take a very high price. If there are more companies, the most realistic way would be to make the companies decide the price themselves, and then calculate the station ratings based on the price (over time). There should, IMO, be a maximum price, and the companies can then adjust the price simply by multiplying with a percentage, in order to keep track of prices more easily. This is not an easy solution though

* Cargo payment is calculated for the distance from supplier to the nearest accepting industry.

Sounds interesting, I will do it tomorrow. I guess making it is far simplier than evaluating it

I am not an economist, but I think computing prices using a simple formula will be too simple no matter how advanced the formula is.

It will never be perfect, but you can do a surprisingly good job with a simple formula!

* Cargo payment is calculated for the distance from supplier to the nearest accepting industry.

Very good point, I like it

If possible, let the pay be depending on the distance to the closest raw material source that actually delivers to the industry. This way I can sandbox alone and earn lots of money on a long haul, but in a multi player game the shortest haul will more or less effectively bankrupt longer lines. Maybe just use the shortest delivering distance as a damper on longer hauls? Or rather "shortest delivery time" - a very slow service close to the industry should not get paid more than a faster one from far away.

This is why it would be a patch setting, this should definitely not be "standard", if you want sandbox then just turn it off! What do you think of it as an idea to make the game harder and more "realistic"?

AndersI wrote: [Against: TTD is a transportation game, so we have to assume the industry actually want a delivery from the other end of the map. We don't get the money for the raw materials, only for transporting them, and thus should be paid for the full distance.

I found some statistics suggesting that commodity prices and transport prices are correlating, so the basic idea of Zephris isn't so wrong.

http://voteview.ucsd.edu/rtopic7.htm

I believe it's difficult to calculate the costs of railroad transportation and it's easier to calculate freight costs for trucks.
The main costs are fuel and wage for the driver (so both are dependent on distance) .
A truck doesn't really costs money as long as he doesn't move (same for a train, but theoretically there are so many other costs for example the infrastructure)

A commodity can be transported for longer distances to a lesser extent due to cheaper transportation costs, but rather because of cheaper production (more productive industries or lower wages) and high endprices at the destination.

Storage is important, so vehicles could wait if the storage is full or empty. In reality especially many agricultural rawmaterials are seasonal, so in general it's mostly not possible to operate vehicles always at full capacity.
What about a commodity futures exchange for raw materials to define prices?

* Cargo payment is calculated for the distance from supplier to the nearest accepting industry.

Done, attached the new demo. It is calculated as dist from originating station (CargoPacket doesn't include the orig. industry, this could be added, but it would require some more work) to closest cargo accepting industry.

I didn't test it much, so guess it might have problems with Transfer order and I'm pretty sure it will crash when delivering cargo to city. All these problems could be of course fixed if I was sure there is interest in this.


The principle is not perfect too. See the demo game, I constructed several routes from mines all over the map to one Power Plant. Then I built a new power plant just near one of the mine and the train's income immediately sinked to 1/4. Not very fair.

I guess we are misplacing the transportation service cost with the cost of the cargo. The transporting service will IMO get paid for the travel distance no matter what (if it delivers the cargo, of course). Maybe it is okay as it is in the OTTD now, the distance factor just should be somewhat less important...

I will post the patch on request.

Zephyris wrote:This is why it would be a patch setting, this should definitely not be "standard", if you want sandbox then just turn it off! What do you think of it as an idea to make the game harder and more "realistic"?

I think you didn't read my post well enough - I'm not against this suggestion per se, as I wrote in my previous post:

Pro: As it is too easy to make money (with most settings) it's never wrong to try to do something about that.

I was just suggesting that the game is actually about transportation, which means that the fact that there is a coal mine nearby shouldn't have any influence if no-one is transporting that coal.

I did suggest that the lower pay rates should consider the distance to the closest raw material supplier that actually delivers to the industry, which means that I could play whichever way I liked when sandboxing, without having to flip a switch.

In general, whichever method you chose to limit the profit, you should only consider resources actually involved in transportation. A coal mine which is not in the catchment area of any station should not have any influence on my profits. Only when someone starts to pick up coal there should it enter the formulas (or even better: not until coal from mine X has been delivered to the industry).

Thing is that they industries are paying you to transport the cargo, not actually for the cargo. Realistically the secondary industries will set up contracts with whoever (for them) would provide the cheapest product. We could implement contracts a little like subsidies. E.g. Fluntfingfield Power Station requires coal to be transported from Sentfingway Coal Mine.
This would be closer to real life. As the UK imports coal etc even though we have mines in the UK. It could be hard to implement though.

T-Unit wrote:It could be hard to implement though.

And hard to play. Gameplay wise that'd probably make passenger transport more attractive, unless cargo transport pays big money.

I guess we are misplacing the transportation service cost with the cost of the cargo. The transporting service will IMO get paid for the travel distance no matter what (if it delivers the cargo, of course). Maybe it is okay as it is in the OTTD now, the distance factor just should be somewhat less important...

What about a cargo delivery price based on:

=( Base Value * 1 / ( Perishibility * ( 2 * Pi )^0.5 ) ) * (e ^ (-( ( Distance ^ 2) / ( 2 * Perishibility ^ 2 ) ) ) * ln( Perishibility )

I'm sure this equation could be simplified massively, but the principle may work, see attached for a graph.

That's quite complex. Also, your table puzzles me. is distance supposed to be along the columns (i.e. to the right is longer distances) and time 'down'? Because that's the way that formula seems to work, even though the values it produces are backwards to that interpretation (more profit from delivering later and less from distance).

=( Base Value * 1 / ( Perishibility * ( 2 * Pi )^0.5 ) ) * (e ^ (-( ( Distance ^ 2) / ( 2 * Perishibility ^ 2 ) ) ) * ln( Perishibility )

I note also that the highlighted part is different in the spreadsheet. This is a ln (time) not ln(Perishability).
Which, i confess, makes more sense. However, it results in the price increasing with time, a behaviour i suspect was not intentional. Did you intend to divide by ln(time) instead?

Edit:

Further investigation has revealed why this formula is a bit broken (sorry!), and the source of my confusion with the table. By having e^(-Distance^2), you actually have a coefficient that decreases with distance rather than increasing. What i suspect you intended was e^(-1/Distance^2), which gives an increase with distance that has a 'roof' set by the coefficients of the power of the exponential. Distance probably doesn't need to be squared in this, either, as this results in a very quick approach to the 'roof'.

TBH I designed that a long time ago and cant quite remember the components of the equation, although the principles are:

Old: Payment rate is proportional to distance travelled
New: Payment rate is proportional to the natural log of the distance traveled
This reflects real life - you would pay £1 to travel a mile, but not £1000 to travel 1000 miles (london to scotland) or £10000 to travel 10000 miles (australia!?). ln is probably too harsh a drop off, but exagerates the idea. An extra constant is needed.

Old: Payment rate is related to time in transit by a curve
New: Almost the same, just exagerating and improving the curve.
IRL you dont mind if your coal has been in transit for a month, but you would mind if your mother in law was in transit for that long! This equation uses the positive half of a normal distribution curve for calculating payment depending on time in transit.

The combined effect of these would be to reduce the payment for long distance travel (no easy billions) whilst still requiring the use of express transport for perishible cargoes (passengers, food, etc.). The more I think about the economy the more I can see that can be improved simply! I think I will design a modular set of improvements for perusal, watch this space!

If you think your formula is worth coding, I will give it a try at the evening.

Just what exactly is "perishibility"? I couldn't find it in dictionary.

Also, I believe the formula could use some simplifications. I will try to put it into Mathematica if it would be able to do something with it.

I made up perishibility It means a measure of how perishible an item is - food goes rotten but you can leave iron ore in the back of a truck for years and it is still fine.

I am sure the equation can be simplified a lot, and may have to be for performance. An obvious change is:
e^x ---> 2^x (changing a floating point calc to a byte shift)
But any changes to simply the equation would be good.

Remember that at least 3 tweakable constants will be needed; one for overall pay scaling, one to balance pay with distance carried and one to balance pay with time in transit. Ideally these could be set via the patch menu/command line to allow playtesting and tweaking.