NewGRF balancer

[555gln22]

Now we have the ability to run multiple newGRFs of the same type of vehicle, I've come across a problem. Many of the GRFs have varying prices, running costs and capacities for similar vehicles.

For example, the EMC Doodlebug, which appears in both the NARS and the Canadian Trainset.

In the US set, the stats are:

cost: 16,406
weight 41t
speed 60mph
power: 250hp
Max TE: 41KN
Capacity: 32 Passengers

In the Canada Set, the stats are:

cost: 44,531
weight 47t
speed 55mph
power: 500hp
Max TE: 51KN
Capacity: 25 Passengers


Now obviously it would be too much of a pain to get every GRF author to make their trains all the same as everyone else's, it's not desirable anyway as often there's a specific gameplay reason for it.

What I was wondering was whether it would be possible for OpenTTD to take a look at each GRF, establish an average price for engines (for trains), and an average price for wagons, work out the price multiple for each train in that set, establish a global average for all loaded GRFs, and then multiply that global average for each train?

for example:

Set A

Loco 1: 20,000
Loco 2: 60,000

Average price: 40,000

Loco 1 Multiple: 0.5
Loco 2 Multiple: 1.5

Set B

Loco 3: 100,000
Loco 4: 200,000

Average Price: 150,000

Loco 3 Multiple: .67
Loco 4 Multiple: 1.33

Global Average = (total Set A + Set B/ total number of locos) = 190,000/4= 47,500

New Loco 1 Price = 47,500* .5 =23,750
New Loco 2 Price = 47,500* 1.50=71,250
New Loco 3 Price = 47,500* .667=31,666
New Loco 4 Price = 47,500* 1.33=63,175

That way all the GRFs should be somewhere around a similar pricing model, which would mean you could play lots of different GRFs in the same game properly.

Thoughts?

[michael blunck]

What I was wondering was whether it would be possible for OpenTTD to take a look at each GRF, establish an average price for engines (for trains), and an average price for wagons, work out the price multiple for each train in that set, establish a global average for all loaded GRFs, and then multiply that global average for each train?

Correct prices and costs are essential for set balancing. Changing them would result in buggy behaviour.

If OTTD should like to change it, why shouldn´t it change other stats like power, speed, tractive force, etc., pp., in the same go? To get a more "unified" game-style?

Now we have the ability to run multiple newGRFs of the same type of vehicle [...]

No, we don´t "have that ability", see above. Possibly you´re refering to OTTD´s "multipool feature", which isn´t a feature but simply a bug.

regards
Michael

[555gln22]

What I was wondering was whether it would be possible for OpenTTD to take a look at each GRF, establish an average price for engines (for trains), and an average price for wagons, work out the price multiple for each train in that set, establish a global average for all loaded GRFs, and then multiply that global average for each train?

Correct prices and costs are essential for set balancing. Changing them would result in buggy behaviour.

If OTTD should like to change it, why shouldn´t it change other stats like power, speed, tractive force, etc., pp., in the same go? To get a more "unified" game-style?

Now we have the ability to run multiple newGRFs of the same type of vehicle [...]

No, we don´t "have that ability", see above. Possibly you´re refering to OTTD´s "multipool feature", which isn´t a feature but simply a bug.

regards
Michael

As I said, I know that having the original prices set by the developer of the GRF is important, and a good thing. However, I would imagine that quite a lot of people do like to have more than one GRF for trains/trucks/planes/ships loaded at the same time (I can't seem to find the "multipool feature" in the bug tracker, but if it is it's a mighty useful bug ) and I thought it would be nice to have an option to place the various GRFs on a similar cost footing to even out the differences between the various GRFs.

Obviously I'm not suggesting this should be standard, but it would be a useful tool IMO.

[Eddi]

that is a completely impossible task, as it involves reading the minds about what the grf designers wanted to achieve.

there are two major flaws involved here:

1. the "multipool" feature is not a magical "make everything work together" feature. it is merely the tip of a deeper underlying flexibilisation of the whole fixed and arcane "engine ID" TTD-ancientism.

2. the grfs still have to be specifically designed to interact with each other, everything else does not make any sense. with every component based system, the composition of components is not as free as is often advertised. the components may be trivially compatible on a low protocol level, but they also have to have a common interface on the high protocol level, otherwise the outcome of the composition is complete garbage. combining e.g. the DBSet and NARS makes as much sense as combining PBI and ECS. they can be loaded together, because the low level protocol (NFO, pool, etc.) is prepared for it, but the gameplay effects are not combinable, because the sets go by totally different design principles (high level protocol).


