News:

Simutrans Tools
Know our tools that can help you to create add-ons, install and customize Simutrans.

Balancing 0.7 in 1750

Started by ras52, December 13, 2010, 05:42:03 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ras52

I've been testing 0.7 starting in 1750 to see how playable it is this early on.  It seems to be a big improvement on the last version I tried seriously, but there are still a few balancing issues and other minor problems.

1.  The macadam masonry road bridge is using the wrong images -- it's using the cobblestone one, even thought git now seems to have pngs for the macadam surface.

2.  Is macadam the right name to describe the earliest type of road?  According to Wikipedia macadam wasn't introduced until the 1820s, and in fact cobblestone roads were replaced by macadam ones, not vice versa. 

3.  Is there a place for a more primitive droveroad. They would have minimal maintenance cost, and be unsuitable for any sort of wagon.  Their purpose would be just to drive livestock; I'm not sure whether that would be best achieved with a prohibitive way constraint or just a very low weight restriction.  They were quite common in rural areas of the country with few proper roads such as the North York Moors.

4.  Should the weight restriction for a cobblestone road (8t) really be so much less than for a macadam road (80t)?  If this is intentional rather than a typo, I assume it reflects the idea that cobblestones provide a higher speed surface, but one that is easily damaged.  But if so, why is the weight restriction on a masonry road bridge lower with a macadam surface (4t) than with cobblestones (7t).  This means that until 1765, the heaviest-duty road bridge available only has a 4t weight restriction.  However, a stage wagon full of piece goods weighs 5t, and so until 1765, there's no way of it crossing a river / canal.

5.  The running cost of a horse and wagon is 0.27¢/km and it carries 3t.  With bulk goods only fetching 0.17¢/unit-km, and the 8km/h speed-bonus inaccessible, it's not possible to make a profit carrying bulk goods by road unless the wagon can be reused for some of the return journey.  Reducing the running cost of a horse from 0.25¢/km to 0.15¢/km would allow a profit of perhaps 18¢ p.a. on a straight, flat route; that would pay back the capital cost of the horse and wagon in 10 years.  It would still never be profitable to use a pair of horses to haul low-value goods (unless it can travel full in both directions) which seems right. 

6.  Horses bought in shipyards have a running cost of 0.07¢/km while those bought in coaching stables need 0.25¢/km to run them.  Is the disparity intended?  Is it historically justifiable?  Reducing cart horses to the same running price as barge horse would make them profitable in almost all situations (perhaps overly so).

7.  Would it make more sense to change horses' running costs from per km to per month?  An idle horse still needs looking after, feeding, etc.

8.  Do the carts serve any useful game purpose?  They cost the same as wagons (50¢), they're introduced at the same time (1750), and they weigh the same (1t).  Per unit transported, wagons are 50% more expensive to run.  At the very least they should be a lot cheaper to buy, but given you need a 125¢ horse to pull them, that makes little difference.  Perhaps if there were a cheaper beast (e.g. a donkey) available to pull it, that would help.  But even then, it's only really of relevance if the player has insufficient money to afford horses and wagons.  That seems a very niche case.  Were the horses' running costs changed to per month, that would offer an incentive to use a carts for very low capacity routes.  Allowing them on a drove road would provide another niche use for them.

9.  Similarly, do Norfolk wherries or unpowered barges serve any useful game purpose?  They all cost 50¢ (though the latter needs an expensive horse to pull it), and their running costs are the same or more as the Humber keel.  In the real world, so far as I'm aware, Humber keels were only used for transporting bulk goods.  (Googling, I found this site which seems to have some interesting information on the subject of early waterways.)  And presumably wind-powered craft were only used in flat, exposed areas of the country.  I don't really understand simutrans-experimental's physics model, but can the power value be used (or abused) to stop wind-powered craft going up hill at all? That could serve as a convenient proxy for how windswept the area is.  It might also make sense to reduce the speed of wind-powered craft to simulate the fact that there won't always be enough wind.  In reality, wind-powered craft could also navigate lakes or sheltered inshore waters (e.g. the Wash) which a horse-drawn barge obviously cannot do.  But I don't think simutrans-experimental is able to simulate that.

