News:

Use the "Forum Search"
It may help you to find anything in the forum ;).

A path to balance

Started by jamespetts, October 24, 2013, 01:16:05 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jamespetts

The task of having a properly balanced pakset for Simutrans-Experimental has been long delayed. The most comprehensive pakset for Simutrans-Experimental has always been Pak128.Britain-Ex, and that has never received a full set of balancing works, with a result that prices are often haphazard, creating perverse incentives and rendering large numbers of vehicles economically irrelevant. (I should note, however, that the fares for passengers and goods have been calibrated against each other based on historical data since version 0.8.4 of the pakset).

The main reason for this delay is that the planned features for Simutrans-Experimental include quite a number of features that will affect the game balance significantly: if those features were implemented after the balancing exercise had been conducted, it would be necessary to restart the balancing exercise. There is also some doubt over whether the game can be balanced properly without at least some of the features marked with an orange "B" in the above linked list.

There is also the issue of inflation: one of the planned features is a price inflation system, and so the input numbers in the .dat files will necessarily be affected by how I choose to implement and calibrate that system: balancing on one basis will be futile if a different basis is subsequently used. There is also the question of the separation of vehicle running costs (that is, per kilometre costs) into two distinct parts: fuel and repairs (which would inflate at different rates), which would again require complete re-balancing of these once implemented.

However, the lack of a properly balanced pakset is, I strongly suspect, holding Simutrans-Experimental back. To increase the chances of more people contributing to the project, the game has to be more enticing for people, and a game that is not properly balanced lacks an essential element: in many ways, the balance is the game. It has been years since the balancing features were originally proposed and, to date, little or no progress has been made towards them because bug fixing or pakset extending or merging from Standard or adding more basic features (such as that relating to passengers walking to origin stops and passenger generation this year, and timing, point to point average speeds/journey times and related matters last year) have taken priority.

What is needed, I think, is a way to achieve a provisional balance sooner rather than later, and a way easily and quickly to adjust that balance as necessary as new features are added: after all, it is not just the features that I describe as balance critical that have the potential to affect balance and require adjustments: other features, such as railway signalling, have the capability to affect balance by affecting network capacity and adding new overheads (maintenance cost of signalboxes, etc.).

What I propose is as follows, and I should be very grateful for people's views on this proposal, especially (but not only) those with experience or knowledge of economics, finance and/or accounting. Firstly, it is necessary to implement the feature separating fuel and repair costs for vehicles: it will have no particular effect in the short term (existing running costs would be treated as fuel costs). This would probably be relatively straightforward. Next, a provisional balance could be achieved by extrapolating and interpolating data gathered in the snippet of relative pricing information thread. All the prices would be normalised to a value in real terms at a fixed point in time (1900 is, I believe, the conventional zero year for inflation calculations, so I will use that) and then converted using a fixed conversion rate from £ to Simucents. This would allow the inflation feature to be added later, which would work on the basis of all prices being normalised to a particular year. Then, or perhaps at the same time, another relatively simple feature could be added: global balance adjustment factors. For each category of price (for example, fuel costs for steam powered vehicles or the costs of building ways, etc.) there would be an index value set in simuconf.tab. The default value would be 100, and would act as a percentage. This would allow types of prices to be adjusted upwards or downward as a single block, whilst preserving the relationship between the individual prices of that type. Increasing the index for road vehicle purchase costs, for example, to 150 would increase by 50% the purchase price of all road vehicles, whilst keeping the price of each road vehicle compared to each other the same.

To allow this provisional balancing to work and not require being substantially re-done in the future, it is important to decide now in outline how balancing in principle will work, and in particular, the relationship between the individual prices of items in each category, the proposed inflation system and the proposed indexation system. What I propose is this: the prices of items relative to each other in each category will be based as closely as possible on real world pricing information. Similarly, inflation, when implemented, will be based as closely as possible on historical data for inflation rates of various types (cost of labour, cost of different types of fuel, etc.). The indexation figures, meanwhile, will be used as gameplay adjustment values, and calibrated to produce more or less realistic overall return on capital given a reasonably realistic network. Importantly, the global indexation will be totally separate from inflation: I had originally thought that it might be easier to use the inflation system to adjust these global indices, but on reflection this would not permit the necessary separation of historical modelling of inflation (which requires the figures to be fixed) and gameplay based adjustment of the global indexation figures (which will need to be mutable as game features change and we learn more about how the game balances overall).

