Topic: PAK128 Pricing & Balancing - Discussion

[DirrrtyDirk]

Ok since we need to get started somewhere, somewhen and somehow...

... I decided that "right here", "right now" and "whatever comes out of this" are the best answers to these questions. 


Now, the old system was very, very complex - as even things like tractive power and speedbonus were core items of the basic calculations. With the new, table-based speed bonus system, I hope we can get things easier than this.

...

BRAIN STORMING:

So for the beginning we will ignore all these special & complex things like bonuses, etc. and just do it simple.

Step 1: Calculate the max. income (vehicle fully loaded) per km(=tile) a vehicle can generate (according to the freight-types transport fee from the goods definition).

Step 2a: Calculate a balanced RunningCost for that. I think other paks do it this way, so might also try it: we could figure out a load percentage that marks the point above which a vehicle will be profitable (or will generate losses if below that).
Of course we have to consider the fact that most freight vehicles will drive empty on 50% of the way, while passenger and mail usually carry loads both ways.

Step 2b:
We also have to include some margin in 2a that will be able to pay all the required infrastructure (like roads, tracks, catenaries, bridges, tunnels, stations, etc.)

Step 3:
Purchasing price... I think that one is actually quite freely adjustable, but we could develop some kind of "guide line" balanced on net income of each vehicle - i.e. determining "how long" it should take until a vehicle pays itself from its own net income.


Open problems so far:
- solution for vehicles that only pull others but have no payload themselves (loco's, trucks)
- implementation of speed bonus
- ... probably several more - but I'm not going to do this all alone. 


So, now... YOUR ideas, comments and solutions are required...
EDIT:

I had another look at the old Excel sheet - and it seems that load percentages were also used as reference in pak128 (Pass. 75% and freight 48%). And I got quite a number of ideas from it - let's see how many I can get to work in my version. 

[VS]

So, first - about trains. Calculate whole convoi of one loco and say six wagons. Take wagon prices and rc's as fixed, then substract from the resulting number -> the rest must go to the loco. Obviously wagon<<locomotive must be true in both aspects.


Second, I wouldn't remove at least speed. Speedbonus directly affects revenues, and thus the whole calculation. You can't drop it completely. Also with power value increases - at least for trains this holds absolutely true.

[DirrrtyDirk]

I've started with the easiest: EMU's/DMU's. I'll have a look at conventional trainsets later.

Trying to orient myself on how Napik did things in his Excel sheet - starting with the simple functions and getting into the more complex stuff later.



Now, speed bonus...

The problem with speed bonus, is that it is just a bonus. So we should make sure that vehicles can generate profits even when they do not get this bonus...or not? If we do that, then vehicles which qualify for the bonus, will simply receive some %'s more money. If we require the bonus for being able to make money at all, that's... well that's not what I'd like speed bonus to be, if I'm honest. And that's going to be much more complicated as well.

[VS]

That makes sense. Now that it does not have to be "loopbacked" with the other values, it should be actually possible to make it a true bonus, not some degenerated threshold.

So, the task is easier...

Err, does it act always strictly as a bonus? I think not. ****.

[DirrrtyDirk]

All I can say is: we need to get things much more simple than what napik did. Even on the "Waggons" sheet (that's not even using the macro!) there are so many calculatons and references between dozens of cells...

I don't think I will ever understand it all, unless I do a printout for every cell...

So let's just hope we can manage to get things easier... :-\

[VS]

With speed bonus read from external table, you can easily skip hundreds of calculations required to determine it from available vehicles…

The main problem with spreadsheet "programming" is that you have very limited capabilities for actual computing. You can't expand the code beyond that boundary no matter what...

[ariarinen]

What about having classes for different types of vehicle, so older vehicles should be have a lower purchasing price, but much higher running cost and the opposite for newer, plus maybe a 30-50+ % profit margin for the back trip and new investments.

Maybe limit small planes form flying longer distances or by making them expensive on longer routes.

[DirrrtyDirk]

@VS:

Yes, but speed bonus is not all that makes Napik's Excel sheet complex. There are quite a few other factors that are also used for calculations - and it's almost impossible for me to sort it all out.

By the way, Frank gave me his balancing sheet for pak.german - I hope that will be easier. 

---

What about having classes for different types of vehicle, so older vehicles should be have a lower purchasing price, but much higher running cost and the opposite for newer,

If that is wanted, it could be done after all other calculations are finished. After all it's just multiplying cost / running cost by some factor that depends on the intro_year. Shouldn't be too difficult - question is do we want that? But even so - that's of no relevance yet.

Maybe limit small planes form flying longer distances or by making them expensive on longer routes. 

That's impossible to do in a pak set. To get that working, simutrans code would need to be changed - and that
a) belongs into another forum section
and
b) requires other people to do.

