A question of economics.

[Jullietta]

I actually don't mind this a bit. What is a bit out of whack, though, is that the money you receive from a delivery is based on the distance of your stations, rather then the industry, which, on smaller routes, can easilly tripple the income.

See here: http://s10.postimage.org/slr4zttah/ttdx ... stance.jpg

Do you think changing this would bring other problems? Do you think this should and can be changed? Thank you

[Aphid]

Actually, there's many more of those things. I'd like to call them 'artifacts' of chris sawyer design. Which is to say random arbitrary magic numbers and nonsensical calculations for everything. When it feels good go with it. It's the way the game was made 18 years ago and we're still unfortunately stuck with much of it.

Unfortunately getting rid of this can prove quite difficult as there's all these pesky other people, also known as the entire newGRF community, that rely on chris sawyer's design, sadly. But maybe one step at a time you could do it. Here's some example other things:

1 - Profit doesn't depend on the location of the industry.
2 - Not only does profit depend on the stations, it depends on the position of the station SIGN.
E.g. compare this route
ssssS-----Sssss
to
Sssss-----ssssS.
Where s is station tile, S is the first placed station tile. (which is where the sign is). The first route is 5 tiles long, the second is 14. Go figure.

3 - Even though trains move at a speed of about 1 tiles diagonally for every 1.4 tiles straight, you get paid double for diagonal lines x tiles long and x tiles wide compared to a straight line x tiles long. You also pay 2 times as much for two diagonal pieces of track compared to 1 straight piece of track, even though 1.4 would make more sense.

4 - Trains are longer diagonally than they are straight. That might seem fine until you understand that this means longer trains with the same power to weight ratio as shorter trains will still need longer gaps between eachother if your tracks contain (long enough) diagonal sections. Which is highly counterintuitive.

5 - Profit doesn't depend on the time the cargo actually takes to reach its destination, only the time it actually spends in a vehicle. If a unit of coal sits in the departure station for a year the train isn't going to make less money off of it. But if the train carrying that piece breaks down that's a problem. Seems really off for passengers especially.

6 - Cargo can magically fly instantly from one part of a station to another, even if these are 64 tiles apart. (and in actuality, you could create a magic transfer system with just a couple road vehicles transporting huge amounts of cargo near-instantly over large distances like that). This is usually seen as an exploit, in contrast to 1-5.

7 - The order in which things are built sometimes has a huge impact on the actual cost of things, especially when water is involved.

8 - Building a station over an existing station (enlarging a train station) costs you the full cost of whatever you use to fill up the new station. E.g. suppose you have a 1-lane length 6 terminus. Replacing the whole thing with a 2-lane terminus in one click by selecting '2' and '6' and clicking will cost you twice as much as adding a single extra lane via '1' and '6'. (and look better for passenger terminus).
8a: (edit) Even worse, accidentally double clicking costs you an extra full station. That can be pretty expensive when either just starting out or playing in the 19th century.

9 - Placing a tree in a tile already containing a tree doesn't please a town at all. A town loves you for placing a tree in a tile that has no trees already. (wut?)

10 - Buying advertising campaigns works only for those stations whose SIGNS are in the range of the campaign. The actual topology and location of the brunt of the station structure is irrelevant.

11 - The same applies for exclusive rights (though this is not much of an issue as this is seen as an exploit, like 6)

12 - To get optimum town growth, a button in a submenu from a menu needs to be clicked every 10 seconds. (and you need 3 buses) Now do it for 30 towns. (hint: you need a partner....)

13 - The cargo acceptance of your HQ, important for some passenger-related or mail-related endeavors, depends on a weird arbitrary rating system.

14 - Cargo payment values tend to be optimum for distances larger than the maps themselves for default sized things. For large maps (1k/1k+) they work out better provided we stick with rail.

15 - When going at a 30-degree angle, taking long stretches of alternating diagonal and straight rail is faster for long, fast trains (say, Lev4), than it is to use short stretches of alternating diagonal and straight rail (only 2 directions are ever used).

16 - Station rating can increase even when the vehicle responsible for this will never take the cargo anywhere, or even drops it off at that same station. As long as it's a shiny new truck the coal mine's happy to give you more coal, disregarding the fact that that same truck just keeps loading and unloading and never really goes anywhere else.

