Pak128.Britain balancing

Topic: Pak128.Britain balancing - the plan (Read 20331 times) previous topic - next topic

Pak128.Britain balancing - the plan

October 15, 2009, 07:49:14 pm

Right, the pak needs balancing, and it really needs doing before it just gets too messy, so this is the thread, now is the time!

I've been doing a bit of talking with people who have done this sort of thing before on other sets (special thanks to Zeno here), so I think I have the start of a plan. However, it will need refining, and if anyone with any experience of playing the game/pak has any suggestions/ideas, then I'd love to know, as I haven't actually played for over 2 years!

In other paksets, quite a few people have commented it is very easy to make lots of money after a while, and the game loses challenge. Judging by a save Kieron sent me, this is the case in the latest release of pak128.Britain too. We need a way to keep things profitable, but challenging. I propose the following principles:

1) Construction and vehicle purchase costs are all high. Especially tunnels and bridges. I reckon a payback period of 2-5 years would strike the balance between challenging and not too dull, but how we calculate this is a challenge... (less for vehicles, more for infrastructure).
2) Vehicle running costs should encourage people to select sensible vehicles for a route, i.e. requiring good loads to be profitable. I reckon 20% of revenue per tile would be about right, to allow for return empty trips for goods or non-full loads for p****engers (I always find wait for full load a bit silly for p****enger trains, and I'm glad real trains don't work like this!!!), and also to allow for non-crow-fly routes and leave some profit over.
3) Maintenance cost for tracks etc. should encourage people to make good use of infrastructure, i.e. fast double tracks should be used intensively to be profitable (but the capacity the higher speeds allow should make it a good choice for busy routes). Conversely branch lines need to be just about profitable with only a limited service...
4) Balancing should be adjusted to reflect historical realism. For example trains shoud have higher infrastructure and purchase costs than road vehicles, but generally higher profits when used efficiently.

This has lead me to the following plan:
Step 1) rebalance vehicle running costs to a new speedbonus.tab (I noticed the current one was quite different to the average speed of convoys over time, so I've made a new one, attached, which will NOT be in the next release 1.05, but should be used by anyone contributing to rebalancing). If anyone wants to help with this, please PM me for more details on how to do this.
Step 2) rebalance vehicle purchase costs to give a payback period (with some variability depending on the vehicle to give some historical realism) of say 1 year for road vehicles, 3-5 years for trains/trams. To do this we need to take:
- constant * payback years * annual vehicle profit (after running costs are subtracted).
The constant should vary from vehicle to vehicle (e.g. electrics are cheaper than diesels, experimental vehicles e.g. the APT should be more expensive), but probably in the range 0.2-0.5
Step 3) rebalance infrastructure maintenance costs and construction costs. This will be a bit hit and miss, but hopefully after steps 1 and 2, we will have an idea of how well the current ones work.
Step 4) continual refinement.

Thoughts? More importantly, volunteers? As I'm the only currently active artist on the project, it would be great for other people to help me out here, otherwise graphics output will slow to a crawl...

Re: Pak128.Britain balancing - the plan

Reply #1 – October 15, 2009, 07:58:41 pm

I can't help but wondering how this will fit in with the rather different revenue model in Simutrans-Experimental. I'll be releasing 7.0 over the week-end, and am hoping to start work on tweaking the pakset balance to work well with Experimental. I'm hoping to get as realistic relative costs and revenues as possible, as realistic figures should, if I have done the coding properly, work well with Simutrans-Experimental. Any thoughts?

Re: Pak128.Britain balancing - the plan

Reply #2 – October 16, 2009, 05:07:26 am

Please keep in mind that changing vehicle purchase cost does not have any influence on difficulty and playing challenge. One will never go bankrupt by only buying vehicles, since their value is counted too your company's ****ets. (This applies to simutrans standard ofc).

I will run tests with my AI players over the weekend and report back. This AI only uses ships+trucks.

Re: Pak128.Britain balancing - the plan

Reply #3 – October 16, 2009, 07:46:33 am

@Dwachs, I understand what you are saying. What I am proposing should mean it takes longer to get to the situation where you have so much cash you can do anything you like without noticing a dent in your account! Thanks for looking into things though.

As an update, I have re-calculated running costs for all the trams and trains. I decided 10-20% of max profit for electrics and 20%-30% max profit for diesels/steam. Some really fast trains have higher percentages still, but because of the speedbonus their profit per km per unit transported is still higher than any of the alternatives at the time. These values should make everything profitable to run at any sensible point in the timeline, but may pose challenges when infrastructure costs are factored in.