[VS]

By the way, Frank gave me his balancing sheet for pak.german - I hope that will be easier. 

Sounds good.

[Zeno]

Some ideas (just ideas, no implementation):
I think locos running cost should have a relation with its power and speed (as they can't be directly tuned to goods capacity); maybe not a full dependance, but a percentage would be fine.
For purchasing prices, I would take as reference some "medium" benefit or "typical" benefit and calculate then a number of years to get it paid back (f.i., 6 years for bus/truc, 10 years for locos, 15 for planes/ships).
I can help on excel formulas & tests, lists and other similar stuff. On-game testing would be harder for me 

[ariarinen]

Some ideas (just ideas, no implementation):
I think locos running cost should have a relation with its power and speed (as they can't be directly tuned to goods capacity); maybe not a full dependance, but a percentage would be fine.
For purchasing prices, I would take as reference some "medium" benefit or "typical" benefit and calculate then a number of years to get it paid back (f.i., 6 years for bus/truc, 10 years for locos, 15 for planes/ships).
I can help on excel formulas & tests, lists and other similar stuff. On-game testing would be harder for me 

I like that,
Pay back is a flawed model, NPV would be much better, so if its a positive value you should buy that thing negative buy some other.
Formula is CF/(1+i)^t   i=15 % (interest)  and t=time CF= cash flow and the first cf is the purchasing price. 
 

[DirrrtyDirk]

@Zeno:

The difficulty is that both, a vehicle's income and running costs are based on distance - not time. And in-game speed is not directly related to any tile/min rate. (IIRC Hajo just had a certain animation speed, watched in on screen and then decided "that looks like xxx km/h") So it's not easy to calculate a typical benefit over any amount of time... We'd need a tiles/sec or tiles/min rate for any given speed (the factor beween real time and ST time can be calculated). There is some value for that in Napik's sheet, too - but I'm not sure if it's correct (any more).

Now, don't get me wrong: the general idea isn't difficult to implement - I think I already did that. It is just that I used some "artificial" factor that is not really connected to a specific amount of time, just something that produced about the same price as the old system (taking vehicle speed into account) - but I have no idea how many months/years of time in ST that number corresponds to at the moment. But fortunately, changing a fixed number to a formula (once we have it) is no problem at all in Excel. 


@arianen:

We are trying to get this system as simple as possible, not as realistic as possible. And when I look at your proposal, I looks just the opposite to me.

[ariarinen]

@arianen:

We are trying to get this system as simple as possible, not as realistic as possible. And when I look at your proposal, I looks just the opposite to me.

Payback Period = A+(B/C)
A = Years before final payback year
B = Total to be paid back
C = Total Paid back at the end of final payback year.

Is just as simple in my eyes  

How about average speed form the speedometer, that would be easy to calculate 

[DirrrtyDirk]

Err, does it act always strictly as a bonus? I think not. ****.

Actually I just found out that it works a bit different from what I thought.

Apparently speed bonus works like this:

You have a given speed for a year - let's say e.g. 100km/h. If a vehicle has speed=100, it gets exactly the amount of money defined in the goods files (e.g. 0.05 cr / km / passenger). (In reality it's just 0.04666... but let's make it easier by assuming that it's exactly 0.05).

For every km/h more (or less) than that, 1/10 from the given speed-bonus % is added (or subtracted) from that (e.g. 18%/10=1.8%) - so if your vehicle has a speed of 200km/h (=100 above bonus speed) it gets 0.05+(100*0.05*0.018)=0.14 cr / km / passenger, or if has only speed=50 (50 less than bonus speed) it gets 0.05-(50*0,05*0.018)=0.005 cr / km / passenger.

So, unlike I thought, it must already be included in the basic calculations.

[Zeno]

The difficulty is that both, a vehicle's income and running costs are based on distance - not time.

Maybe we could base it in a couple or three parameters not calculated but really tested and extract a medium value. Let me explain. For instance, we could calculate fore each loco how much income do they produce transporting a "standard" product (maybe books or canned food) across 30 sqares with 4 wagons; then repeat with 8 wagons; maybe repeat with cheapest and most expensive goods; then extract a medium value.

I think we won't need a *real* medium profit, but a value representing the ability of each loco to make money. And it's as simple as test & write down 

[Zeno]

I've got some ideas for locos RC calculation, at least usable for pulling locos (no cargo). I've been thinking of factors which can make a running cost increase or decrease, and I get to these ones: power, speed and type (electric,steam...). I thought about calculating RC with these values, and leave other factors to the purchase price. So I played a little with some numbers, and got some formulas:

RC = POWER * GEAR / SPEED / 2  is giving me "reasonable" numbers (2 to 10 most, 10-16 some, +16 a couple).

It's soooo easy to calculate 

I can think of two coeficients to apply:
1) Multiply result by a bonus-speed coef (vehicle speed vs. bonus speed of launch year in %)
2) Multiply result by a bonus-power coef (vehicle power vs. power "normal" value of launch year in %)