This system as proposed will hopefully allow the value early work done to balance the various prices to be preserved as future features, such as inflation, cost of capital and usage based costs for ways and increased maintenance costs for more heavily utilised vehicles are implemented such as change the overall game balance.

As stated above, I should be very grateful for people's views on this topic and how best to achieve a good, playable, realistic and readily adjustable balance as efficiently as possible within the constraints of limited developer time.
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

I'd be cautious about adding further complications to an already very difficult-to-do balancing system.  I am working on converting some pak128 vehicles to Experimental and getting a correct balance is a significant challenge.  Multiply that by the sheer number of vehicles in pak128 and pak128.Britain and the task quickly becomes overwhelming. (cue image of pakset balancer staring blankly at the computer screen)

My intent is to create a complex system of formulas in a spreadsheet to be able to better balance vehicles and smooth out the advantages and disadvantages of each model.  The complexity of different combinations of vehicles, different cargo types, short vs. long haul, comfort, loading times, capital cost vs. operating cost, vehicle lifespan, typical way costs, etc, is huge.  Basing the figures off of reality may not help much as there is still a significant amount of reconciliation required to make them fit in the Simutrans world.  Prices may include local/federal subsidies/incentives, land grants, etc: costs that we need to remove in order to create a realistic economic valuation.  When, and if, I successfully implement a working spreadsheet model I will certainly share it with you.  The spreadsheets included in the source material were certainly helpful as a starting point.

I would be hesitant to add any further variables to these calculations without carefully considering whether we are truly adding a valuable feature to the game or not.  Many of the planned features I would put on the "nice, but" list that may make pakset balancing even more difficult and add little of value to the game.  Adding variable maintenance costs for ways and stations would certainly be of benefit to early gameplay, but again vehicles can be (and for the most part, are) balanced with this taken in to consideration.  You definitely don't want to make the game so complex that pakset balancing is nearly impossible for even an existing pakset like pak128.Britain, let alone anyone else wanting to convert one (you may end up being the only person who understands the system well enough to have a chance at achieving anything near a balance).  My initial plan is to significantly pare down the number of vehicles to make the balancing process easier to implement and test.
Current projects: Pak128 Trees, blender graphics

jamespetts

The plan that I outline is intended to simplify rather than complicate the task of balancing. If we only have to consider gameplay elements of balancing when adjusting the indexation figures, and can simply normalise and extrapolate from real life data for the individual vehicle costs and use historical inflation data for inflation rates, the actual number of variables that one has to consider for each individual input figure for the system is much reduced. Instead of having to consider the in-game cost of ways and the probable in-game revenue (and the multiplicity of factors that go into determining that) for each individual vehicle, with this system, setting the individual prices need only be done on the basis of historical data (which although takes more research is a cognitively much easier task), and those in-game factors are then automatically taken into account if the global indexation values are adjusted by trial and error to obtain realistic returns on capital over a given period. The advantage of this system is that it does not require a reduction in the number of vehicles to make balancing manageable, and should also have the best chance of obtaining a result that is realistic as well as playable: in other words, the incentives that a player will have to use any particular vehicle in the game will be as close as possible to the incentive that a real transport company would have had to use that particular vehicle at the relevant time in history.

Incidentally, none of the actual code features that I propose here should affect the ability to balance other paksets in a different way to what I propose, as the inflation feature, the global indexation feature and the split of fuel/repair costs for vehicles will have defaults that are identical to the present game without those features. The features that might very well affect balance more generally are those such as the removal of credit interest and the possible addition of a tax/dividend rate discussed elsewhere, intended to mitigate runaway profits that remove the challenge and incentive to do anything in particular for players who pass a threshold of successfulness.
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

The relative balance of vehicles against others of the same category is informed by normalised historical data, while the absolute cost is obtained through a function of that value and a set of parameters?

That would be a reasonable approach.

sdog

One more thing: with regard to pak 128. Britain standard balance, it would perhaps be a good idea to ask again if there is a desire to take some economic features from experimental into standard. For example independent monthly and running costs. With a few years extra experience with those features the view on them might have changed.  Well, in that regard I chose a poor example.

Vladki

Hello everybody,

when I read about splitting the vehicle costs to per km (fuel, maintenance) and per month (crew salaries), I thought that fuel costs should be separated from maintenance. But the change I had in mind is, that fuel costs are not per km but per Joule (or kWh, or liter of petrol, ton of coal,...). Empty train consumes less fuel than full, going uphill is more expensive than downhill.