coming back to your example calculation, which is, of course, complete nonsense.

let's assume for the sake of argument, that the DBSet came in freely combinable "epoche" sets
epoche 1: 1835-1920 - early private railways and Länderbahnen - very slow, very cheap engines
epoche 2: 1920-1950 - Deutsche Reichsbahn Gesellschaft - unification of designs, increasing effectivity and speed, moderately priced steam engines, highly priced electric engines
epoche 3/4a: 1950-1990 - Deutsche Bundesbahn - rebuilding after the war, moderately priced engines, but prices adjusted for inflation, traction change from steam to diesel/electric, international traffic and early high speed engines
epoche 3/4b: 1950-1990 - Deutsche Reichsbahn - east german equivalent to the above
epoche 5: 1990-today - Die Bahn - reuinification, privatisation, high speed lines, high priced engines (ICE)

now, with your pseudo-balancing "wooden hammer" calculation, this would make the ICE part of the set of the same pricing range as the Länderbahn part, which obviously makes the set LESS balanced

[555gln22]

It's only a suggestion...

[PhilSophus]

IMHO, it would be nice to have a per-GRF copy of base costs that are clearly related to vehicles which you can find out which NewGRF defined them (i.e. running and purchase costs. Base costs for building, terraforming... are not of this kind).

This would solve most of the issues. I know, some vehicle GRFs also fiddle with some non vehicle-related base costs (e.g. mb's DBSetXL), but this can easily be fixed by loading a base cost modifier GRF after it. I think, there are also some global variables defining sprite offsets, which can be set differently by NewGRFs, so maybe those should get a per-GRF copy, too.

Now we have the ability to run multiple newGRFs of the same type of vehicle [...]

No, we don´t "have that ability", see above. Possibly you´re refering to OTTD´s "multipool feature", which isn´t a feature but simply a bug.

Sorry, that you don't have , we do . And it's working quite well with most road vehicle sets (I found only two modifying base costs) and with other vehicle types it could also work equally well with my suggestion above.

[DJ Nekkid]

personally do i think that we should find a "good basis" on where we put the cost modifiers so that it can suit everyone. After all, we do have three different running cost bases that can be switched around.

A steam engine can use the electric base and vice verca.

Steam based cost could be, for example, from 0 to 25k running cost
Diesel based could be 0 to 100k
Electric based could be 0-500k

or something similar.

[michael blunck]

[...] Possibly you´re refering to OTTD´s "multipool feature", which isn´t a feature but simply a bug.

[...] it's working quite well with most road vehicle sets (I found only two modifying base costs) and with other vehicle types it could also work equally well [...]

Well, I´ve never argued against having more vehicles IDs. Nor did I argue against the potentiality to use two (or more) train sets simultaneously. There are good reasons to do so, e.g. in cross-border scenarios. However, OTTD´s current "multipool feature" lacks everything what a proper implementation would need to offer, i.e. a clearly defined interface for the vehicle sets.

There have been proposals enough how to improve that feature (or, better phrased: develop it in the first place) which may be found by using the forums´ search function.

regards
Michael

[AndersI]

Steam based cost could be, for example, from 0 to 25k running cost
Diesel based could be 0 to 100k
Electric based could be 0-500k

Are these numbers based on anything in real life, or taken 'out of the air'? Or do you need them to be like that for game balance?

When early Swedish railroads were electrified, the decision was based on (at least) two facts:

- Electrical engines could haul longer trains than Steam.
- Electrical engines had about 1/4 of the Steam running cost. I don't know if rail damage is included in that figure.

This was enough of a gain to support electrifying the iron ore railway(s) in the north of Sweden as early as c:a 1910.

Diesel is more difficult to get right, as oil prices has fluctuated a lot during the years.

Anyway, I think the running costs should be in the order Electric < Diesel < Steam if they are to be realistic.

I'm sure MB can correct me if I have read the numbers wrong in the book where I found them - no reference, sorry, the book is back at the library, and I don't even remember which book it was.

[michael blunck]

Steam based cost could be, for example, from 0 to 25k running cost
Diesel based could be 0 to 100k
Electric based could be 0-500k

Are these numbers based on anything in real life, or taken 'out of the air'? Or do you need them to be like that for game balance?

Hehe.

When early Swedish railroads were electrified, the decision was based on (at least) two facts:

- Electrical engines could haul longer trains than Steam.
- Electrical engines had about 1/4 of the Steam running cost. I don't know if rail damage is included in that figure.

Rail damage should be far less for electric locomotives, depending on the type of drive. The main problem with steam locomotives were unbalanced masses, mostly for two-cylinder engines. Some of them were notorious for giving rise of rail damage. Even for early electrics with only one large series electric motor, masses could have been much better balanced. And when direct axle drives were introduced, there was (nearly) no rail damage at all from this reason.

This was enough of a gain to support electrifying the iron ore railway(s) in the north of Sweden as early as c:a 1910.

It should be obvious that different traction types have different cost depending on the special situation in the diverse countries. Speaking of early electrification, Switzerland comes to mind with a nearly unlimited availability of cheap electric power from hydroelectric power plants. OTOH, coal had to be imported, and especially during the war years, prices for coal had been risen significantly.

Diesel is more difficult to get right, as oil prices has fluctuated a lot during the years.

A good example for diesel usage (or non-usage) would be the former East-German Railway.

Anyway, I think the running costs should be in the order Electric < Diesel < Steam if they are to be realistic.

Well, it depends. There are sources claiming steam in general must have been cheaper than diesel (dieselization in US depending largely on a big publicity campaign), and early electrics were not so easy to maintain than we think today.

And though I´ve been successful in collecting some cost data (very hard, BTW), there´s no general conclusion possible, except for single engines.

O/c, today, usage of steam is very expensive, simply from the fact that it´s "exotic" today. But o/c, that had´t been the case in its own era.

regards
Michael

[ostlandr]

After reading this thread, I'm not sure GRF balancing is something we want to do. But I did have a few ideas on the subject. I have done a lot of this kind of thing with assigning points values to WW2 military units from various countries for balancing war games. Each player is given a set number of points to "buy" their units, with the hopeful result that a 2,000 point German force is an even match for a 2,000 point Soviet force, even though the Soviet force is about twice as large.

To me, it's mostly about horsepower/hours. (BTW this is the unit that railroads use when they share locomotives.) Speed also enters into the equation, as this improves station ratings. But tractive effort is what moves the heavy loads. Less reliability means fewer horsepower/hours per game year available.

So:

Base price = Horsepower x 10 plus Speed x 5 plus Tractive Effort, all multiplied by the reliability percentage.

Examples (fictional):

Early diesel, 1500 hp, speed 60 mph, 200kn TE, 80% reliability

{(1500*10)+(60*5)+200}*0.8= $12,400.

Modern diesel, 4400 hp, speed 75 mph, 500kn TE, 95% reliability

{(4400*10)+(75*5)+500}*0.95 = $42,631

I just picked these numbers out of a hat, but with some discussion we might be able to come up with a workable formula. Changing the relative weights of TE, HP, etc. is easy in a spreadsheet.
This is how we did it with AFVs (tanks) - we factored in mobility (speed), firepower (range and penetration of the main gun) and protection (armor thickness) and after a lot of tweaking and testing we got it nailed down. And it works in the game and matches the historical records: "A Tiger was a match for five Shermans, but the Americans always had that fifth Sherman."

[555gln22]

As I said, it's just a suggestion. Regardless of which way round it gets done (and I think I prefer your way ostlandr) it would be really nice to have the option to override the cost/running cost set in GRFs.

[DJ Nekkid]

i think you guys may have misunderstood me.

the point was; steam engine running cost can be pointed to electric, and vice verca.

[michael blunck]

i think you guys may have misunderstood me.

the point was; steam engine running cost can be pointed to electric, and vice verca.

It´s quite irrelevant how those numbers would be generated. You could even use those from ships or planes. The OP´s point was that he felt a need for some form of "averaging" of cost numbers.

After reading this thread, I'm not sure GRF balancing is something we want to do.

No, definitely not.

[nevertheless.. ]
I just picked these numbers out of a hat, but with some discussion we might be able to come up with a workable formula.

I have my reservations to the whole idea:

- set designers might want to maintain the exact numbers they put into their sets, not any "adjusted" numbers,
- if we´ll have something like this for cost numbers, we´ll soon have something other for speed, power, TE data, ..., and even graphics. So, what´ll be left from the idea of a "vehicle set"?

regards
Michael

[555gln22]

OpenTTD already does do some of this (there's an option to remove wagon speed limits, for example) so I don't see why it would be too much of a concern. It wouldn't be compulsory at all.

[michael blunck]

OpenTTD already does do some of this (there's an option to remove wagon speed limits, for example) [...]

Newgrfs are able to check the state of the wagonspeedlimits switch and base some decisions on it. E.g., it might even quit if it is set wrong. If OTTD doesn´t allow the newgrf to work this way, it´s clearly a bug in OTTD.

regards
Michael

[andythenorth]

I see the point of this suggestion. For example I am balancing the HEQS road vehicle set at the moment. That set is intended to be used with other RV sets, and currently balances against eGRVTS. When/if the North American Road Vehicle Set gets done, I'll also want to balance against that. Then what about the German Road Vehicle set? And then other new sets?

It's tricky. (By the way, the key properties (for RVs) are running cost, purchase cost, speed, and capacity).

However as a grf author, I think it's nonsense that the game could balance grfs automatically. It would be easier for grf authors to just talk to each other and agree what ranges to use for the key properties. Guess what - some of us do

grf authors could adopt a formal system, with bands or classes of vehicle, but I would really only support this if it saved me time creating grfs by giving me ready-to-use values for properties. Creating grfs is already time consuming.

Another option is that within the grf, the key properties could be controlled by parameters, or adjust dynamically depending on the other sets. However this would be an absolute pain in the ass to code: I have lots of hard-coded strings in my grf informing the player about capacities etc); it would also be complex and more likely to contain mistakes. It also isn't possible to adjust all properties dynamically in the current implementation of newgrf.

A second option, although long winded: players can use use grf-codec to decode the grf, change the properties to those of their choice, and then re-encode. Means learning enough nfo to understand Action 0, but a little learning never hurts. Could be some copyright/licensing issues for some grfs with this approach, but for anything released under the GPL it would be fine.

cheers,

Andy

[555gln22]

I sort of went over all of those ideas in my head first, and then thought of a couple of things.

1)As has been mentioned above, GRF authors often have a good reason for setting parameters the way they have.

2)NewGRF is independant of OpenTTD, so changing it to have a set of "global modifier constants" would be a big issue.