Re: Pak128.Britain balancing - the plan

Reply #4 – October 16, 2009, 08:58:58 pm

Some thoughts on doubling time:

A doubling time of 2 years would mean that after 20 years you can potentially double your money 10 times, which means 1024 times the income after 20 years, or that you will have significantly more money than ou are actually spending. If you want to play for 100 years, 50 doublings will obviously result in a rather large amount of money.

The advantage of a short doubling rate is fast feedback - especially good for beginners to see their company fail or thrive in a reasonably quick amount of time. Also you can start with a very small amount of money and enjoy watching your company grow quickly into a map spanning behemoth.

For best longplay value we would want to consider what the doubling rate for the transport task is and then match profits to this. The doubling rate of the transport task is how long it takes from spending a certain amount of money to transport everything on the map with modern trains, to needing to double the amount of money you have spent to include new transport tasks (added population and industry), and to keep the vehicles/infrastructure upgraded to a modern standard. If the profit doubling rate and transport task doubling rate can be kept close enough then good play that ekes out extra profit could result in a more complete service and faster city growth. Play that is a little wasteful could see the player fall behind the transport task and see slower growth.

And if profit growth and transport task growth rate are in sync, then there is the issue of starting funds. If you start with a small amount, then growing the company to service the whole map will be very hard as you can't really grow you company much faster than the natural growth rate of the map. So you would want to start with enough cash to provide a reasonably complete service right from the start. Which of course would be a different cash amount for different maps.

Re: Pak128.Britain balancing - the plan

Reply #5 – October 17, 2009, 09:36:26 am

I'm not a developer, but could it be possible to create a formula so the amount of money is increased according to map size, industry growth, beginner mode, city sizes etc.
This could also be disabled, if people prefer default money for a challenging game.

Alternatively, there is a box on the new game menu for people to increase as they wish. - Could there also possibly be a sandbox option? -

Re: Pak128.Britain balancing - the plan

Reply #6 – October 17, 2009, 09:51:45 am

Maragil,

there is already a sandbox option: go to "players" and select "freeplay".

Re: Pak128.Britain balancing - the plan

Reply #7 – October 17, 2009, 10:31:02 am

No no, i mean on the game menu itself, as newbies may not know where it is.

Re: Pak128.Britain balancing - the plan

Reply #8 – October 17, 2009, 11:48:41 am

@jellyman, I'm not sure what you mean by "doubling time". 2 years to double your money is too much I agree. Unless I'm being thick (completely possible though!) I intend a 2 year repayment of costs, i.e. you buy a train that costs 100,000 and it takes 2 years for the train to earn 100,000 and repay itself.

Obviouisly this will need to be tested. If it turns out 2 years makes it too easy, I can up the purchase costs...

Re: Pak128.Britain balancing - the plan

Reply #9 – October 17, 2009, 01:39:47 pm

Two years seem to me awfully short. IIRC pak128 is balanced for 10 years for road and 15 years for track vehicles. This might seem too long, but then again, it is easy to exploit Simutrans in a number of ways so the game is still somewhat enjoyable. The "somewhat" is because bad decisions can result in stalling the development completely, while some strategies can also make the game easy.

Re: Pak128.Britain balancing - the plan

Reply #10 – October 17, 2009, 04:38:37 pm

Thanks for the advice VS, if it works for pak128, then it should work for me! As an aside, is pak128 generally harder since the rebalancing? I haven't played it since, and I remember the old versions were easy.

Back on topic, all I have to do now is figure out a way of working out how many tiles a vehicle can cover in a year...

Re: Pak128.Britain balancing - the plan

Reply #11 – October 17, 2009, 05:57:22 pm

Might I suggest that having exactly the same payback period for all vehicles would make the game rather dull? Some sorts of vehicles may well produce a quicker return on their investment than others, but be less profitable in the long term, and vice versa. Giving all vehicles identical proportionate returns on their investment takes away a great deal of interesting choices for players to make.

Re: Pak128.Britain balancing - the plan

Reply #12 – October 17, 2009, 06:11:37 pm

Agree totally. Road vehicles will generally be cheap, with a quick return on investment (probably around 5 years) but poorer profitability in the long run. Trains will have longer term returns, but higher profitability overall. There will be some variability between different vehicles of each mode, but how much I'm not sure yet. Any suggestions are welcome.

Re: Pak128.Britain balancing - the plan

Reply #13 – October 17, 2009, 07:02:01 pm