I don't know much about the physics model in experimental, but for standard we could use a fuel cost formula for one tile (km) like this: cost*weight*friction. If the friction is negative (downhill), it should be set to 1 or some other minimum - diesel and steam engines use some fuel even if idle. Electric engines could have minimum of 0 or even negative as some of them can recuperate when braking. Maybe in experimental a more precise model could be done, that takes accelerating and braking into account as well.

I understand that this could complicate balancing and gameplay as well, but I had to share this idea. Maybe it would make noticeable difference only if one train was going fully loaded uphill and empty down and another one fully loaded downhill and empty up...

jamespetts

That is an interesting idea, but balance only actually works like this in the real world for electric vehicles: diesel vehicles idle as you point out, and the amount of fuel used when idling or running at low speed differs between different displacement values of engine, so that more powerful engines will use more fuel even at lower speeds.

With steam locomotives, the position is even more divorced from actual usage: the fire has to be burning at all times (and for many hours before the locomotive starts), and larger locomotives have larger grate areas and therefore are burning more coal even when not working hard. Steam locomotives do have to burn extra coal when they are working hard, but this varies wildly with the design of the locomotive, especially in early years, and I am not aware of any evidence as to the nature of the relationship.

Incidentally, speed is also highly relevant to the amount of power being consumed, but the relationship between speed and efficiency is an extremely complicated one: generally, all vehicles will have a speed of optimum efficiency, but that speed will differ greatly between different sorts of vehicles.

Finally, there is the issue of how this figure can be communicated with sufficient clarity to players in order to enable them to make informed choices and predictions of actual ownership costs based on it.
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.

Jando

I noticed something when comparing my current Simutrans Standard to my current Simutrans Experimental game. Since I believe it's relevant to balancing I took the freedom to revive this thread. :)


  • In Standard, about 75% of my monthly costs are running costs, roughly 25% is maintenance.
  • In Experimental it's the other way round, roughly 75% of the costs are maintenance, roughly 25% are running costs.

Personally I believe that Standard is more realistic in this split of the costs - but that's just a gut feeling, I don't really know anything about the topic. What I do know however is that the large percentage of maintenance costs causes problems in my current Experimental game (about 90% of revenue through freight transport). But changing industry demand has no effect on maintenance costs of course, only on running costs.

Practically I completely ignore running costs in an Experimental game, but I do everything I can to reduce maintenance costs.

jamespetts

Interesting - thank you for that. Which pakset were you using in Standard, and why do you think that the Standard split is more realistic?
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.

Jando

Hello James. And thanks again for your work. Much appreciated indeed.

Here's a picture showing the finance screens of both games: http://i.imgur.com/eXxmnG4.jpg

Upper picture is Simutrans Standard, pak128, no add-ons, only change to configuration is to increase station capture radius from 2 to 3 tiles. Lower picture is Simutrans Experimental. No change to configuration but to separate station capacities. Both games have been fast-forwarded 2 years, no changes to network during that time.

Three observations from me that might be relevant for balancing:

1. Costs during last month
In the Standard game Operation Costs cause 79.8% of the costs, in Experimental it's 30%. Accordingly maintenance causes 20.2% of the costs in Standard, in Experimental it's 70%.

