News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Mismatch between production and vehicle capacity

Started by ras52, September 09, 2013, 12:52:15 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ras52

For some time I've felt that many of the factories in many of the paksets product far too produce to be realistic.  I prefer to play the early game (18th century), and it's not unusual to find, say, a cattle farm producing milk at a rate that will nearly saturate the capacity of the road.  Surely that can't be realistic? 

In my current game (year: 1754), I have a cattle farm occupying 18 tiles with a production level of around 300 units per month.  The game's cattle farm has 100% milk production and a crate of milk weighs 960kg, so my farm produces around 288,000 litres per month.  One tile is 1/64 km^2 or 3.8 acres, so my farm is 70 acres.  A bit of googling suggests that one cow per acre is a general rule of thumb, at least these days, and that the average UK dairy farm has 123 cows each producing 7000 litres a year.  So my farm is smaller than average for today, but historically farms were.  At modern milk yields, my 18-tile farm should be producing about 40,000 litres a month, but I bet in 1754, yields were a fair bit lower.  However, this overestimate is a fairly minor balancing issue specific to the cattle farm.

However, there's a much bigger source of error.  In the game, a wagon can carry 5 crates, or 4800 litres of milk.  That seems broadly plausible, and I found someone on the Internet saying their two horses could pull a 4-ton wagon.  In my current game, I therefore need 60 wagon trips each month to transport the milk produced by my farm.  In real life this would mean two wagons a day, but because each game-month comprises only 384 game-minutes, we need a wagon every six minutes.  In real life, a single wagon could travel 10km to a dairy and back the twice a day in a 9-to-5 day; in the game, you need more than 30 wagons travelling constantly, which is 1/4 of the theoretical capacity of the road (because road vehicles need to be separated by 125m).  Basically, the fact that a month is 100 times too short introduces a 100-fold discrepancy between productivity and vehicle capacity.

One possibility is to ignore the problem.  It's a game about transport, and won't be much fun if there's hardly any transporting going on.  I expect that would be response if I reported this for pak64.  However pak128.Britain-Ex seems to regard accuracy higher than some of the other paksets.  In any case, I think making the game more accurate needn't make it less fun, though it would change the dynamics of aspects of the game.  I suspect there would be more small-scale transport to hubs, perhaps with road vehicles going round multiple industries.

Another justification for ignoring it is to say that each factory is actually representative of about 100 similar factories.  In the real world, the countryside has farm after farm after farm; in the game, we simply depict 1% of them, leaving plenty of space for players to build their transport infrastructure.  That makes sense for things likes pubs, too, where in real life, every village would have one.  There's something to that, but personally I'd prefer my maps to be much more industry-dense, but can't do that currently because of the problem that would cause transporting them all.

Richard Smith

Sarlock

It's a good point you make and one that I have considered before as well.  It's a pakset decision on how best to reconcile the imbalance.

The average modern dairy cow produces around 20-25 litres milk/day which is roughly 20-25kg in weight.  If this farm is producing 10 tonnes per day (300 crates per month) this is about 10,000 kg or 10,000 litres/day (assuming density of milk is at 1 l=1 kg which it isn't but it's close enough and makes for easy math).  At 20 litres/cow/day this is a farm with 500 cows, utilizing roughly 500 acres.  Of course, as you say, we are being representative here so that the map is mostly vacant for the player to use, so our one dairy farm represents many farms.  Maybe there are 10 x 50 cow farms in this area at 50 acres each.  (add to this that many modern dairy farms bring in feed and the cattle have limited mobility, so 500 cattle could easily be housed in just a few acres -- but there was still several hundred acres somewhere nearby that produced the feed for this cattle to eat).

So we have 10 dairy farms producing ~1,000 litres(kg) [1 tonne] of milk per day being represented by a single dairy farm picture on the screen.  We then need to bring 10t of milk to market every single day (300t per month).  Of course, if we were using a 10:1 ratio for the farm then really we should use a 10:1 ratio for our road vehicle as well.  Thus, one wagon should be able to pull 50t of milk, not 5t, since our wagon picture represents 10 actual wagons on that road tile.  This would require 6 wagons per month to transit the route.  Hardly any impact on road volumes.

Of course, we choose to not use a 10:1 scale for transport because that's the aim of the game.  We instead choose 1:1 and therefore the player needs 60 wagon trips to bring the milk to market, not 6.  Given that we aren't making a road 10 lanes wide to compensate, it overloads the road network in short order and causes bottleneck problems that the player has to resolve (something that becomes significantly easier with rail transport).