OK, some comments on how I figured out which vehicles would be most profitable (in every set):
(1) You really do need to know how many tiles a vehicle can traverse in a month. Well, in experimental, actually, you need to know how many *km* a vehicle can traverse in a month. I did this experimentally when playing. It should be computable, however.

The trouble is that there seems to be some sort of tricky relationship between claimed speed (km/hr) and actual speed (km/month). Someone needs to look into the codebase and find out what that is....

[hours of research later]

OK, so this seems all very complicated. The month appears to be driven by ticks. ticks_per_tag, which seems to be ticks per month, is 2^20. Ticks are advanced in sync_step by the amount delta_t. This is called all over the place, but ticks appear to be largely driven by the *actual* p****age of time -- apparently supposed to be equivalent to milliseconds. (I would *never* write sim code this way....) In the more interesting fast-forward mode, it's simply 201 ticks per sync_step.

Now, the vehicle movement seems to be driven by kmh_to_speed. Internal "speed" is (kmh) * 2^10 / 80 (Yeech.) vehikel_basis_t::fahre_basis is the primary movement routine. It takes "distance" -- appears to be same units as internal "speed" -- as an argument and divides it by 2^12. (!?!?) This is the number of "steps" to move. 256 "steps" equals a tile (orthogonally, longer on diagonal). This means that "distance" / 2^12 / 256 is the number of tiles moved when fahre_basis is called -- this is "distance"/2^20. It appears that for each call to sync_step with delta_t, fahre_basis is called with an argument equal to delta_t times the internal "speed". So this is (kmh) * 2^10 / (80 * 2^20) tiles for each tick.

Which should be (kmh) * (2^10 * 2^20) / (80 * 2^20) tiles for each month. Or, simplified, (kmh) * 2^10 / 80 tiles a month.

So I guess a lot of the funny numbers cancel out. kmh_to_speed converts km/h into tiles/month. It's as simple as that.