2. Fluctuation of revenue and operational profit
The Standard game gets roughly half the revenue from passengers, the other half from freight. The Experimental game is about 90% freight revenue (it's year 1873). Therefore the Experimental game shows large fluctuations in revenue, due to fluctuating industry demand.

3. Assets
In Standard vehicles are expensive, in Experimental in 1873 vehicles are dead cheap. Thus the difference in assets.

As to what split is more realistic I'm in no way qualified to judge - but I'm fairly certain that labour and fuel costs play a big role for transport companies in the real world. And to me that sounds more like running costs than like maintenance.

jamespetts

Thank you for the information; but this seems on the face of it more like a Pak128 versus Pak128.Britain issue than an Experimental versus Standard issue; does Pak128.Britain behave any differently on Standard?
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.

Jando

Quote from: jamespetts on November 19, 2013, 11:18:06 PM
Thank you for the information; but this seems on the face of it more like a Pak128 versus Pak128.Britain issue than an Experimental versus Standard issue; does Pak128.Britain behave any differently on Standard?

I don't know much about Pak128.Britain on Standard, never had a somewhat developed game with it. But just from looking at the depots and the menus Pak128.Britain on Standard is balanced like Pak128 on Standard: rather cheap maintenance but high initial costs (for engines). Experimental is the other way round: high maintenance costs but very cheap engines.

Examples (from 1870-ish):
Monthly maintenance for railroad track in Pak128.Britain: 16-36 cr.
Monthly maintenance for railroad track in Experimental: 92-104 cr.

Experimental maintenance is 3-6 times the maintenance cost of Pak128.Britain.

Monthly maintenance for Macadam road in Pak128.Britain: 4 cr.
Monthly maintenance for Macadam road in Experimental: 16 cr.

Experimental maintenance is 4 times the maintenance cost of Pak128.Britain.

Costs for available rail engines in Pak128.Britain: 22.000-130.944
Costs for available rail engines in Experimental: 2.520-16.368

Engines in Experimental cost roughly 10% of what they would cost in Pak128.Britain. :) Your decision anyway about what you think the proper balance should be - I only thought to mention it when I noticed the difference between my Experimental and my Standard game.

jamespetts

Hmm - interesting. I have not intentionally rebalanced the pakset, apart from the revenues, but the two might have drifted apart over the years. I shall have to consider this balance in more detail when I come to do full balancing. Thank you for your input!
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.

Banksie_82

At least with respect to the capital cost of vehicles (actually with everything, but with everything else it is probably warranted), could it be that Ex scales the cost with the m/tile setting?

jamespetts

There are quite a few costs scaled by meters per tile, yes.
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

To get a better realistic feeling when playing EXP we need:


- Better balance between price versus maintenance of ways and buildings. As is prices are way to low and maintenance to high. The way maintenance is calculated makes it allmost impossible to play with a
  high BpM setting. If you play on BpM=25 this problem is 8 times higher than on BpM=22.
  I spend a long time to find out a realistic solution for the prices of way-items. I even made a calculation of the price/km of Macadam-road. Believe me you can't afford that. In a solo-game you are the only    player and it would be not logical that you have to pay that much for a way which is in fact public.
May be a better approach is that you pay f.i. 10% of the real cost to the government, which gives you the right to decide where the way will be laid and in what quality.

Rail-price.
In my next scenario scenario I will try this out with the formula for railways: Speed*Load*10 for track, *100 for bridges and *1000 for tunnels. (Load= axle-load)
There will be at least 3 cheaper alternatives. One track with speed 10km/h, one with 30km/h and the last with 60km/h.
The 10km-track can be used as sort of a prospector-track; the program can do the way-finding in difficult terrain without the risk to go bankrupt.
  Example: One km track 90/17 cost now 450 Cr and is going to cost 15300 Cr
Rail-maintenance.
  Prices for high speed/load railways are high; very high.
  Reason for that is the fact that they are designed to withstand the high forces related to the high speed/load.
  IMHO it does NOT mean that you have extra high maintenance-costs as are in the existing PAKs.
  An approach could be: Maintenance-cost per year is 10% from new-price. Attention: this is per real year and 720 hours/month. So roughly at BpM=29.
In the example from above it would mean 1530 Cr/real year.  At BpM=22 this would be 1530/128= ~12 Cr/year or 1 Cr/month.  Maintenance as is 57,60. So a huge difference.


This way of calculating is only valid for constructions where not people is working in.


For buildings like stations, depots, etc we realy need aninflation[size=78%] [/size][/size][size=78%]-factor in the main-program. A steady factor of 3% could do for starters.[/size]
We not only need that for maintenance costs but also on the earns side. The income/km is now constant even in a scenario of 200 years.
If we have such a factor the fixed cost of a building consist of building-maintenance and labor-cost.


To be continued.
Ad van Gerwen

jamespetts

AvG,

thank you for your feedback: that is helpful. An inflation system is indeed planned, and will make a real difference to balance, I think.

As to the figures that you give, are they based on real world data? If so, what are the sources of those data?
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.

greenling

Hello Jamespetts
I have remark in pak128 britain ex 0.9.0 that sometime the time how i can buy Vehicle in the Depot to long it.
I think that shorter buyingtimes the gameplay interessant make.
Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!

jamespetts

I'm not sure what you mean by "how I can buy vehicle in the depot to long it". Can you explain?
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

