Modeling of goods price elasticity and max. population cap.

[ӔO]

I think it might be nice to have these two modeled in the game.

Goods price elasticity, which is also known as supply and demand is a way to encourage players to build up freight networks, niches, that may be neglected by other players or ensure the distribution is not lopsided or incomplete. The basic idea is that if there is a factory with zero supply, the price of the commodity will go up by x and with a maximum of 120% of the base price. If there is oversupply, the price lowers by x to a minimum of 80%. The price fluctuation would be cumulative, meaning the previous number is kept and the same factory will be counted again on the new month.

The simplest formula I can think of is:
At beginning of month
If factory has zero supply, increase demand in goods price by 0.5%.
If factory has supply, do nothing.
If factory has over supply, decrease demand in goods price by -1%.
Add total to previous count.



Maximum population capacity is basically carrying capacity of the map. For any given map size, there can only be a maximum of x population inhabiting it and once that number is reached, cities no longer expand. This would prevent infinite expansion of cities which could cover the entire map with only cities and would result in no agriculture that you would normally find once you reach the edge of the city.

The simplest formula I can think of is: map width x map height = max. population capacity

[sdog]

500k population is not quite a lot for a 500*1000 sized map.

[colonyan]

Given that any map is isolate system, I did imagined a mechanism where total population cap and growth speed is
influenced by the factory supply as AEO presented and also let there be farms as such that they are independent
entity which determines the cost of basic living. Those independent farms should serve as map items to give
absolute rural area which must be kept/respected.

I did also proposed city industries to produce various finished products. Agricultural machines could be supplied
into these independent farms throughout the map to influence the growth speed too.

Just as rough thinking.

[ӔO]

500k population is not quite a lot for a 500*1000 sized map.

well, the other way would be to use hectares of land.
From the internet, it presumably takes about an average of 6 hectares per person.

on a 250m tile 500*1000 map, that would be 3,125,000 hectares and 521k people.
on a 1000m tile 500*1000 map, that would be 50,000,000 hectares and 8,333k people.

maybe even a switch to turn it on or off?

[Carl]

I thought that Simutrans populations weren't supposed to reflect realistic population levels for the area they occupy? In my experience, at 250m per tile the "realistic" Simutrans population is about 12 times smaller than the "real" population for such an area.

[jamespetts]

AEO,

thank you for the suggestions, and apologies for not having replied sooner. Let me deal with them under headings (it might be better to post one request per topic in future, to keep discussion easier to follow and more focussed)

Goods price elasticity

We should be very careful here not to conflate the price of goods with the price for transporting the goods. The relationship between the two is a complicated one. Transport networks will tend to "charge what the traffic will bear". This means that they will charge the highest price that will allow the consignor of the goods still to make a worthwhile profit on the consigned goods after deducting the transport costs (or else the network would not get the traffic at all). The price must not be lower than the variable costs of transporting the goods (or else all transport of those goods would be at a loss), but may be less than the variable costs plus a proportion of the fixed costs of the network.

Competition between transport providers will reduce the price that any of the competing transport operators can charge, but this cross-price elasticity is based on competition for the haulage of a particular type of goods along a particular route: in other words, it exists only when the consignor of the goods has a choice as to which method to use. A cost/benefit analysis is then conducted, in which speed, reliability, safety and price are weighed into account.

In Simutrans, the basic principle of charging what the traffic will bear is simulated by having different per unit costs for transporting different sorts of freight, on the basis that certain types of freight are more profitable for the consignor, and thus that they can afford to pay a higher level of transportation costs and still remain profitable.

Competition based elasticity is not easy to simulate, however. The system proposed here does not really reflect things that actually give rise to price elasticity, not least because factories in Simutrans have fixed contracts with other factories which are not themselves determined by transport cost or quality (and it would be terribly difficult to have a system in which industry linking did depend on these things). Also, factories in Simutrans don't really have an over-supply: they will take a supply until their input store rooms are full, then not take any more until their store rooms have space once again.

The system suggested would, in effect, simulate price competition internally to one transport provider, which makes no sense: if transport company X can supply Y quantity of goods to a factory and can charge Z price per unit for doing so, it has no incentive to lower that price if subsequently it is able to provide Y2 goods to the factory. If there is no competition between different providers, the factory is the price-taker, so it will have no ability to demand a lower price: its choice would be pay the price on offer or not get its goods delivered. Only if there is an alternative transport provider does increased supply of transport lead to a reduction in prices.

Such between provider price competition, however, is probably impractical to model in Simutrans: not only would it involve a multi-factorial method for route-finding, involving price as well as journey time (which would probably have too great an impact on performance to be viable: route finding is already a very computationally intensive process), but it would involve players being incentivised to set prices themselves, which would lead to perverse outcomes if they are not able to do so, or the necessity to micromanage ad tedium to produce optimum profits if they were able to do so.

Population cap

I don't think that this idea works because it does not really reflect real life experience, which is that populations do grow steadily. If what was being suggested was implemented, the population would grow steadily to a certain level at the current rates, then stop entirely suddenly. I am not aware of any real country in which this occurs, except in times of war, famine, etc., which we try not to model in Simutrans (and, in any event, in those extreme cases, the population will start to decline, rather than remain stable).

To prevent excessive growth of towns over the lifetime of a game, one simply has to work out the maximum length of time for which the game is likely to be played (for example, 300 game years: 1750 - 2050), and set the growth rates and starting sizes of towns such that, by the end point, they are likely to be at a realistic size.

[isidoro]

I think multiplayer gives the opportunity for a certain competition.  Imagine a factory with two stations belonging to two different companies.  Maybe it is possible for the owner to set a percentage discount on the base price of the goods.  If the factory has to buy more goods, it will buy it from the one available with the greatest discount.

That way, a company is forced to look for better routes, cheaper vehicles, etc.  Time of delivery would have nothing to do here, since goods are bought at destination, not origin.

[jamespetts]

The problems, as I wrote above, with the player being able to control the price and the price having an effect on which route is taken are:
(1) the player will be forced to undertake tedious price micromanagement in order to maximise profitability; and
(2) it would make the routing system too computationally intensive to take account of more than one factor.

If you are suggesting using price instead of speed for routing of goods, then it is not the case that delivery time does not matter: many goods are perishable, and it is very inefficient for highly valuable goods to be tied up in transport for a very long time.

[isidoro]

I think I mixed up things.  I didn't recall that, in ST, you are paid for moving goods, not for the goods itself.  Sorry.