10.  The relative running costs of the most efficient road and waterway vehicles (a horse and wagon at 0.27¢/km versus a Humber keel at 0.02¢/km) seem a little implausible given their relative capacities (3t vs. 50t for bulk goods; similar for other goods).  Likewise, the costs of buying them (175¢ vs. 50¢) seem wrong.  Even reducing the horse's running cost leaves a surprisingly big gap.  It's historically accurate that transportation by water should be much cheaper than by road, but this seems excessive.  On a straight, flat route, a Humber keel can make 400¢ p.a.  I suggest it's running cost should be quite a bit higher, as should its purchase cost.  A running cost of 0.50¢/km would have little effect on its profitability, and given the anticipated return from it, a price of, say, 500¢ seems easy to justify.
Richard Smith

AvG

#1
Hi Ras52,
I am glad that somebodyelse is making remarks on prices and maintenance-cost.
IMHO this is a very important matter for the serious player who is willing to play a large scenario from 1750-2050. The possibility to do this should be the starting-point of developers.
REALISM, combined with feasability, should be the goal.
We are dependend on hobby-developers. They develop what they like most and you may not blame them for that. They are hobbyist and no emplyees. If you are not able to convince them you are done.
There are 2 kinds of development that are interacting: The .exe and the PaK-file.
Dev of the .exe-file is the most difficult. If you are not an experienced programmer you can forget it. After the intro of Windows95 I stopped programming in C and I doubt if I can reach a level to be able to make changes in the .exe.
Dev of Pak is not so difficult, but very time-consuming.(pixel-drawing)
Years ago I started DRC (Dutch Reality Connection). It is intended to be an addon for every Pak.
All prices and maintainance of vehicles and buildings are related to each other via a huge background matrix where the year, inflation, efficiency, inventions, etc are playing important roles. Of course a lot of educated guesswork and simplification in such a job. Your link to igg.org.uk is very valuable for possible input in the matrix.
Your point of horse-problems I completetely understand. I solved it in DRC by replacing the everlasting horses by 11 new horse-types. The Albanian-horse of 1750 has a price and running cost of 80 and 0,01. The Tori-horse of 2000 has 963 and 0,32. A huge difference, but also a big timespan of 250 years.
Are you using Standard or Exp?
AvG
Edit: This is the max length of an entry I can make. I am typing now in an invisible part of the  reply-window. Is this a matter of settings somewhere?
Ad van Gerwen

ras52

Thanks for your response, AvG.  You make some good points that have made me think...

Quote from: AvG on December 13, 2010, 12:15:32 PM
We are dependend on hobby-developers. They develop what they like most and you may not blame them for that. They are hobbyist and no emplyees. If you are not able to convince them you are done.

I completely agree.  I hope that my comments were not taken as criticism of the excellent work the developers and other contributors are doing, as that certainly wasn't my intention.  I've been playing it for several years (initially pak64, and more recently, pak128-Britain) and have greatly enjoyed it ,but it's only recently that I've started wondering whether I can do anything that might help improve it further.

Quote
There are 2 kinds of development that are interacting: The .exe and the PaK-file.
Dev of the .exe-file is the most difficult. If you are not an experienced programmer you can forget it. After the intro of Windows95 I stopped programming in C and I doubt if I can reach a level to be able to make changes in the .exe.
Dev of Pak is not so difficult, but very time-consuming.(pixel-drawing)

I can't see myself contributing to the Pak graphics -- that really isn't my sort of thing.  But I'm a Unix C++ programmer and the bits of simutrans code I've been reading doesn't look to bad to me.  That said, I think I'm more interested in contributing to balancing the game play.  It seems to me we already have an excellent game engine and a good historically-plausible range of graphics.  I appreciate simutrans will appeal to different people for different reasons, but for me part of that appeal is that it's a winnable (and, importantly, losable) game.  To me it loses that appeal if it's not possible to remain profitable -- or for that matter, if it's too easy to stay profitable.  So from a purely selfish point of view, spending time fine-tuning the balancing seems the best way of improving those aspects of the game I'm interested in.