James,
At the moment I have no info on cost/km of road or rail. The only info I have is for smallscale projects with prices per square foot.
The price I mentioned in my previous entry is meant to prevent the player of reckless road/rail construction. You should get the feeling that you earned a traject because you worked for it.
Ad van Gerwen

jamespetts

I see - thank you for the clarification. That is helpful.
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.

zook2

I'm probably flogging a dead horse here, but I don't see the point of staying as close as possible to historical data (despite the "Sim" in "Simutrans"). In my (largely uninformed) opinion, it consumes lots of developer time and is horribly hard to balance. If done wrong, it makes the game unplayable from the start. If done right, almost every railroad company goes bankrupt in or around 1960. I mean, you're trying to simulate *four centuries* of passenger and cargo transport.

Maybe that's a bit harsh - I admit I haven't read all the discussions since 2011 (when I last read the forum) but what's the long-term goal of SimEx? If it's playability, then historical values don't seem to serve the purpose.

jamespetts

Actually, it is easier by orders of magnitude to use historical values than to guess or try to calibrate from scratch, as the relative prices of everything can simply be researched rather than calculated. There are such a vast number of variables that trying to calibrate it without historical data would be an unimaginably complicated task (where would one even start?).

The idea is actually to use historical prices to determine the relative price of different things of the same type (the purchase cost of steam railway locomotives, for example), and as a starting point for the balance of different things against each other (the purchase cost of steam railway locomotives relative to the cost of building railway tunnels, for example), but be able to adjust those costs in block against each other based on what actually works in the game (and by "works", I mean well-run companies with realistic infrastructure having a return on capital that approximately matches that which companies with that sort of infrastructure would actually have had), and then further modify them over the 300 years of play based on different sorts of inflation.

But your post raises an interesting theoretical question - in a simulation game, what exactly is "playability" if not, within the limits of what is actually within the player's control and what is actually modelled in the game, the player's actions in the game having as similar effect as practicable in the game to the effect that those actions would have had in reality?
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.

zook2

Quote from: jamespetts on December 26, 2013, 01:33:42 PM
But your post raises an interesting theoretical question - in a simulation game, what exactly is "playability" if not, within the limits of what is actually within the player's control and what is actually modelled in the game, the player's actions in the game having as similar effect as practicable in the game to the effect that those actions would have had in reality?

Ahh, therein lies the rub. That historical approach is viable if all relevant elements are modeled more or less correctly. But if, as in a complex transport simulation, one or more elements are not, because of program limitations, then the whole result is distorted and a results-based approach might be better suited.

Let me try and find an example. In my current game (seed 45, 1200x1200km, 1860, land masses separated by seas), I need to connect a number of towns to ports as feeders for my shipping lines. Coaches don't work for connecting towns because of the waiting time problem and because they mostly fail to overtake a bunch of 7 km/h carriages on country roads. So I could really use a lot of passenger steamboats for river or canal travel. Let's see:
- a shipyard costs a horrible amount of money, both to build and upkeep (sounds realistic)
- steamboats can't enter the open seas (fine)
- it's practically impossible to connect all rivers and canals on a "continent" (fine)
--> I'd need to build a shipyard for 28.000 in order to build four or five boats, which would make less money than the shipyard's upkeep alone costs me
---> I can't use steamboats. The boats themselves might be economical, but the necessary infrastructure is not. The result is unrealistic.

And that's because there is one factor that is unrealistic and breaks the simulation: if the Bumborough Steam-Ferry Ltd. needs four boats, it doesn't start by building a shipyard. It simply orders them at a private shipyard and tells them where to deliver them. In simulation terms, the boats would just magically appear on the river after a while.

jamespetts

The answer is not to abandon all attempts to make the simulation anything near real because there are a few problems: the answer instead is to apply specific solutions to specific problems. The waiting time issues have been discussed elsewhere (the next major release, with its abolition of distance ranges, should make a substantial difference here), and there is also a plan to have a separation of shipyards and boatyards, permitting canal and river boats to be built at a much more inexpensive yard than sea going ships, which, although I do not have historical data to hand, strikes me as probably realistic (it is highly unlikely that the place where canal boats are made would need to be anywhere near as expensively built as a place where ocean-going ships are made).

As to the 7km/h private carriages, I wonder whether those are too slow if they are much slower than the stage carriages, or whether, alternatively, the overtaking settings are too conservative. How many of these do appear on the roads in the 18th and early 19th century?
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.