3)Cracking open and altering GRFs by hand is fraught with the issues you mentioned.

As far as I could see the only other place that you could balance the GRFs without altering the GRFs themselves would be as an option in OpenTTD which would be off by default.

[ostlandr]

My idea was to figure a way to take the TE, horsepower, reliability, etc. that the set designers put in, and use them to generate purchase costs. For example, if somebody wanted to use the UKRS, DB and SNCF sets together for a Europe map, with each player representing a different nation. Of course the vehicle sets have three different dev teams and wildly different purchase and running costs. But using multiengine pool and switching this option on would override the original costs and recalculate based on the vehicle stats. This way, the player using the SNCF set wouldn't have an unfair advantage because the purchase and running costs for that set are lower.

Plus, we could add a paramater to the SNCF set that says "use DB set after 1940."

i think you guys may have misunderstood me.

the point was; steam engine running cost can be pointed to electric, and vice verca.

It´s quite irrelevant how those numbers would be generated. You could even use those from ships or planes. The OP´s point was that he felt a need for some form of "averaging" of cost numbers.

After reading this thread, I'm not sure GRF balancing is something we want to do.

No, definitely not.

[nevertheless.. ]
I just picked these numbers out of a hat, but with some discussion we might be able to come up with a workable formula.

I have my reservations to the whole idea:

- set designers might want to maintain the exact numbers they put into their sets, not any "adjusted" numbers,
- if we´ll have something like this for cost numbers, we´ll soon have something other for speed, power, TE data, ..., and even graphics. So, what´ll be left from the idea of a "vehicle set"?

regards
Michael

[Zephyris]

I have often thought about a possible role for calculated costs for a vehicle, especially as part of the fabled "balanced economy". In theory it would be easy to calculate the potential profitability of a vehicle for a particular cargo on a route of standard distance and create an arbitrary formula to assign running, purchase and refit costs from that. Stumbling blocks will be things like articulated vehicles or vehicles with complex refits which also change capacity, speed, etc. and trains whose profitability is determined by their wagons, but it could be possible...