Quote
Your point of horse-problems I completetely understand. I solved it in DRC by replacing the everlasting horses by 11 new horse-types. The Albanian-horse of 1750 has a price and running cost of 80 and 0,01. The Tori-horse of 2000 has 963 and 0,32. A huge difference, but also a big timespan of 250 years.

I'm intrigued that you still provide horses in the 21st century.  The 1918 obsolescence in pak128-Britain-Ex_0.7 seems reasonable enough to me.  Except while petrol was rationed during and immediately after WWII, were there any real-world situations when horse-drawn public transport or freight transport was the norm?  The only cases I can think of are (i) short-distance urban freight, and (ii) remote rural transport where the roads are unsuitable for motor vehicles.  Within the game (i) perhaps exists delivering beer from a brewery to a nearby pub and similar urban industry chains; maybe urban mail too.  However (ii) doesn't fit in the current game as there's no such thing as a road that's unsuitable for motor vehicles -- though the drove road I suggested in point 3 would perhaps do that.

But your comment also raises an interesting point about inflation.  As I see it, the simutrans currency is to inflation adjusted (at least to some extent).  This shows up in the goods rates, which are constant throughout the 250-300 years in which the pakset is playable -- for example coal always pays 0.17¢/t/km.  (Speed bonuses don't change this as the monetary value of the bonus does not change even if the criteria for giving it do.)  So if your horse's running costs increase from 0.01¢/km to 0.32¢/km over the course of 250 years, what's that trying to represent?  Is it just that the horse is becoming obsolete?  Simutrans-Ex already has a means of increasing price over a period of obsolescence -- by default a four-fold increase over 40 years.  For the horse, that's 1918-1958 which is pretty close to what (I think) actually happened.

In the real world, did a horse and wagon cost more to run (in real terms) in 1918 than in 1750?  My guess is probably not -- unlike now, the expertise in training horses and making wagons, horseshoes, harnesses, etc. still existed.  The difference was that other modes of transport (first barges, later trains) were able to do the job more profitably.  But equally, in areas of the country without railways or navigable waterways (e.g. large parts of the Northwest Highlands), horses must have still been commercially viable as they were still regularly used.  In the game, the way to do that seems to be to make sure that the newer forms of transport are both faster and either more profitable or capable of larger throughputs.  They need to be faster so that when the old form of transport is competing directly with the newer form, freight is preferentially routed via the new mode of transport.  But you also need an incentive for a player (or a competing player in a network game) to set up a network using the newer mode of transport.  Making the new mode more profitable is one possible incentive; gradually making the old mode less profitable is another; and allowing higher throughput is a third.  (I think I prefer the latter as it avoids the problem of games becoming boring by being too profitable.  It also avoids implausible scenarios which result in railways being built to every last outlying farm.)

Quote
Are you using Standard or Exp?

Experimental.  Specifically, a git checkout from the 9.x branch -- so effectively a pre-release of 9.0.
Richard Smith

The Hood

Just as a brief comment - balancing is a pak-maintainer's nightmare as it generally requires lots of time to test which we generally don't have.  If you're interested in it, please do whatever you feel like and propose changes.  I for one am much more interested in getting graphics drawn (when I have time) than fine-tuning prices etc.  A lot of the prices in pak128.Britain have not even been approximately adjusted (all boats for example), but road, rail and tram vehicles should be approximately profitable for most of their lives.  The thing is that vehicle running costs are also related to profitability via maintenance costs of ways and buildings, and these are not balanced either.  On top of that in experimental is the fact that most costs are taken straight from the standard version and haven't been adjusted AFAIK to the different game engine.

So in summary I took the view it was best to complete the graphics for the pak first to get a more realistic game world in which to test the ways and vehicles, and only once that was done to seriously tackle balancing.  Thing is, that's likely to be a few years down the line development wise unless someone else steps in, so by all means make suggestions/changes to either or both the standard and experimental branches of the pak.

jamespetts

Richard,

thank you very much for your insightful contribution, and apologies for not having replied earlier: I have been kept busy this week! Let me deal with the points in number order.

1. Thank you for spotting that - will be fixed in the next version.

2. That is very interesting - I don't think that I'd researched that properly. Do you think that it'd be beneficial to have separate types for "dirt roads" (can you suggest a better name) and proper MacAdam roads? If so, how do you think that they should be distinguished graphically, and what settings/balancing should the MacAdam road have?

3. This is an interesting idea. I imagine that its costs would be negligible (perhaps a tiny construction cost and a zero maintenance cost). What would you suggest for graphics to distinguish it from the other two non-metalled types of roads?

4. The idea of having a very high weight limit on what I had (probably incorrectly) described as the MacAdam road was that it was supposed to be an all-purpose dirt road type, which can, as someone pointed out once, take a very great weight indeed in theory, if one goes slowly enough. Cobblestones are, as you point out, easily damaged. As to the bridges, the idea was that the difference between the two bridges was not just the surface, as bridge technology had moved on in the interim.  However, I had not spotted that the wagons were heavier when they were loaded - I shall increase the weight from 4t to 5t in the next version.

5 - 7. Ahh, the old chestnut of price balancing. I have not even really attempted this yet, partly as it is a truly gargantuan exercise, and there are other things that need to be done first, and partly because I had been hoping for some real-life data (particularly with respect to railways) that, unfortunately, has not been forthcoming, and I am not quite sure what to do without it. Do you happen to know where I can discover, for example, how much more expensive that it is to build a diesel locomotive than a steam locomotive, how much more expensive that it is to run a steam locomotive than a diesel locomotive, how much more a large ferry costs to build than a 'bus, or the relative price of installing 3rd rail electrification compared to overhead catenary? Until a large, universal re-balancing can be done properly, therefore, the policy that I have so far adopted has been to leave things as they are unless there are any glaring anomalies which can easily be rectified without having to change a large number of different things. The same applies to the use of per month running costs - this feature is more or less unused because to use it would require invoking the mammoth re-balancing task that has so far not been possible for we beleaguered pak maintainers to undertake (and bear in mind that the Experimental re-balancing will need to be done separately to the Standard re-balancing, as Standard does not have the fixed monthly cost feature, and is balanced differently in terms of revenue, too). There may well be a case for reducing significantly the running cost of the cart horse as the sort of glaring anomaly described above - I shall set it to 0.15c/km for the next release for the time being.

8. I see your point. For now, I shall reduce the price of carts by more than half. I have doubts that donkeys will add much useful to the game, but allowing them on drove roads, if they are introduced, is an interesting idea which merits further consideration.

9. You should probably ask The Hood this one, as this is not an issue specific to Experimental. The other suggestions require changing the code (in possibly quite complicated ways), so that will need to be considered for the rather more distant future. In the meantime, any suggestions as to how to provide a useful role for these different craft without code changes would be appreciated.

10. I shall increase the costs of the Humber Keel as suggested - thank you for that!

In more general terms, your assistance in balancing the gameplay of Pak128.Britain-Ex and Simutrans-Experimental would be very welcome indeed, as this is an area that currently needs a great deal of work (and has been an area on which I have been working of late, although more recently distracted by bugfixing in the run-up to the release of 9.0). Other than the particularly huge task of price balancing, there are a few other things on which balancing work needs to be done on which any assistance would be much appreciated, as follows:

1. Industries - someone recently experimented with changing the balance of industries such that there were a much larger number of end-users (shops) compared to primary and secondary industries, and found that this worked well in principle; this needs to be investigated, fine-tuned and, if it can be made to work well, adopted.

2. Steam railway locomotive power - the tractive effort figures for the steam locomotives are mostly historically accurate, but the power figures are guessed, as these data are not widely available. These figures will have to be adjusted based on experimentation and historical performance data from real life. I have a book with quite a bit of this information, so I can probably do this one.

3. Passenger distribution/generation - this is the one on which I have been working most recently, and have made some progress in the run-up to releasing 0.7 (and also in the code for 9.x, to a lesser extent). This will need further testing, however, as I do not know how well the latest changes have worked and whether anything needs re-adjusting.

4. City distribution/size - this is more about map generation settings, but, when a complete set (i.e., executable and pakset) are distributed together, default settings for this can be fine-tuned and pre-set at optimum levels for realism; however, I have yet to discover what the optimum levels are for the number and size of cities to be generated, and also the balance between initial city size, city growth and the passenger factor (the latter of which is also involved in the balance relating to journey time tolerances, which complicates things considerably).

5. Online play - this is very new to Standard and not tested in Experimental yet, but once we manage to get Experimental working online, consideration will need to be given to what rebalancing is necessary to make it work well in a multiplayer environment. I have a few ideas  at present (which are also relevant to Standard) that I am about to post in "Extension requests".

Thank you again for your helpful feedback!
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.

jamespetts

See now here for some useful relative pricing information for the capital costs of railway vehicles.
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.

AvG

Started a game in 1750 with the newest config.
Gamesize: 320x640, 1 big city (8500) and 64 cities (med 1600)

At 19 bits/month maintenance is too high ( >100% of newprice per year) A good rule in maintenance-precalculation is 10% of newprice per year. So I reduced maintenance by a factor 10. 
Note: This situation will improve the moment more building-paks are with their own maintenance-data.

Passenger_factor=20.
The real reason for this scenario is checking the effect of this factor.
Result: Within 4 years the game is not playable any more, due to the huge supply of passengers. Roads are overcrowded with small, slow vehicles. There are simply no transport-means in this era to do mass-transportation.
It is also highly unrealistic. The industrial revolution just had started, but had in 1750 hardly an influence. I guess that maybe 10% of the population could afford to travel as a luxuary and maybe another 10% had to travel for its job.
The rest of the people was POOR and could not travel AT ALL.
This 20% in 1750 will rise to 95% in 1950.
IMHO it would be easy to implement this % in the passengers_factor.
AvG
Ad van Gerwen

jamespetts

AvG,

thank you for your observations: these are most useful. I am still trying to find the right balance in respect of passenger factors: this had previously been too low, and is now too high. There is additional complexity with passenger levels in relation to the journey times tolerance feature, which tolerances were also significantly relaxed for 0.7. My preliminary view at this stage is that it is best to use a passenger factor of 16 (the Standard default) and tune the passenger generation beyond that using journey time tolerances, which seem to have a greater effect than the passenger factor itself on the number of people travelling.

As to the maintenance costs, I shall keep in mind your comments for when I conduct the full balancing exercise in due course (but it will be an truly gigantic task).

In respect of the final suggestion, it is an interesting thought that the number of travelling passengers in the 18th century was restricted by cost rather than by journey time. Are there any historical data from which relatively accurate figures can be obtained for this? This is more complex than at first appears, however: part of the reason that more people could afford to travel in later days is precisely because mass transport made travel cheaper. Few indeed could afford their own horse or carriage (and that is already taken into account with the private cars factor), but was very little other in the way of transport in days of old, apart from stage coaches and wagons, which took an enormous amount of time. I suspect that people could afford to take that much time out of their work rather less than they could afford the fare. A further complexity is that some people would have been able to afford short journeys but not long journeys, which would not be simulated by a simple percentage change. Also - if few can afford to travel, should the player then not be given the option to reduce the prices? I have deliberately avoided either anything which involves the player having control over prices charged to passengers or goods or anything that would give the player an incentive to have such control (without actually giving the player that control, which would then be frustrating and give rise to arbitrary outcomes) because it would make it quite difficult to manage.

Is not a simpler way of altering the number of passengers generated over time simply to increase the passenger level of town buildings that towns build in later years than earlier years?
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.

Archon

I got some suggestions about carts and wagons.

Problem is often that simutrans engine doesn't allow enough these small and slow convoys on single road. This makes it hard to supply early shops that are located in city center. There are 3 possible solutions for this problem:

1. Rewrite code that handles road traffic. :)
2. Increase speed of vehicles.
3. Increase capacity of convoys.