We could use these coeficients to calibrate a little more the values. Also comment that we could apply to all locos, and then charge to locos which can carry goods by themselves to the purchase price.
Edit (1): I forgot to introduce WEIGHT in the formula... it should be dividing the result... I'll gonna play a little more with numbers 
Edit (2): Following this way of thinking/calculate, a "constant" could be invented for each cargo type, and used to calculate all vehicle RCs using an expression like VEHICLE_TYPE_RC + CARGO_RC, calculating the vehicle RC using only its physical parameters, and adding aditional RC value for the cargo it carries using capacity, type... :

[prissi]

Did you look at the excel sheet for pak64 in the sourceforge SVN. That is like I did rebalance pak64 ...

[Zeno]

Did you look at the excel sheet for pak64 in the sourceforge SVN. That is like I did rebalance pak64 ...

No, I was looking/using the old excel from pak128... but I think your name appears somewhere in it anyway
I'll take a look to that excel from SVN, thanks!

[wernieman]

@Zeno ... so at the moment you are the person, how make a rebalance?

[Zeno]

Can't find the excel that prissi talks about... anyone knows where to find it? 
Edit:
Found something... cars.xls into vehicle folder!
Edit2:

@prissi: I don't know how much I really understand of it, but it seems to be a similar calculation to mine... I think you used a typical cargo to calculate revenue, while I proposed to use a constant to simulate that itself (which actually is getting to the same thing).

[Zeno]

@Zeno ... so at the moment you are the person, how make a rebalance?

Mmmm... actually I don't know exactly what are you asking 

But anyway, IMHO we should decide which are our objectives:

• balance vehicle data?
• improve playability? 
• develop an easy way to get vehicle params? 
• make a guide on how to create vehicles so they can fit into simutrans engine? 
• all of the previous options?

Then decide how to deal with the problem in a simple way, and develop it till we decide is enough.

Edit: Is goods pricing pak-dependant? And if yes, pak128 pricing & balancing includes goods income balancing?

[VS]

First, a way to calculate something must be created, implemented and documented.

Then use that to balance 128 - specifically vehicle data and goods (if needed) but maybe also industries.

[Zeno]

First, a way to calculate something must be created, implemented and documented.

IMHO, a vehicle's running cost should not depend on its cargo type or capacity, but its physical values (vehicle type, engine type, weight, power, speed...); another thing is if this way of thinking can (or should) be applied to simutrans, or not.
Anyway I think that should be the way to calculate engine's RC, just using physical parameters, and make it as easy as possible.

[VS]

So far three people expressed some kind of interest: DirrrtyDirk, Zeno and wernieman.

It's up to you three to come up with something. If you let me do it, I would probably make some horrible program in Python

[wernieman]

Sorry, at the moment I look to cross-compiling to mac......

[Zeno]