17 - by default, the best method to make money on the tropic map involves planting 3862945624958712 trees.

There's probably many more. Especially number 3. is pretty influential for gameplay. Changing it would make sense for better competitive multiplayer because it's kind of impossible to build diagonal bridges over another person's diagonal track. Meaning the 'first to place wins' issue is greatly aggravated.

http://bayimg.com/CAaebAAei

A more extreme example.

Edit: The difference in profits is about 550%.

[YNM]

And at last, just remember it's just a "game" in any economic point. There's also flaws, because human are imperfect. And this is a TRANSPORTATION, NOT ECONOMIC GAME.

Anybody mind to move to Simutrans due to these silly economic facts ? They're more neat in these economic problems, through they have some problems at places where OTTD is good at. (Especially at vehicle handling)

[mfb]

12 - To get optimum town growth, a button in a submenu from a menu needs to be clicked every 10 seconds. (and you need 3 buses)

Can you explain this part?
And if the stations are close to each other, a single bus should be sufficient.

15 - When going at a 30-degree angle, taking long stretches of alternating diagonal and straight rail is faster for long, fast trains (say, Lev4), than it is to use short stretches of alternating diagonal and straight rail (only 2 directions are ever used).

Why? Assuming the sections are long enough to avoid 3 turns within a train length.

[Dave]

I'm going to say that as a Briton, we have millions of tons of coal STILL UNDER OUR LAND...

So where do we get the majority of our coal from... Well... Abroad...

Some 70% of it, in fact. (Figure is approx from 2008 as below)

https://docs.google.com/spreadsheet/ccc ... aM3c#gid=0

[Aphid]

12 - To get optimum town growth, a button in a submenu from a menu needs to be clicked every 10 seconds. (and you need 3 buses)

Can you explain this part?
And if the stations are close to each other, a single bus should be sufficient.

15 - When going at a 30-degree angle, taking long stretches of alternating diagonal and straight rail is faster for long, fast trains (say, Lev4), than it is to use short stretches of alternating diagonal and straight rail (only 2 directions are ever used).

Why? Assuming the sections are long enough to avoid 3 turns within a train length.

I can explain both parts. 12 is simple. Clicking 'fund town' resets the house timer to 1 day. Therefore, constantly clicking it gets you the highest grow rate. This becomes especially frustrating to do with more than one town, while building up. Some automation to it would be nice.

15 is also simple, what if my sections aren't long enough to avoid 3 turns?. Longer trains can easily cause that. 3-tile sections with 7-tile trains. Or even a 5-tile one followed by S-bend.

18 - When multiple industries per town is turned on, certain types of industries can flood the map and/or towns.

19 - Town growth requires 5 stations to be optimal. However, train stations that transport to that same town using a train do not count towards this total of five, yet a bus station doing the same does. (To test this out: place 4 stations and 2 trains in a town, observe growth rate is 0.). Trains transporting passengers to other towns DO count.

19 is especially bad. how in the nine hells does that make any sense?

20 - By default, building a railway and then electrifying it at some later time costs twice as much as electrifying a rail as it's built immediately. Building an electrified track doesn't cost you any more than a normal track from the ground up.

[YNM]

Eh, about No. 20 - Build an electrified track and non-electrified track from first time have different cost.

Well, you're right about electrify a track later, its more expensive for £14 compared to build a new electrified track. (Jan 2010 using OTTD 1.2.0 beta 4 + cargodist. Just to assure if theres maybe difference.)

And number 15 - Its players problem, not a dev problem. I don't think that should be removed, because its half - reality.
30 degree turns is likely unsupported, codewise or graphicwise. (the later may be done)

[mfb]

I can explain both parts. 12 is simple. Clicking 'fund town' resets the house timer to 1 day. Therefore, constantly clicking it gets you the highest grow rate. This becomes especially frustrating to do with more than one town, while building up. Some automation to it would be nice.

Interesting, I'll have to test this.

15 is also simple, what if my sections aren't long enough to avoid 3 turns?. Longer trains can easily cause that. 3-tile sections with 7-tile trains. Or even a 5-tile one followed by S-bend.

Well, I thought about tracks of 10++ tiles, longer than the trains. If you let a real train run over several 45°-curves within its length it will slow down, too . The issue is not the slowdown, it is the lack of 30°-bends. But that is part of the game...