So I ended up increasing speed of carts and wagons from 6 to 8 km/h (mailcart 10 km/h) + made it possible to use 2 wagons in 1 convoy (horse -wagon - horse - wagon).

Also as suggested added donkey for carts (greyscale horse graphics).

Paks/sources for experimental.

http://www.saunalahti.fi/jusskiiv/pak/donkey+stuff.zip

jamespetts

Actually, there's a fourth solution: reduce the capacity of the shops in city centres :-) This has previously been suggested by AvG, and I am planning on implementing this when I get a chance.
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.

sdog

Quite a good solution, by greatly increasing the number of shops also, it becomes quite interesting to create large distribution networks.
Players can also build canals into the cities. This was done to provide transport to industry all over europe, and i'd bet it was done in england too. England was the template for most continental european canal projects.

AvG

Restarted scenario of reply 6.
Settings: Reduced maintenance 45 i.s.o. 450
             Passenger-factor 8 i.s.o. 20
After 3 years of playing still fun to play.
1 big city (8500) and 7 small cities connected.
Total investment ~25K and monthly profit of 250-300. So a yearly return on investment of ~ 15%.

I want to tweak maintenance-cost in the .dat-files of buildings.
Where can I find an example?
AvG
Ad van Gerwen

Archon

Did some testing with wagons.