(Note that insane things happen when leaving or entering depots, which I didn't figure into this.)

OK, I'll leave my other comments in another comment....

Re: Pak128.Britain balancing - the plan

Reply #14 – October 17, 2009, 07:16:59 pm

Neroden, you are a legend. That formula is just what I was after. Thanks

Re: Pak128.Britain balancing - the plan

Reply #15 – October 17, 2009, 07:24:06 pm

No it does not cancel out, as the user can choose any value for month length he desires. The only important issue is tiles/ticks, as ticks are the only unchanging unit of measure. month and years do not matter in simutrans.

And you cannot do anything about loosing the challenge. That money making get easier and easier as the game proceeds is due to mathematical facts: Any connection add extends the network vastly. Making a single 1-1 connection, all p****enger get 1 additional arget. Adding a branch line to a network of 100 stops, all p****engers are offered 100 additional stops. As a result the number of p****engers (and thus income) will grow nearly exponetnially while the costs just increase linear. That was the reason, why it was possible to construct the large railwaysnets in the middle of 18th century, since the income also grew exponentially. Thing get only interesting after stabilisation, i.e. every town is added and additional connection to cover with the load are needed.

Or by not paying for distance, but just for progress, With that lots of unwanted (since not paying) p****enger are on the trains. The larger the net, the larger the number of those. THus I would rather try to balance pak128.britain for that setting, since imho this is the best way to keep the challenge for larger game and provides still an easy start.

Re: Pak128.Britain balancing - the plan

Reply #16 – October 17, 2009, 07:28:25 pm

I think neroden's formula still holds if bits_per_month=20, which is what I am balancing to.

prissi, I'm not sure I understand your final paragraph though. Is this something simutrans currently does / can do (configurable in simuconf.tab?) or something it will do on the future?

Re: Pak128.Britain balancing - the plan

Reply #17 – October 17, 2009, 07:40:30 pm

Quote from: prissi – on October 17, 2009, 07:24:06 pm

And you cannot do anything about loosing the challenge. That money making get easier and easier as the game proceeds is due to mathematical facts: Any connection add extends the network vastly. Making a single 1-1 connection, all p****enger get 1 additional arget. Adding a branch line to a network of 100 stops, all p****engers are offered 100 additional stops. As a result the number of p****engers (and thus income) will grow nearly exponetnially while the costs just increase linear. That was the reason, why it was possible to construct the large railwaysnets in the middle of 18th century, since the income also grew exponentially. Thing get only interesting after stabilisation, i.e. every town is added and additional connection to cover with the load are needed.

Simutrans-Experimental has been designed specifically to mitigate the gameplay balance issues to which the exponential growth of revenue against the linear growth of costs give rise. A higher proportion of p****engers travel locally, which means that, as a network expands, fewer new p****engers trips are added per unit of expansion. P****engers have alternative destinations, which again de-couples the network growth from a strictly exponential growth in revenue (since adding a further destination will mean for some p****engers that they will travel on the same network to their first choice, rather than second or third choice destination, which does not increase p****enger numbers). Likewise the caps on journey time - the longer the journey in time, the fewer p****engers want to travel on it (even if they otherwise want to get to the destination), again acting as a check on exponential revenue growth as the network expands to cover a larger geographical area (inevitably involving longer journey times - better technology to reduce journey times costs more). Since actual speed, rather than maximum theoretical speed, is used for calculating the speed bonus, increased network congestion can reduce revenue (and likewise, measures to relieve it increase maintenance costs), which can also, albeit in this case to a limited extent, reduce the exponentiality of the link between network growth and revenue growth. Finally, the aspect of competition with private car transport in the later stages of the game also acts as a damper on what would otherwise be exponential growth, causing a reduction in p****enger numbers with which the player will have to deal.

Re: Pak128.Britain balancing - the plan

Reply #18 – October 17, 2009, 08:10:14 pm

OK, so here are the numbers I usually compute when comparing vehicles:
(1) Operating profit for hauling one unit one km on the target run.
For p****engers with full loads, this is [(running cost) / (capacity)] - [revenue per unit] , This works because revenue and running cost are both per km. (It doesn't take into account indirect routing, which is relevant in experimental, but that's OK.)
For freight with full loads, this is [2 * (running cost) / (capacity)] - [revenue per unit], since the freight routes *usually* run empty half the time (and if you can get a two-way run it *should* be super profitable).

For balancing, you have to leave a little leeway on the p****engers and ****ume less than 100% loading both ways. I'm not sure what's good to ****ume, probably somewhere in the region of 90% much of the time, and probably depends on equipment. With big trains you want to leave some leeway for a route with a central trunk section which is 100% full and outer "branches" which are maybe only 75% full, so probably less than 90%. With equipment designed for "point-to-point" traffic you can keep the percentage higher but you have to account for asymmetrical trips, so still not 100%.

So much for per-unit-hauled costs.

-- Note that revenue per unit can simply be looked up on a chart in standard, but is based on the *actual travel speed* in experimental. So in experimental one needs to figure out what the average speed will be on an "appropriate route". An "appropriate route" for a mainline train is one which is pretty straight and pretty flat, typically two curves between stations (= shortest possible route in simutrans) plus some serious slowdowns in the station areas. (And with station spacing appropriate to the chosen train type.) Similarly for lorries. An "appropriate route" for a city bus or tram is full of sharp curves and short distances between stations. An "appropriate route" for a ship is probably terribly indirect. An "appropriate route" for a plane is a straight shot.

(2) Max haulable volume per month on the track.

This is how I figure out how many convois it takes to service a factory. It can also be used to decide what factory production volumes should be! ****ume freight here:
[length of route in tiles] * 2 is the number of tiles it takes for a convoi to traverse a full round trip.
So [length of route in tiles] * 2 / [convoi actual speed in tiles/month] is the number of months it takes a convoi to traverse a full round trip.
[factory units per month] / [units per convoi] is the number of convois which need to arrive at the factory per month.
So [factory units per month] * [length of route in tiles] * 2 / ([units per convoi] * [convoi speed in tiles per month] is the number of convois needed for the route.

(3) Congestion check.

The number from (2) can be too many to actually support. This allows me to figure out whether the tracks or roads or stations will get overcrowded, and should be used as a sanity check when balancing.
[length of track in tiles] / [tiles per convoi -- 1 for trucks, lots for trains] = maximum number of convoys on a two-way route (you can really only manage a lorry every other tile or a train every other block before everything slows to a crawl).

(4) For locomotives only -- cost per kw.

[running cost per km] / [kw] gives a good sense of which locomotives are the best deals for hauling a bunch of waggons. In pak64, one locomotive is head and shoulders cheaper than the rest and ends up being the best choice nearly all the time. (This is not terribly desirable). If a locomotive has a lower top speed, it should have a cheaper cost per kw, otherwise it will never be appropriate to use. (If it's supposed to be obsolete, of course, this is just fine, but if it's supposed to be competitive, it matters.) If it has a higher top speed it can be more expensive per kw, because higher top speeds lead to higher revenue.

(I'm not sure what the effect of "gear" is because I haven't figured out how it works. It *should* give higher accelerations. In experimental, but not in 'standard', higher accelerations would lead to higher average speeds on runs with many stops and higher revenue, too; so locomotives with higher acceleration could also be allowed to be more expensive per kw.)

(5) Figuring monthly maintenance costs into the entire scheme.

OK, so I have two hypothetical schemes, one with rails and one with roads (for instance), or one with fast trains on fast track and one with slow trains on slow track.

I can figure costs per month on each one pretty easily; x units of track * cost of track + x units of station * cost of station. In experimental, also have to add the monthly convoi costs.

Now, in *standard* you can totally cheat by buying very fast vehicles and getting the speed bonus for them and then running them on dirt roads! I do this *all the time*. The only reason you'd need to upgrade the track is if you needed greater volume per month. So to balance it you need *two* speed columns in your spreadsheet, one for revenue and one for volume. :-P

In "experimental" this is more realistic, and easier to work out in a spreadsheet, because the "average speed" for purposes of tiles per month is the same speed used to determine the revenue.

Note that the length of the track figures into the computation up in (2) and (3) as well. The cost of the track is connected to the average speed of the vehicles (used in 2, 3, and in 1 for experimental), and in fact is largely determined by it (except for bridges and tunnels, and you should ****ume none for balancing purposes). The track speed should of course be equal to or higher than vehicle maximum speed. In experimental the "weight limits" also determine the choice of track, but again the choice of track is driven by the choice of vehicle. Expected average speed should be a bit lower than track/vehicle maximum speed. The percentage to use should be dependent on the station spacing and percentage of "in-city" running mostly, since those are the main slowdowns, so it should be different for short-distance and long-distance vehicles. (****ume minimal curves outside cities, because we want to make the route profitable *if it's built efficiently*, not if it's a "bad route".) However, note that in-city running for road vehicles is "free".

The length of the station is simply determined by the length of the train, ideally, and you need only one station at each end for a freight run (that's good enough for balancing purposes; complex stations are used generally when multiple lines interact, otherwise a "staging line" of track or road is used). P****enger runs also need a station large enough to hold slightly over the number of p****engers in a single convoi -- at each end. So the station costs are determined by the vehicles, largely.

OK, so how do I put the numbers together?

[operating profit for hauling one unit one km (from 1)] * [length of route in km] = operating profit for hauling one unit entire route (and returning empty, if freight, and with allowance for non-full p****enger services)
[operating profit for hauling one unit entire route] * [factory units per month] = operating profit per month
[operating profit per month] - [maintenance cost per month] = true monthly profit (not counting depreciation).

[true monthly profit]/[number of convois (from 2)] = profit per convoi

This last one is the number which should be compared to the capital costs of the vehicles. (Treating track and station costs as "input" numbers; whenever they change, you have to recompute the lot.)

Finally, if you do make a spreadsheet, I'd suggest putting it in SVN so other people can poke around at it. :-)

Re: Pak128.Britain balancing - the plan

Reply #19 – October 17, 2009, 08:18:53 pm

Quote from: The Hood – on October 17, 2009, 04:38:37 pm

As an aside, is pak128 generally harder since the rebalancing? I haven't played it since, and I remember the old versions were easy.

I am afraid I can't really tell - all I do remember is that it used to be a lot easier, and that this new balance is finally adding some challenge to my games...

Re: Pak128.Britain balancing - the plan

Reply #20 – October 17, 2009, 08:36:29 pm

Quote from: prissi – on October 17, 2009, 07:24:06 pm

No it does not cancel out, as the user can choose any value for month length he desires. The only important issue is tiles/ticks, as ticks are the only unchanging unit of measure. month and years do not matter in simutrans.

In the paks, cost of track is specified, apparently, in cost per month. Not per tick. So, uh, months do matter.
I guess the cost is actually specified in units of 2^20 ticks, with a variable month length, but that's just CONFUSING, and it does seem to cancel out when nobody's screwing with the default settings. If I get a chance I may run through the codebase and try to abstract out the time and distance constants correctly, and give them names and descriptions in a header file, instead of chasing random bitshifts across the code.

It looks like factory production is also not specified per tick, though I can't figure out how it is figured without giving myself a migraine. It seems to be somewhere in fabrik_t::production. Again, not well-documented code here, random hardcoded bitshifts all over the place.

Re: Pak128.Britain balancing - the plan

Reply #21 – October 17, 2009, 09:01:28 pm

Hm. You probably missed the thread where we talked about the fixed costs being recalculated according to month length. That was yesterday...

Re: Pak128.Britain balancing - the plan

Reply #22 – October 17, 2009, 09:09:15 pm

The costs are per bits_per_month=18, since this was the length of a month before is was configurable. So the costs you see in the game are four times higher.

Re: Pak128.Britain balancing - the plan

Reply #23 – October 17, 2009, 09:35:31 pm

Quote from: prissi – on October 17, 2009, 09:09:15 pm

The costs are per bits_per_month=18, since this was the length of a month before is was configurable. So the costs you see in the game are four times higher.

"Oy." Definitely need to break out and name some constants.

Re: Pak128.Britain balancing - the plan

Reply #24 – October 17, 2009, 09:54:59 pm

Getting back onto balancing rather than coding, it certainly appears from the above that Neroden has done a lot of detailed thinking about the issues here - I mean I had thought of all those factors but never got round to trying to turn the interactions into anything formulaic.

So all told, I've currently only got as far as (1) for running costs of vehicles. That's all my spreadsheet does, it just takes max speed, capacity, speedbonus, goods type, and a nominal balancing year for a convoy and calculates the revenue per tile. From this I apply a factor (typically 10%-35%) to get the maintenance cost per tile. I'll upload this spreadsheet into SVN as suggested.

That's the easy bit, and the rest is Neroden's points (2)-(5). I have to admit I was just going to fudge it through a combination of educated guesswork on annual revenues and payback times, and good old trial and error. However, if anyone (Neroden?) wants to have a go at something more intelligent, then I'd be very interested in what they came up with, especially if it could also give some clues as to what values to give to infrastructure costs and maintenance.

I'm going on holiday on Monday for a week, so I won't really get chance to do any more than finish calculating revenue costs as per step (1), so there won't be any duplication of work if someone else wants to have a go on some of the other bits (or simply just propose fudge-factor values for purchase costs etc.).

Finally, I should repeat about power and gear. The only thing that matters is the value of power * gear - the relative size of power and gear is irrelevant, and is just there to allow you to give historical power values but with different in-game behaviour. I've 95% decided to do away with gear factors in pak128.Britain (as it confuses most players) and just have non-historical power values. Many of these need recalculating (it seems they are too generous and many cheap locos can pull very long trains effortlessly - not intended!). If anyone wants to try that too, feel free.

Re: Pak128.Britain balancing - the plan

Reply #25 – October 18, 2009, 07:33:49 pm

Quote from: The Hood – on October 17, 2009, 09:54:59 pm

That's the easy bit, and the rest is Neroden's points (2)-(5). I have to admit I was just going to fudge it through a combination of educated guesswork on annual revenues and payback times, and good old trial and error. However, if anyone (Neroden?) wants to have a go at something more intelligent, then I'd be very interested in what they came up with, especially if it could also give some clues as to what values to give to infrastructure costs and maintenance.

OK. So this is what I'd do. :-)

For each vehicle, we have a good sense of whether it's a "short distance", "medium distance", or "long distance" vehicle. From this, you can use some educated guesswork to decide how many tiles, approximately, it *ought* to be travelling in an *appropriate* trip.

Enter that as a column in the spreadsheet.

We also know how fast it's supposed to run, and from that we can tell which type of track it should "usually" be using.

Enter the cost of that track as a column in the spreadsheet.

We know how long the convoy will be (we had to in order to compute (1) ), and from that we can tell how many station tiles it will take (another column in the spreadsheet). For freight we know how many stations are needed -- 2. For p****engers we can make an educated guess for an "appropriate" number of stations (another column in the spreadsheet). Again, each engine is probably "supposed" to be used for either p****engers or freight. From this we can figure the cost of station maintenance for the line.

Enter that as a column on the spreadsheet.

This gives all the entries, except factory units per month, needed to compute (2), (3), and (5). So add factory units per month as a column (you're just going to mess around with it experimentally) and put in the formulas to see what the results are for (2) (3) and (5). Then you can eyeball those results and see if the monthly profits make sense as you twiddle with the input numbers.

Essentially, putting those computations in the spreadsheet gives you instant feedback from your trial and error, and that's what I'd suggest. It's still trial and error for the input numbers, but with quick feedback without actually compiling the pak and playing the game. :-)

If you can tell me what the "expected use" of each road or rail convoi is (p****enger/freight and short/medium/long distance), I can put the columns for those computation into the spreadsheet. Although I run OpenOffice.org so you may have to tell me what format to save it in if you run Microsoft products....

For (4) you should probably be running a different spreadsheet, just with locos (no waggons) and a couple of columns. Compute this as a "sanity check" to make sure you maintain the principle that $/kw goes up only if "something else good" like top speed also goes up. To avoid the "BR39 is dominant in pak64" problem.

Re: Pak128.Britain balancing - the plan

Reply #26 – October 18, 2009, 09:18:18 pm

The spreadsheet is now on sourceforge in xls format. That's usable by openoffice and excel so is generally the best to go for (although being an openoffice user I can read ods as well if you do use that).

Anyone is welcome to play around at leisure, especially since I am away for the next week and so if anyone does do something to it then I can pick up the work when I get back.

The rail vehicles have a couple of columns stating a brief (and not terribly consistent) description of the intended purpose of that vehicle. The consist is the one used in the capacity for balancing, and any power/gear balancing needs to ensure that there is sensible acceleration with that consist (and allow for a little lengthening as well, within reason). Note "MT" means mixed traffic, i.e. should be usable on medium level p****enger services and faster goods trains. These usually have two or more entries in the spreadsheet to do the calculations for p****engers and goods separately.

Trams are all short distance, and as for road vehicles, I'm no expert, but you can probably make intelligent guesses. Use wikipedia/internet as well. Generally speaking buses should be short distance. Stagecoaches/coach variants should be mid-long distance. Freight vans should mostly be short-medium distance, with larger vans becoming longer and longer distances for trunk routes.

The RC column indicates the new running cost per km I have just calculated, the RC_factor is the percentage of full load required to generate a profit in the balancing year.

Hope that helps, and good luck and thanks to anyone willing to give this a go! Any questions, do ask, but I won't be answering for the next week...

Re: Pak128.Britain balancing - the plan

Reply #27 – October 19, 2009, 04:59:16 pm

Quote from: The Hood – on October 18, 2009, 09:18:18 pm

The spreadsheet is now on sourceforge in xls format. That's usable by openoffice and excel so is generally the best to go for (although being an openoffice user I can read ods as well if you do use that).

Since every single version of Excel uses a different file format :-P unless I know which one to use it is probably safer for me to save in ods.

Re: Pak128.Britain balancing - the plan

Reply #28 – October 23, 2009, 05:15:27 am

OK, so this is a spreadsheet for The Hood. I added most of the columns and formulas I consider relevant to the "Rail Cost"/"Tram Cost"/"Road" sheets, and an extra "Track Cost" sheet for each of them (tram tracks may differ from train tracks in cost eventually), as well as an extra column on the "Goods" sheet. I left out electrification costs for now; though they may have to be included later, for now the costs are so low that simply making electrified vehicles slightly more profitable than non-electrics should do the trick.

The columns which need to have data put into them, which I *didn't* do properly, are:
(1) route km. This is how long a route is expected to be for this consist (one-way). I'm thinking this should actually be looked up on another table, so that there's a standard balanced "commuter" route length, a balanced "long distance local" route length, etc., but I didn't get around to that. Rough guesses would be a fine way to start. For most situations, this affects the resulting profit quite little, so it's not actually *that* important. It's only really needed for corner cases, although there are several of those in the road vehicles.

(2) Factory/mo. This is a tricky one because it changes over time and based on goods type, but actually the consists should be checked with all the possible relevant factory production rates. For p****engers I'm not really sure what to set it at. But for a first p**** you can just set it to an absurdly large number, since it's just used to generate "ideal convois", and my computations use the smaller of that and "max convois".

(3) Convoy tiles. This is the length of the convoy in tiles, used to figure out station maintenance costs. I'm not sure what these actually are but it should be really easy to figure out :-D This one *IS* important to get right, unlike the other two. However, for trucks I'm pretty sure it's always 1. :-D

(4) AvgSpeedFactor. This is the percentage of the maximum speed which gives the *average* speed. I just guessed utterly randomly, and I'm probably completely wrong....

It's attached p7zipped, which just about fits in the attachment limit. It's in "Excel 97/2000/XP" format. If you have any trouble with it I can reattach it in ods format.

Note that "True Profit/ mo" ****umes full utilitization of the track -- up to the limit of the "factory/mo" setting.

You will immediately notice wildly unbalanced profits per month -- the "Terrier" is probably completely unusable. So I hope this helps balance....

Re: Pak128.Britain balancing - the plan

Reply #29 – October 23, 2009, 05:17:59 am

Oh, I should note the tiles/km column, which I set to "4" thinking about experimental. You should be able to set it to "1" to balance for standard.

*Most* vehicles end up with the same profit/mo, but since it affects max convoys, a few corner cases where track costs dominate will come out rather different.

Re: Pak128.Britain balancing - the plan

Reply #30 – October 25, 2009, 05:39:49 pm

OK, some more notes on that spreadsheet:
(*) There are two significant, important problems with the computation, which I'm thinking about how to fix.
-- For road vehicles, it doesn't take into account 'free' roads, city roads which you don't pay for.
-- For rail vehicles, it figures the cost of a single track, and ****umes convoys packed into a double track.

This should overestimate the profits of rail vehicles, and underestimate the profits of road vehicles.

I have therefore prepared a revised version of the spreadsheet. This one has a column for road vehicles explaining what percentage of the route is on city roads. (My entries in that column, which ****ume that all mail and p****engers are entirely in-city and all goods are entirely on private roads, are probably a bit off but I figured it was a good start.) It also has been changed to ****ume double track for all rail vehicles. (This means that you should be careful with vehicles where a low number of convoys are needed as they will be cheaper than the spreadsheet says.)

Again the factory production numbers appear to be very important to profitability, however I have not been able to figure out how to compute them from the .dat files.... and I still don't know how to guess "typical" or "appropriate" p****enger or mail production.

I think I'm going to poke into locomotive cost/power ratios next.

Re: Pak128.Britain balancing - the plan

Reply #31 – October 26, 2009, 10:08:22 pm

Sounds like good stuff, but I can't read 7z zips - any chance of a more standard format (zip, gzip, tar etc) so I can take a proper look?

Re: Pak128.Britain balancing - the plan

Reply #32 – October 27, 2009, 08:20:43 am

Quote from: The Hood – on October 26, 2009, 10:08:22 pm

Sounds like good stuff, but I can't read 7z zips - any chance of a more standard format (zip, gzip, tar etc) so I can take a proper look?

Not in the forum -- I had to use p7 to get it under the attachment limit! Otherwise it comes out over 150K.

Got a better way for me to transmit information to you? :-)

EDIT: OK, try this:
<deleted>
EDIT: OK, try this:
http://files.[ simutrans [dot] us (site down, do not visit) ]/files/get/tE1kUC5w6g/balancing.xls

This is another revised version. First of all, I caught two bugs in the profit calculation; second, I added a lot of computations to handle "very small" ideal numbers of convois properly (this is one of the things which is causing the revenue problems in the early years, so it's important); third, I abstracted the 'tiles/km' number to its own sheet (and switched its default value to 1); fourth, I put in smaller (more likely) factory production rates and trip distances. I still don't have the array of factory production rates I really want for the sheet though.

Finally, I now ****ume that "one convoy" lines are single-track and all larger numbers of convoys require full double track, which is close enough to correct for most purposes.

I also still don't have proper number-of-tiles lengths for the trains.

Re: Pak128.Britain balancing - the plan

Reply #33 – October 27, 2009, 01:37:14 pm

Thanks. Not sure I understand 100%, but I think I'm about 90% there

Firstly it looks really comprehensive, and fingers crossed it if we can iron out any niggles it's a big step in the right direction.

Now I think I can address some of your queries:
1/ Production rates - these can all be found in the industry dats (productivity=xxx) if you want to root around in the SVN. However this may not be the best way forwards. Especially for p****engers and mail.
a)I think that pax and mail trains should be generally expected to be moving most of the time - i.e. if you have to wait for profitable loads, there's not enough demand to justify that choice of vehicle so you should get scuppered by maintenance.
b)For goods, this may make more sense, but then again what about mixed traffic main line railways? Goods travelling between lots of combinations of factories sharing track with various p****enger routes, and all sharing the maintenance costs.
So generally speaking about this, I think most vehicles should be running most of the time. Excessive waiting for full loads should be discouraged, to make people optimise their vehicle choice to the situations they face. If you still want though, I can do a bit more digging on this. Note that industry productions may need to be re-balanced too.

2/ Convoy length - easy to get from the depot window. I'll get these for you.

3/ Route length - I'll do some guestimation on this.

Anything else you need clarification/discussion on? I'll add in 2 and 3 and return the spreadsheet...

EDIT1: Thinking about ideal convoys more (which from what I can tell is why production rates are required) it may be better to start with the ideal number of convoys a route should support for each convoy in the spreadsheet (e.g. rural branch line train = 1, intercity express route = 4+), and then back-calculate the production rate (this also allows for ballpark industry rebalancing). 1 or 2 convoys should be OK with mostly single track, 3+ should require double. Thoughts?

Re: Pak128.Britain balancing - the plan

Reply #34 – October 30, 2009, 09:51:25 am

The latest spreadsheet is in SVN r230. This includes correct values for convoy length for each convoy, and guestimates of an appropriate route length for each too.