19 - Town growth requires 5 stations to be optimal. However, train stations that transport to that same town using a train do not count towards this total of five, yet a bus station doing the same does. (To test this out: place 4 stations and 2 trains in a town, observe growth rate is 0.). Trains transporting passengers to other towns DO count.

19 is especially bad. how in the nine hells does that make any sense?

It does not make sense because it is wrong. You do not have to deliver the passengers to any destination at all - dumping them on some dummy station with transfer order is fine. However, the stations have to be close to the city center, which is easier for bus stops, especially in small towns.

[Frank327]

I'm pretty sure it's not a problem of realism, but one of balance. In some games the best strategy seems to be to have one mammoth train station on one side of the map, one on the other, and then build a train transporting coal go one way and sell the train when it has reached its destination. Short distance transport isn't unprofitable, but just not really worth it.

Then again, it depends on the settings you're using. Originally the maximum length of trains was 5 tiles, and if that would still be the case it would probably still be somewhat balanced. Also it makes a big difference if you use more infrastructure costs.

[Aphid]

Actually, I believe I once calculated optimum route lengths with a really complex math formula obtained from OTTD's train physics model. Numerical integration and all that. From what I recall, the fist-rule was about speed*1.5 to speed*3.5 depending on cargo type (km/h to tiles in both directions). For most cargo engines for the length of the track (2-way transport) in order to obtain the highest possible ROR value. (rate-of-return), which held true for most normal engines (speeds of 80-250 km/h) in this case we include the effect that having to wait until your train delivers cargo has, and assume cargo production >> cargo transported (e.g. the start of a game with high industry count).

Note: on a 512x512 map this means corner-to-corner for engine speeds >~ 140 km/h for wood cargo (including mill build costs)

For higher sustained profit the route is longer, but not that much longer. Eventual Total Profits / Investment form a weirdly-shaped curve, close to but not equal to a curve of the maximum of a parabola and an increasing line through the zero point.

So what are all the changes needed to absolve the list of inconsistent behaviour?

1: If a cargopacket kept a record of its origin tile, then it could award money based upon the actual distance required. The optimum behaviour of a player would then be to keep routes short instead of artificial elongations as done in the picture.

2: Above solution works.

3: Use the actual distance for a profit measure, NOT the manhattan distance. Floating point rounding errors are way less bad than being off by a factor 1.4. And it's not like there's a billion profit calculations per second, so performance is not significantly impacted by having to use fp numbers for the sqrt() function.

4: Highly complex to solve. Would require creating a new graphics standard in which a different carriage length for the four diagonal directions is specified. The existing graphics standard could at best coexist, and have to be blitted in a non 1-1 ratio in order to 'shorten' the images via the GPU, upon which the correct train length would be established in diagonal sections. This introduces problems due to the 'pixely' nature of the images (their small size) so visible distortions will result from the effect removing rows or columns of pixels has.

5: Could be solved by having a cargopacket keep track of its creation date' timestamp.

6: Players policing themselves still appears to me as the best solution. By the way, turning off control-click building is NOT a good solution. The problem still persists in that you're still perfectly able to exploit. However you can now no longer feasibly build many pretty legitimate configurations, such as two stations where three different modes of transport exist at, and where these three modes have one or more station tiles cojoined with the other station for each of the three modes. E.g.:

ABC
DFE

Where A is a 1x1 train station, B a bus depot, C a truck depot, same with D,E,F. A,B,C belong to one station, D,E,F the other. No tile gaps exist between the stations. You can't build it without ctrl-building!

This minimal example has little financial merit, degenerate it is. However, more complex examples exist that certainly do (have merit).

7: Hard to solve. To eliminate a large portion of the problems, clearing a diagonal-coast water tile should not cost more. This happens when crossing large bodies of water with multiple small bridges and wanting to clear a minimum of water tiles. Only those with the very fastest fingers will manage to build a bridge before the tile is re-occupied with water and the clear cost has to be paid twice. When the former is implemented, this is no longer an issue.
Building canals should not clear water tiles.

8: This doesn't sound too hard. change would be: Don't charge for replacing station elements for equivalents. It has mere visual impact.

9: Simply moving the logic about can solve this problem. E.g. putting the town effect in the function/method that handles the player action of planting trees when succesful.