Well, first of all I'd like to say I prefer to spend my time on doing this than in making addons, as long as I consider this much more important. So, what about designing a route planning for this?
I would say first we need to decide which parameters will be involved in the balancing, and what do they affect to.
Just to begin somewhere, I think we should consider we may change this three things: vehicle purchase prices & RCs, infrastructure prices & mantainence and goods incomes. Do you agree? Do you want to add something to this list?

Next step could be deciding which game parameters should be involved in each point, and maybe its relevance.

It's up to you three to come up with something.

Well, I guess you should get involved a lot in this, not necessary working on it directly but giving advice at least. Also advice from prissi would be important, as an expert, as he has done this for pak64!

[prissi]

Well, I used nearly the same system as you (as you find out) with the aim to get nearly the same income per ton (including the car) of goods transported. I also include the speedbonus for passenger engines, and thus I calculate two values: The income at the start and the end of an epoch. Thus for every engine I can calculate how many cars (and estimate and income at introduction and retirement) and then use about 10% of this income as running cost (for land engines, for ships it would be 45% and for airplanes 70%).

The price I just handwaving guess form power and epoch.

[Zeno]

So, I think I could resume this way of calc like: Running Cost = XX% * Medium(ExpectedYearlyIncomes).
YearIncomes are calculated for intro and retire dates, based on speed, weight, power & cargo capacity (estimated for trucks & engines). Also for this we need the year calculation, based on some space-time calculations using some constants like squares/sec and stuff like that (we'll define later on).

Everyone agrees on calculating RC based on a predefined percent of the expected income? I do agree. OPINIONS REQUIRED!!!

For price we can use additional ideas like payback time, as well as power and epoch, and mix them as percents or additive coeficients.

[VS]

I'd say only the financial aspects should be changed freely, the other parameters are mostly good already.

This I'll admit I didn't think about, but makes good sense:

the same income per ton

About RC, I was thinking more or less the same - except there should be a check if the vehicle is still profitable at end of its lifetime. When is the end? Dunno. Maybe retire date + constant - 10 years for RVs, 20 (15?) trains and planes, 30 for ships…

[Zeno]

I'd say only the financial aspects should be changed freely, the other parameters are mostly good already.

We may change only vehicle's running costs now, without considering other pricing/costs as far as we can. We might consider, but, electric locos should (must?) have a RC lowering factor due to line mantainance.

... same income per ton ...

I also think getting a similar income/ton is interesting. I assume you meant same income per ton including running cost. Didn't you? Also another question for you: did you consider half-way-full plus half-way-empty, or X% of cargo loaded, or you assume train always is full of cargo for calculation?

[wernieman]

If somebody whant to balance the full PAK ... then it is a good idea..

At my last playing, I see the big problems im balancing street (busses, trucks) and train.. so this is a good think to resolve first ...

[Zeno]

I have been looking to an excel file that was used some time ago (I think T.Kubes did it). It was looked time ago, but as it's quite complex, interest on it was gone. Now, with our last comments and ideas, I'm back to that excel, and I've understood many things I didn't in the past, and I think they could be a good reference for us now.

I've only left the necessary parts for locos (I've deleted trucks, buses, trams and so); there is a 'engine' sheet where all data of locos should be entered and then calculations are made over its data. I've writed down some comments on the formulas (see numbers above column headers, and annotations made after all data, aroud row 200 or so). I've tried to explane a little what I think is pretended to calculate with the formula, and how is it done.

There are other sheets where constants, goods, bonuses and other calculations are made (or just there is raw data on it). They help making some calculations on the engines sheet.

I hope it's a good reference, and even a good template to work in it (we could just simplify it, or just tune up the parts we think we have to and document it for further use). Whatever you think IMHO is good at least to take a look on it, and to get some ideas from 
Let me know your opinion on it!

[prissi]

The Napik Excel sheet puts most emphasis on the buying price and less on the running cost, if I remebered it correctly. As a reuslt thing were quite cheap and running cost were also relatively low, compared to pak64 "reloaded".

[Zeno]

Yes, prissi. I think you're right, cause used to play pak128, pak64 running costs look to me as huge as purchasing costs too low
But I think that's more a general thinking problem than a mathematical one...

[prissi]

Well, the Napik was done assuming five years to pay back for everything. This was of course five years on the old system. With the slower default flow of time, this is just one year three months. Most company would like such a high revenue ...