There's a few ways to attempt to reconcile this issue but each has its advantages and disadvantages:

Increase convoy capacity to be 10:1 (wagon hauls 50t instead of 5t).
- More accurate representation of road traffic, roads can easily handle the volume.
- Now we wonder why a single wagon on the road can haul so much weight (a modern truck carrying 250t a load!)
- Less interesting for the player, a lot less happening.  One road vehicle to service an entire factory, spending much of its time waiting for a full load (unless it's a long route)
Increase time scale to be close to real time
- Again, we can serve with just a few wagons because they have so much time per month to make the journey
- Who wants to sit around for 24 hours waiting for a single game day to pass?

This leaves us with your solution: increase industry density.  But with a caveat: reduce production levels accordingly and reduce the production ratio from 10:1.
Build 10 dairy farms in the same area and reduce production levels to 3:1 or something closer but still high enough to put enough wagons out to be interesting.  10 dairy farms producing 10t/month (100t/month total production) would probably be a good balance, give or take.  I've done this before with my farms in previous games, I find it more visually rewarding and adds to the logistic challenge of aggregating production from multiple farms spread out over an area.  If using a smaller scale, like 125m/tile or smaller, then it's more realistic from a scale perspective as well.  It just requires you to manually add the industries to your map instead of letting the game do it, unless you want to go to the advanced step of recompiling the industries with lower production figures (but then the game likes to spread your industries all over the place instead of grouping them together as you would want with low production).
Current projects: Pak128 Trees, blender graphics

jamespetts

Thank you both for your comments. As it happens, I am currently dealing with a related issue in preparation for the next major release, which is that factory and electricity production are not currently scaled properly to match the meters per tile setting, and I need to consider precisely how they should be calibrated at base so that I can scale them properly.

The principle, however, should be that factory production, passenger generation, mail generation and electricity generation, as well as running costs, should be scaled accurately to in game hours rather than to months. The only things that should be scaled to the months/years are: (1) capital costs; and (2) introduction/retirement dates.

So, if there is a diary farm in 1754 producing 288,000 litres of milk per "month" (i.e., per quarter of a day, as a month in Pak128.Britain-Ex 0.9.0 default settings is 6.4 hours), that is bad calibration and needs to be fixed. Your milk production statistics are very useful, and I shall try to remember to refer to them when I do recalibrate the dairy farm. (If you have any other farm output statistics, it would be very helpful if you could post them here, too).

Before I can do the calibration properly, however, I need to fix the basic scale against which all things are calibrated for the next major version (currently in the passenger-generation branch on Github).
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.

ras52

Thanks for both of your replies.  There are some interesting points here.

Sarlock — you use 1:10 as the current over-production of the cattle farm.  That's roughly correct for over-production per game-month, but the over production per game-hour is about 1:1000.  Unless I've misunderstood him, James is saying that it is the productivity per game-hour that ought to be accurate; for what it's worth, I think he's right.  So we're looking to explain and/or correct a thousand-fold over-production.

It might be reasonable to suggest each factory actually represents a cluster of 10 nearby factories of the same type.  A farm occupies a lot of space, so it's plausible to make a farm in the game occupy the correct area.  But that's not true of all industries: a pub doesn't really occupy a whole tile's worth of space, for example.  And in any case, transport infrastructure takes up far more space in the game, and we need to make space for it.  So it seems quite reasonable to multiply up productivity from reality by a factor of, say, 10 because of that.

But that still leaves a factor of 100, or thereabouts, to either explain or correct.  If that involves a significant decrease in the productivity, it will significantly affect the dynamics of the game, and a significant increase in industry density if the game is to retain much interest.  I think that's no bad thing.

Sarlock mentioned the problem that when you let the game place multiple similar industries, it places them far apart.  That's easily solved by tweaking the industry placement code.  When an industry of the same type already exists, simply make it more likely that the new industry is placed near the old one.  That reflects reality well.   A cattle farm will probably be near another one, because certain areas will have climate and soil that's particularly suitable to cattle farming; a coal mine will be near another because that's where the coal seam is; a biotech campus will be near another one because that's where the local experience is.
Richard Smith

jamespetts

#4
The productivity imbalance needs correcting rather than explaining, I think - the only explanation can be that it is wrong. If anyone is able to find data about other sorts of farms, I should be very grateful. I have managed to find good information about most other types of industry, as reported in this thread.

As to the industry placement code, what would be far better is the actual simulation of resources (in a somewhat approximate way), but that will probably have to wait a long time for me to plough slowly through a very long queue of higher priority tasks.

Edit: I have now applied code scaling factory production on the passenger-generation branch. It might need a little further work, but it seems to work in principle. This has indeed very greatly reduced factory production (in one instance, for example, from about 4,400 units per "month" to 72). This will require some considerable recalibration of the pakset's industry production values to make work properly (and might well require calibration of the storage amounts by meters per tile/bits per month, etc., too), but it seems to be at least a start in calibrating this correctly.
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.

Sarlock

An important thing to consider is that for many factories, production and employment will increase with sustained demand: A steel mill that has high downstream demand and extra resources available will likely expand in the near future to supply the increased demand for steel (add more shifts/day, more equipment, expand the building, etc).

Agriculture faces a different challenge in that it must cultivate additional fields in order to increase production (excepting the increased production that technology brought about over the 1750-2000+ period).

The challenge in finding much statistical data for farms, especially pre-1950, is that most were family run, fairly small and only hired outside staff during harvest time for the most part.  A fruit orchard might hire extra fruit pickers for a few weeks in summer but other than that most of the upkeep of the orchard is done by the owner(s) of the farm.  With the increase in large corporate-run farms post-1950 the dynamics change somewhat, though still the production per acre and labour per acre remain somewhat constant, once the effects of technology are removed.  A family in 1880 might, if they worked very hard, cultivate a quarter section (1/2 mile square = 160 acres) over the period of a year and have significant surplus crops for market.  The same farm today is probably farmable in just a few days by a corporation that owns thousands of such sections in an area and farms them as a group.  (a large tractor is clearly a lot more efficient than an ox-drawn plow)  In order to accurately model farm production, you would need to have large sections of the map covered with farms.  Otherwise a compromise is to boost production at a few farms and allow those to represent a larger agricultural area (as we do now).  I think of the North American central prairies in the 1800's and they were mostly small quarter-section family run farms and brought their goods to the central town some miles away (via horse and cart) to be put in the grain elevators and hauled away by train.

I'll test out the factory production changes in the next release and see how it impacts things.
Current projects: Pak128 Trees, blender graphics

jamespetts

QuoteAn important thing to consider is that for many factories, production and employment will increase with sustained demand: A steel mill that has high downstream demand and extra resources available will likely expand in the near future to supply the increased demand for steel (add more shifts/day, more equipment, expand the building, etc).

This is dealt with by the production boost mechanism.

As to having large parts of the map covered with farms, that is not a bad idea. Previously, the idea was impractical because farms always started with the minimum number of fields, and could not be reduced below that number, so people could not build on the fields, or, more importantly, build roads up to the farm building to allow produce to be taken away from the farms. In recent versions, I have changed that to allow the number of fields to be reduced to 1/2 the initial number ("minimum", which is not a minimum any longer), so it now should be possible to have realistic numbers and sizes of farms.
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.

Sarlock

If the number of fields that a farm has is proportional to its production rate when being built and production rate per field was significantly reduced, this would provide a pretty nice farm effect in the game.  Then, in order to not make the map look too cluttered by a single tile type, it would probably be prudent to create different field graphics for the same types of farms... this would not be too hard to do (something I am working on for pak128 anyhow, in blender, so I could easily adapt those same graphics to pak128.Britain by changing the lighting setup), you can use the same central farm building graphics and develop a slightly changed graphic for fields.  This will give a bit more variation on the map and look pretty amazing.

Another handy thing, though I suspect this would be more difficult to implement, would be the ability to drag transportation ways through fields and have them automatically removed like trees.  Otherwise a heavily farmed area could be a real barrier to the player(s) in a game (and it's a pain to have to bulldoze each one individually).
Current projects: Pak128 Trees, blender graphics

jamespetts

Thank you for your offer re: the fields - that is most helpful. That might be worthwhile doing indeed.

As to auto-bulldozing farm fields, that is a good idea. I shall have to look into doing that when I get a moment.
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.

Sarlock

Farm field size does scale somewhat to production currently in Standard (and, I assume, it was ported to Experimental, but I can't test due to being unable to change production numbers on placing) so the mechanism already exists, it's just a matter of expanding on the logic a bit.  It will take a bit of playing around to see what size of farm look the best when grouped together.

Given that farms produce only during a small part of the year (harvest time) but Simutrans industries produce throughout the year, we can take an annual per acre harvest yield average for different eras and approximate what the yield would be averaged over a 12 month period.  I'll work on some numbers and some new farm graphics (I already had some preliminary work done for this so it should be fast - the hardest part about drawing fields is that it takes a lot of work to make them look nice when grouped together and not have ugly patterns farming).
Current projects: Pak128 Trees, blender graphics