10: Solving this would be a pretty tough problem. It isn't too impactful anymore if problem 1) is solved though. As there is not such a big influence of the station sign anymore.

11: This should be off in most games anyway.

12: Allow players to set up repeat actions in the town menu with a repeat tickbox and a number of days field. E.g. I enter '3' into the number of days field, click on the tickbox, then click fund town. The game will now automatically fund town for me every three days. To stop, we simply have to untick the tickbox. As the data can be stored in the gamestate, the same box can be used for all the possible actions of the town menu.

13: The weird arbitrary rating system has to go, or the fact that it impacts the game. Either all HQ buildings get equal acceptance ratings, OR the rating system is changed to something a little more rational. C * log(max(income, 1)) * log(cargo_transported + 1) * log(company_value) would do perfectly fine as a rating, with C some constant. Yes, it is unbounded, but at least it's more representative of a company's success. I wouldn't call building 80 bus stations in the middle of nowhere as something worthy of getting a higher rating. You could even cap it to <constant> like locomotion does. As a plus, it's probably reasonably fast as well, not having to query as many values.

14: Allow changing the cargo value deprecation minimum and speed(s) via the adv. settings menu. E.g. instead of 1/256ths per day and then later on 2, these two could be set higher or lower. The minimum of 32/256ths could become 1/256ths, and so forth. This way smaller distances can be made economically optimal. It's better gameplay having to think about the length of your route instead of just building the longest possible in any scenario.

15: Corners should only count when they are truly opposite. E.g. a train is not considered to be in a corner unless it has at least 3 different directions among its consist (with 45deg turns off).

16: Station rating is weird anyway... It's another arbitrary system that makes little sense from both gameplay and Real-world standpoint. The age of the last serviced vehicle shouldn't really be an issue. The speed of the vehicles neither. The issue should be whether or not the station can handle the load. So eliminating variables other than service interval and # of items in the station seems in order. At least as an adv. option. As a bonus, it's even faster to compute! So as an alternative:
Rating starts at 85% for any cargo the station starts transporting. Station keeps track of monthly <transported cargo = T>. A load of 6*T lowers rating to 0. T is at least C, with C some reasonable constant for minimum cargo, about 90-130 would do nicely. Edit: the last 15% are from the statue.

16b: Stations should get an 'enable' button for each cargo, allowing you to enable the station to start picking up said cargo

17: Lumber mills should by default not cut down trees, and you should need a GRF to make them do so. Realism nothwithstanding, having an extra player on your team whose sole role is to plant trees for two hours is not fun gameplay at all, period.

18: There are newGRFs to combat this, but I do believe some settings should be standardized.
a) Min distance of oil refineries to coast, max setting should be 2048.
b) Min distance of oil rigs should be a standard setting
c) max. x banks/water towers/etc per town or another min. distance setting.
d) primary/secondary industry ratio should be standard setting. (for example from 100:0 to 100:100), where primary industry is any industry that can produce cargo without accepting cargo (or if there's a flag use that).
e) # of industries should be able to be specified in map creation like # of towns.
All of these improve the game tremendously, as you won't get lakes full of rigs, or towns with 12 banks and 5 houses.

19: Serviced station count shouldn't discriminate. Town growth is weird anyway, but we have gamescripts for that

20: Well it might cost slightly more, but it's still a no-brainer. Suggestion: the cost of electrified rails is added to the cost of a normal rail to compute the cost of a new el-rail. An existing rail's upgrade would be simply the cost of the el-rail. It isn't too invasive on most NewGRFs as these tend to have very high electrification costs by default, to the point where adding the cost of the normal rail doesn't make a huge impact. It would have an effect on some, yes.

[Kiffira]

If you want to make the game more realistic download the cargo dkistribution and if you also want to YACD. Then put the infrastructure and vehicle maintenance up and there you go an economic game in Openttd. Otherwise then the came is mainly focusing on growing towns and shipping call go around the map, with money involved to buy the track/ vehicles to do it.

[andythenorth]

Just play a GS.

The default economy is both known-broken for gameplay, and entirely correct for a transport game.

The solution for gameplay is not to screw around with labyrinthine rules for cargo transport, but instead to use GS to provide a more interesting challenge. Try NoCarGoal or SiliconValley.