Test run 13 tiles long straight road including stops. Transporting coal.

Standard wagon horse combination:
11 convoys is maximum that fits.
Transports 48 units / month.
Line profit ~14 - infrastructure.

Modified wagons from my last post:
8 convoys.
transports 96 units / month.
profit ~26 - infrastructure.

Road maintenance costs 0,65 / month and loading bay 2*9 ? / month.

These values can be reached only if there are no other traffic on road.

AvG

James,
I looked into your Git-repo in order to find info about how to use the newest data w.r.t. buildingcost and maintenance.
It seems that your rep contains not the newest info.
Could you show at least 1 .dat-file of a building, as an example on how to use these new variables. (or a place where to find it)
AvG
Ad van Gerwen

jamespetts

AvG,

the Git repository is up-to-date apart from one or two of the latest vehicles that I released yesterday in the forum. However, note that there are multiple repositories on Github, only one of which is maintained. this is the correct one.
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.

neroden

Quote from: jamespetts on December 16, 2010, 01:20:05 AM
5 - 7. Ahh, the old chestnut of price balancing. I have not even really attempted this yet, partly as it is a truly gargantuan exercise, and there are other things that need to be done first, and partly because I had been hoping for some real-life data (particularly with respect to railways) that, unfortunately, has not been forthcoming, and I am not quite sure what to do without it. Do you happen to know where I can discover, for example, how much more expensive that it is to build a diesel locomotive than a steam locomotive, how much more expensive that it is to run a steam locomotive than a diesel locomotive, how much more a large ferry costs to build than a 'bus, or the relative price of installing 3rd rail electrification compared to overhead catenary?
Heh.  Diesel and steam locomotive costs varied according to time period and the availabillity of particular types of specialized machining (!), so that it was once cheaper to build a steam locomotive, but is now more expensive.  For a large ferry versus a bus, you can very roughly compare the tonnage, as most of the cost is proportional to sheer volume of steel (so yes, it costs a *lot* more) -- unless you're talking wooden-bodied vehicles!  DC electrification requires 5 times as many substations as AC, and wire twice as thick, but the transformers traditionally cost about half as much, so a very rough estimate is a factor of 2.5 more for DC; third rail costs more to install than overhead line (more metal, more careful insulation), but overhead line costs more to maintain.  Is that any help?  :-)

Edit: the key difference making DC viable, if I remember correctly, is that the vehicles are significantly cheaper and lighterweight for DC electrification than for AC electrification.