News:

Want to praise Simutrans?
Your feedback is important for us ;D.

Where to read about gameplay/balance goals of paksets?

Started by MobRules, March 27, 2016, 01:00:27 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

MobRules

The pakset list at http://www.simutrans.com/en/paksets/ only mentions gameplay/balance aspects for Pak64.Contrast. I tried clicking through to the forum threads for some of them, but I generally couldn't find the balance & gameplay information there, either. I know I've seen that information somewhere, at least of some of the paksets, but now I can't find that info for any of them.

(I mean information like maintenance vs construction costs, which aspects are balanced to be expensive/inexpensive, which aspects are balanced to be high revenue/low revenue).

I'm pretty sure I at least saw a comparison between Pak128 and Pak128.Britain at one point, but now I can't find it.

Ters

It is my impression that most pak sets lack consistent balancing, or maybe even a specific goal. For pak64 at least, what works and what doesn't varies over time, and also according to various settings.

gauthier

Pak128 has a beginning of balancing, not perfect although it works. In pak128 there was an effort to balance vehicles between them. Apart from that: ways are cheap, tunnels are a bit more expensive, stations cost an arm and a leg and vehicles cost the entire body. The usual pattern is having not-very-profitable freight lines, slightly profitable suburb and regional lines (profitable in early era, slightly profitable in modern era) and high speed lines paying for the unprofitable buses, trams and metros (well, like suburb and regional lines, they are slightly profitable in early era and not profitable at all in modern era). It's primarily a matter of speed.

The Hood

pak128.Britain is currently being rebalanced. I'd like to have an online "manual" for the pakset once I've balanced it properly so people can look up the various different vehicles and what they should be useful for. Is that something we can host on a simutrans server somewhere?

DrSuperGood

QuotePak128 has a beginning of balancing, not perfect although it works.
Sure it works but honestly 75%+ of the content is useless. Do the mathematics on the trains and you usually find that some form of high speed train is always the best passenger train as it has good break even point and makes insane profit when running under load. Thus despite giving the player 10-15 passenger trains to choose from, it is always only 1 or 3 which are ever used.

I discussed this with another developer a while back on a server game and the conclusion we came to was that the many of the early unit trains lacked power to even reach top speed and those that did had such high running costs or bad capacity they make a small fraction of a generic passenger train (engine with generic coaches). Towards 2000 and later they become more reasonable but cannot compete with true high speed solutions. Post 2000 all low speed solutions make such little profit you would only ever want to run them when you will make a loss anyway however that seldom happens if you design your lines right to have good traffic.

Airplanes are broken but then again they are broken in all paksets. I am pretty sure there are some critical features missing currently that are needed to balance airplanes but these features have not yet been planned.

Quote
so people can look up the various different vehicles and what they should be useful for
This should really be in-game as a feature of Simutrans. You should have a convoy encyclopedia showing all convoys available to the pakset and giving some information about them. The information could be silly made up stuff, technical or historic or even just tips how to use the convoy.

Leartin

Quote from: DrSuperGood on March 28, 2016, 03:27:26 PM
Do the mathematics on the trains and you usually find that some form of high speed train is always the best passenger train as it has good break even point and makes insane profit when running under load. Thus despite giving the player 10-15 passenger trains to choose from, it is always only 1 or 3 which are ever used.
There are not too many variables you can tweak for vehicles to be very different. Even less so for trains which can be arranged by the player in so many different ways. And there are not too many different occasions which can occur during the game.

I think in reality, most commonly you already have a network, and have to make sure there is enough capacity on each connection, as well as having a reasonable interval and speed to keep customers. Thus, you have to use quicker trains for longer routes, and smaller, cheaper vehicles for places with less potential pax to be able to maintain an interval. You also would move vehicles around instead of getting rid of them as soon as they are not needed at the line they are on anymore. In Simutrans however, you place an ICE in hicktown and simply wait a few years until every hicktownian entered your train and it starts moving. And once it reaches the goal, all those hicktownians pay extra expensive tickets for reaching their goal that quickly. Even though they would have been better off walking by foot.
Additionally, vehicles never break down. As long as a vehicle makes even the slightest profit, it will eventually amortise, even if it is not utilized to it's full potential.

What I'm trying to say is, I don't think you can give the player 10-15 passenger train where he actually has to choose which one would fit a situation best, since there are hardly 10-15 different situations that can arise. Unless of course you want the player to count tiles and play with spreadsheets instead of the game. I'd suggest seeing suboptimal trains as toys for fans and those who don't care about the financials of the game.

Ters

In a way, it seems like the core game is made by developers who want to simulate a transportation company, and the pak sets are made by artists wanting to play with model trains. I know this isn't completely true, but I don't think it is completely untrue either.

DrSuperGood

Quote
Thus, you have to use quicker trains for longer routes, and smaller, cheaper vehicles for places with less potential pax to be able to maintain an interval.
You can use wait for 100% with some month fraction to space convoys reasonably. It only starts to break down with very large numbers of convoys per month at which point you no longer need it for a regular service. Even in pak128 undergrounds can be quite profitable using high speed engines if the city is big enough and overall pickup high enough.

For example a windy underground (payment 0). If your high speed trains are running mostly empty so losing you money you simply reduce the frequency using the wait for 100% until they are sufficiently full to get a profit. Sure you could use slower speed trains and still break even, but you will not be making profit like you would with the high speed trains.

Quote
What I'm trying to say is, I don't think you can give the player 10-15 passenger train where he actually has to choose which one would fit a situation best, since there are hardly 10-15 different situations that can arise. Unless of course you want the player to count tiles and play with spreadsheets instead of the game. I'd suggest seeing suboptimal trains as toys for fans and those who don't care about the financials of the game.
Suboptimal trains would be better off as "skins" of the optimal trains selectable from separate menus in order to keep the UI clean. Even if this makes no realistic sense realistically, it is very good from a gameplay perspective since then every user can customize the appearance of his trains to best suit what he feels like while still getting the advantage of best choice. it also reduces choice numbers making balance easier.

The Hood

One way round the wait for full load problem I'm trialing in my rebalanced pak128.Britain is using a hefty monthly maintenance cost as well as per tile. I think I'll be the first pak to take advantage of this relatively new feature. It would mean not picking expresses which need a high breakeven capacity if there's only demand for a local train.

Leartin

Quote from: DrSuperGood on March 28, 2016, 06:33:20 PM
You can use wait for 100% with some month fraction to space convoys reasonably. It only starts to break down with very large numbers of convoys per month at which point you no longer need it for a regular service. Even in pak128 undergrounds can be quite profitable using high speed engines if the city is big enough and overall pickup high enough.
For example a windy underground (payment 0). If your high speed trains are running mostly empty so losing you money you simply reduce the frequency using the wait for 100% until they are sufficiently full to get a profit. Sure you could use slower speed trains and still break even, but you will not be making profit like you would with the high speed trains.
You quoted and answered out of context. Please note that I started the paragraph with "In reality" - thus the quoted statement above was meant to reflect how it works in reality, but NOT in the game, which is exactly why the differences between real trains can't properly be implemented in a useful manner by the variables available.


Quote from: DrSuperGood on March 28, 2016, 06:33:20 PMSuboptimal trains would be better off as "skins" of the optimal trains selectable from separate menus in order to keep the UI clean. Even if this makes no realistic sense realistically, it is very good from a gameplay perspective since then every user can customize the appearance of his trains to best suit what he feels like while still getting the advantage of best choice. it also reduces choice numbers making balance easier.
It would already help to combine different versions of the same wagon into one object, so first class, second class, dining car, baggage car, pantograph car etc. can be all the same thing, since the difference between them is not properly simulated anyway. If such a thing would be included in Standard, it could also apply to liveries.
However, since usually all trains are based on real vehicles, "simulators" and "railfans" (rather than "players" and "model railway constructors") probably wouldn't be happy about "wrong" data. Perhaps it would be easier to accept in combination with the aforementioned infowindow, which could then include the actual real data, more precise than the game could.

el_slapper

Quote from: DrSuperGood on March 28, 2016, 03:27:26 PM
(.../...)
Airplanes are broken but then again they are broken in all paksets. I am pretty sure there are some critical features missing currently that are needed to balance airplanes but these features have not yet been planned.(.../...)

IRL, in planes, the cost of the travel increases greatly with the number of passengers. Less than the revenue, fortunately, but still, an empty plane drinks far less fuel. And there are landing costs, too, that are either directly pax-dependant, or weight-dependant. As this effect is not taken in account in simutrans, you've got planes that lose insane aounts of money at a 50% load factor, and earn insane amounts of money at a 75% load factor.

It's still worth it to fill the plane, but it's not a magic ticket to billionaire status like in simutrans. This would be a first balancing effect. Speed bonus should be also seen again. Or maybe not all passengers should be able to pay the Concorde ticket. I guess the efficiency of very high speed comes from that, in Simutrans : unlike Real life, pax who want to travel will travel. Whatever the cost for them. IRL, some people take the high-speed train, and some others take the bus. For monetary reasons.

prissi

The balancing of pak set is mathematically impossible, as all those things are linear, while with a network the number of things to move increase faster. The only way out would a revenue which decrease as the amount of things moved increases.

Even more, there are maps with sparse small towns which are almost impossible to start (if not by ferrys or planes). If you have a challenging balancing for a 256x256 map with 16 towns, it will be almost impossible difficult with 16 towns on a 1024x1024 map.

pak64 is at least consistently balanced and the engines are selected that there is a choice, especially for freight which is often limited to 80-100 km/h.

pak128 was strongly biased towards ships and trucks, and tracks were much too expensive in maintenance. The AI only built trains for goods where there are no trucks, as the balance was really broken. It has improved a little,

gauthier

@DrSuperGood:

I agree with you. I was already complaining when this balancing came out. My opinion is that speed bonus for passengers is completely exagerated, making slow trains unprofitable and fast ones cheated.

Anyway, I know that income from vehicles is calculated from their theoretical maximum speed and not from their actual speed. So even if early vehicles don't reach this speed, their income depends on this speed, as well as the balancing so you can still have profitable trains.

QuoteThis should really be in-game as a feature of Simutrans. You should have a convoy encyclopedia showing all convoys available to the pakset and giving some information about them. The information could be silly made up stuff, technical or historic or even just tips how to use the convoy.
Interesting idea but few pakset creators (not to say probably none) will bear doing this, and few players would even read such stuff. I don't think this is worth doing. It's what I do for each of my addons on SNFOS and I'm not sure it's really useful.

QuoteWhat I'm trying to say is, I don't think you can give the player 10-15 passenger train where he actually has to choose which one would fit a situation best, since there are hardly 10-15 different situations that can arise. Unless of course you want the player to count tiles and play with spreadsheets instead of the game. I'd suggest seeing suboptimal trains as toys for fans and those who don't care about the financials of the game.
I agree with Leartin here. Players who want more choice can also use or make addons. The purpose of a pakset is not giving hundreads of options, especially when it reaches significant a significant size.

QuoteYou can use wait for 100% with some month fraction to space convoys reasonably. It only starts to break down with very large numbers of convoys per month at which point you no longer need it for a regular service. Even in pak128 undergrounds can be quite profitable using high speed engines if the city is big enough and overall pickup high enough.
On some lines, this way of spacing convoys is not efficient. If a line is alone on its tracks (or part of its tracks), like with undergrounds, I prefer using a "spacing block" at one end of the line, I mean a block longer than the others which is the size of the minimum space I want between two convoys, eventually using a long block signal if necessary. It works fine and is much easier to manage than minimum loads and waiting times.

Quotepak128 was strongly biased towards ships and trucks, and tracks were much too expensive in maintenance.
Tracks are not expensive at all and cost almost nothing compared to stations and compared to convoys, in terms of buying cost as well as running cost.

DrSuperGood

Quote
Interesting idea but few pakset creators (not to say probably none) will bear doing this, and few players would even read such stuff. I don't think this is worth doing. It's what I do for each of my addons on SNFOS and I'm not sure it's really useful.
I find myself all the time having to consult a self-made excel table to find out which convoy is the optimum to use for the length I want.

Quote
On some lines, this way of spacing convoys is not efficient. If a line is alone on its tracks (or part of its tracks), like with undergrounds, I prefer using a "spacing block" at one end of the line, I mean a block longer than the others which is the size of the minimum space I want between two convoys, eventually using a long block signal if necessary. It works fine and is much easier to manage than minimum loads and waiting times.
Minimum loads are easier to manage as they take literally 2 seconds to set in the scheduler as opposed to tailoring an appropriate block length which can take more time. If the line is getting overloaded its a simple and free frequency change rather than a redesign of the tracks and signals. Sure they will not work for shared platform lines but honestly from personal experience those are seldom that effective.

Quote
Tracks are not expensive at all and cost almost nothing compared to stations and compared to convoys, in terms of buying cost as well as running cost.
Convoys are not that expensive. Only costing the 15% and monthly deflation of value due to them retaining a value while owned. Rails and stops on the other hand cost a lot to build because they do cost their full price as they retain no value.

Let us not forget about the insane pak128 industry balancing. To service a single textile mill I was using 10+ 10 tile long trains and it still was not operating at full efficiency due to insufficient suppliers. To service a single shop I was operating 2 such textile mills and still was short ~20% product. That is just for one of 3 different products from one of 4 such shops on the map of a server game. So many cotton and wool trains were arriving I was having throughput issues on a dedicated line just for that factory. When I first set up one of the factories before I had a dedicated train line built for the product and most of the suppliers connects I had to order 100 road trucks to move the product and they still were struggling to cope.

Industries really should ship fewer but more valuable cargo. It should be possible to mix supplies and products from multiple factories on the same shared line, rather than needing multiple dedicated lines per factory.

jamespetts

Quote from: Leartin on March 28, 2016, 05:38:27 PM
There are not too many variables you can tweak for vehicles to be very different. Even less so for trains which can be arranged by the player in so many different ways. And there are not too many different occasions which can occur during the game.

I think in reality, most commonly you already have a network, and have to make sure there is enough capacity on each connection, as well as having a reasonable interval and speed to keep customers. Thus, you have to use quicker trains for longer routes, and smaller, cheaper vehicles for places with less potential pax to be able to maintain an interval. You also would move vehicles around instead of getting rid of them as soon as they are not needed at the line they are on anymore. In Simutrans however, you place an ICE in hicktown and simply wait a few years until every hicktownian entered your train and it starts moving. And once it reaches the goal, all those hicktownians pay extra expensive tickets for reaching their goal that quickly. Even though they would have been better off walking by foot.
Additionally, vehicles never break down. As long as a vehicle makes even the slightest profit, it will eventually amortise, even if it is not utilized to it's full potential.

What I'm trying to say is, I don't think you can give the player 10-15 passenger train where he actually has to choose which one would fit a situation best, since there are hardly 10-15 different situations that can arise. Unless of course you want the player to count tiles and play with spreadsheets instead of the game. I'd suggest seeing suboptimal trains as toys for fans and those who don't care about the financials of the game.

One of the main purposes of Experimental has always been to avoid these problems and make a far greater range of vehicles viable for a range of different situations: thus, it takes frequency and waiting time into account, passengers will walk when that is quicker (taking into account waiting time), and passengers have a maximum journey time tolerance (including all waiting times) beyond which they will not travel at all. Also, powered vehicles have tractive effort as well as power, making vehicles suitable for quick acceleration or large, heavy loads different to those best suited for high top speeds on longer journeys with lighter loads; similarly, there is comfort, which makes low capacity vehicles optimal on longer journeys (where comfort affects the revenue far more), whereas higher capacity vehicles are more suited to local journeys where comfort is less relevant to price and where profits are in any event lower. Experimental also introduced variable loading times to provide an additional differentiation between the optimal short and long-distance vehicles (the idea being that long loading times would be associated generally with vehicles of higher comfort), although this feature (without the corollary of comfort) has now made it into Standard, albeit in a simplified form (without customisable variable loading times depending on load).

Coming soon will be vehicle overhauls, secondhand vehicle sales and easier automatic cascading, availability percentages and regular maintenance (this will be automated so as not to involve tedious micro-management), a separation of fuel cost from repairs, inflation with different rates for each different type of cost and the ability to reconfigure convoys in service (e.g. to change locomotives on a train at a station).

The ultimate plan is to balance things so that the game is not too hard (slightly or even moderately suboptimal choices should not be catastrophic;  only large errors or significant economic changes should be able to result in insolvency), but not too easy (even the most optimal choices should not result in a player having more money than he/she can possibly spend except by accumulating it gradually over many game decades), and for the exactly optimal choice to be impossibly complex to calculate with spreadsheets (as in reality), but for the approximately optimal choice to be moderately easy to infer (rather than calculate), and for a not seriously suboptimal choice to be really quite straightforward to infer.

The idea is fundamentally to change playing style: instead of, as with Standard, carrying out a fairly simple computation of initial cost and expected lifetime profit on the basis of a few easily quantifiable variables, and finding that, as Dr. Supergood points out, only 2-3 things can ever be optimal for that no matter what the circumstances, the idea is that the player has to think qualitatively as if he or she were managing a real transport network. For example, one railway locomotive may be better for a specific diagram hauling a moderately loaded fast express between two towns with a reasonably hilly route, but, as loadings increase on that route and in 5 years' time a new, faster and more powerful locomotive becomes available that is more suitable for that route, the player might decide to cascade the older locomotive (which would not yet have amortised its cost) to a secondary route to which it is not the optimal solution, but is better than whatever was there before and is not seriously suboptimal. One 'bus might be slightly more comfortable but cost slightly more to buy than another, and whether it is optimal compared with the other will depend on the exact distances of the journeys made by passengers on it throughout its lifetime. One could not work it out precisely: one would have to think in general terms, "this 'bus is intended for short routes in town, so comfort is not a high priority" or "this 'bus will be used on longer routes to neighbouring villages, so it will probably be worthwhile to pay a little more to get the passengers more comfort". Working it out precisely would be practically impossible. The difference between two railway locomotives might be that one has a little more power but quite a lot more in the way of running costs (i.e. is less efficient), or that one has a higher fixed cost than another, but a slightly higher top speed: the exact optimal choice will depend on the relationship between the likely load, the length of the journey between stops, and the hilliness of the route over the lifetime of its usage, which, because cascading will be both permissible and highly desirable, will be impossible to predict at the outset.

Dr. Supergood – you mention that you suspect that aircraft are currently impossible to balance owing to missing game features; may I ask what you believe that those features are likely to be? el_slapper suggests passengers constrained by cost, but this is unlikely to be viable even in Experimental as it would require, even in the simplest implementation, doubling or trebling the computational effort involved in routing (by dividing passengers into two or three price brackets, and having the lowest or lowest two constrained by price in some way), and even this would create anomalies (a service would be profitable even if it were cheaper, but a player cannot adjust the price and so is not profitable because not enough people use it at the higher price) or excessive micromanagement (the player can adjust the price of everything, and thus must constantly do so in order to maximise profits, meaning either the game has to be balanced with this in mind, making it unprofitable for anyone who does not, or it is balanced without this in mind, making it excessively profitable for those who do).
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.

prissi

Ships and airplanes require almost no infrastructure compared to the available transport capacity. You can make airport more expensive to maintain to make flight less attractive for all but the longest distances (which will not work for ships). Still as soon as you get enough passengers, the money will roll in.

One could make waiting for filling less attractive by a higher monthly maintenance. It will then only delay the point when there is a single optimal choice. (And there will be also an optimal choice or maybe a draw, because this is a discrete simulation with controlled parameters).

Since passengers will only travel when there is a connection (fast or at all), the network effect will give you plenty of money once you have a network. The first stop connect nothing, then next two destination, the third will have three destinations and three routes, the forth stop will enable four destinations but six routes, and the fifth stop will enable ten routes, and the sixth stop 15 and for n stops it is (n over 2)=n*(n-1)/2.

Adding stop number n stop will add then n new routes and thus n times new passengers. It can be tuned down by locality and other things a little but it the end the interconnection will cause a lot of extra income by adding very little. (Or one would have to reduce the price for a passenger in proportion to the number of destinations served, although weighting this correctly will be very hard, since we are dealing with exponential(!) growth here and saturation will suddenly make a well behaving game uneconomically when we get a good percentage of all passengers.)

Thus, within the current system any pak can be only balanced for the start phase; and then population density is the key. By setting it very low, even "easy" paks can be impossible to start.

jamespetts

  Yes, the exponential network effect: this is not, of course, how it works in reality, as people do not in reality have only one possible destination for each potential trip, and refuse to travel if they cannot get to it. This is why transport networks in reality, although they are subject to the network effect significantly, do not grow continually exponentially as in Simutrans.


This is the function of the alternative destinations system in Experimental: as in reality, as each new connexion is added to a network, not only will new passengers who would not otherwise have travelled at all be serviced, but existing passengers who would by preference previously have travelled to the new destination but were constrained to take a lower priority choice on the existing network (or within walking distance) will simply be diverted to the new destination.


This allows for a much lower base number of generated trips to be viable in the early stages of the game where there are few networks (significant numbers of passengers choosing destinations far down their list of preferences that are served by initial, early networks), which then prevents excessive crowding and/or profit when networks are much more complete.
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.

Isaac Eiland-Hall


gauthier

QuoteI find myself all the time having to consult a self-made excel table to find out which convoy is the optimum to use for the length I want.
Well if you want the absolute optimum of all the possibilities you have, we can't do much. How a description and general advise about a vehicle would help you ? What you are currently doing is precise calculation depending on both vehicles and lines you want to run, writing an encyclopedia won't do this for you.

QuoteMinimum loads are easier to manage as they take literally 2 seconds to set in the scheduler as opposed to tailoring an appropriate block length which can take more time. If the line is getting overloaded its a simple and free frequency change rather than a redesign of the tracks and signals. Sure they will not work for shared platform lines but honestly from personal experience those are seldom that effective.
First: I don't want to argue too much about this as it sounds like a matter of style of playing.

I can say, from my personnal experience, that I often get problems with minimum loads for several reasons including temporary asymetries in passengers flow along the line or changes between high capacity convoys leading to a situation that a train with 80 or 90% minimum load always end up with 100% load.

The problems I get very often is that after a certain period of time, I have trains waiting at the terminus while the station before it is overcrowded. Finally I spend my time trying to find a good value for these minimum load and minimum waiting time. On top of that, if the line is crowded enough, but still not saturated, convoys start bunching.

When I use spacing blocks, I'm sure to keep a regular frequency. I don't spend an hour measuring total length of the journey or anything like that, an approximate estimation is enough and still very efficient for me. If I get overcrowded stations, I know that I don't have to struggle with parameters or send an "ambulance" train to fix a punctual problem, but just add a convoy and check whether I have to shorten the spacing block of some tiles.

Once again: I'm speaking about my own personal experience, I don't mean to argue on this question.

DrSuperGood

Quote
may I ask what you believe that those features are likely to be?
I honestly do not know. One can feel it is missing but what mechanic really needs to be discussed. From my thoughts it falls into two areas.

  • Increasing airport construction effort. Currently airports are literally 2 minutes for any distance where as a cross map line can take 1-2 hours to make depending on map size.
  • Limiting airport profit in a reasonable way. Since effort is based per stop rather than per distance there has to be some limit to profit which is significantly lower than if the effort was spent making a line across the map.
If one pushes to "ban" aircraft in a server game you commonly read "but airports are so much easier than rail" which is sort of self explanatory.

Airports are not the only problem. Tunnels also have problems with balance as there are no limits to building tunnels other than money. For example in a server game where aircraft were banned the player raged and then built cross-map tunnels instead as they are similar effort to build. I once built an entire empire in pak64 just using road tunnels one on of Fifty's server before my turning circle (roundabouts) unfortunately crashed it due to a now fixed error.

Quote
How a description and general advise about a vehicle would help you ?
The feature should have other tools to help you. What these tools are might need some research but anything is better than what we have now where we literally need to buy convoys and stack coaches to see what happens.

Quote
I can say, from my personnal experience, that I often get problems with minimum loads for several reasons including temporary asymetries in passengers flow along the line or changes between high capacity convoys leading to a situation that a train with 80 or 90% minimum load always end up with 100% load.
It is aimed at commuter services only where you wait at a massive and only transfer to space the convoys a bit. Only time you need to wait for 90% and such is for convoys with mixed passengers and mail where you always wait for the passengers. If the train leaves full there is no problem because it is then full and so not wasting capacity and it is still spaced better than if no spacing was applied. This is not experimental so spacing does not need to be perfect, you just want to avoid the situation where every month you get 4 mostly empty trains in a row in the first few days and the rest of the time there are no trains so the stops over crowd. For main point-to-point lines you should always wait for 100% to maximize profit and so spacing is irrelevant and automatic based on the pickup rate of the servicing lines.

prissi

Sorry, the network effect is real, it has been shown countless times in real life. It is one of the reasons of traffic jams etc. Only for the European saturated society (i.e. almost not growth) there are simply no new destinations and thus not such effect any more.

But look for instance for flights: With cheaper flight available, there are suddenly more people traveling to airports and so on. There is a reason why train and bus operators do not offer discounted tickets for airport destinations, they are using the network effect ...

Simutrans experimental does the same thing, call it diverting or otherwise: As long a you have growth there will be a network effect (unless you set maximum changes to one, i.e. only allow direct connections).

jamespetts

Dr. Supergood – one should ask what the real life things that affect airports' viability are. In Experimental, we now have a (realistic) minimum runway length for aircraft, which forces airports to be in a large flat space, as in reality; there is a minimum transfer time of 30 minutes for passengers to simulate check-in, security, etc.; the loading time for aircraft is high; and airports all require control towers, which can be made quite expensive. All of these are intended to simulate real life constraints on airports the absence of which was making Simutrans air travel unrealistic (and too easy for players). Do we need anything else besides realistic cost of servicing and purchasing aircraft to limit the relative profitability of air travel to realistic levels?

As to tunnels, in reality, these are very expensive indeed, and this is the main constraint on their use. Is there any reason in principle why, if properly balanced, expense alone should not be the limiting factor for tunnels (but allowing realistic underground railways: if a high utilisation can be achieved, at least).

Prissi – I did not intend to doubt the network effect in principle; but the effect is somewhat too strong in Standard, I think, and dampened (I think realistically) by the alterative destinations system in Experimental.
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.

el_slapper

Rethinking about this, I think there are 2 problems with the planes.

On the income side, the speed bonus should not be affordable for all passengers. Same for trains, but the problem is even bigger for planes. I know people who take the bus because the TGV is too costly. In France, not the poorest country in the world. And not many people are going to take the Concorde at this price. It happened to me to cover the map with Concorde. My company was gushing cash. But I'm not sure it's really normal to play like that for being successful.

On the expense side, the airport costs should be less maintenance-based, and more traffic-based. The airport fees have a big impact upon prices on short-range travel. And the fuel costs are bigger with both distance and the number of passengers.

As most planes are balanced for a load factor of 70%, variable costs would ake them more nerfed. With bigger costs on ground(to simulate the handling fees), and increased costs per pax(with 65% costs when empty, and 115% costs when full, leaving the current setup at 70% of load factor). Of course, this would kill my current strategies, but they are cheaty, to stay polite.

Experimental's addition are nice, but the control tower thing is not really balanced IMHO. Maintenance cost for a bush airport fielding only a F27 should be light, IMHO. Operating dozens of A380 in one airport should be prohibitive. As the A380 does not pay anything while grounded, realistic waiting times are not enough. They help nerfing the income per capital invested(a good thing), but not the operational margin.

jamespetts

Quote from: el_slapper on March 30, 2016, 10:17:39 AM
...Experimental's addition are nice, but the control tower thing is not really balanced IMHO. Maintenance cost for a bush airport fielding only a F27 should be light, IMHO. Operating dozens of A380 in one airport should be prohibitive. As the A380 does not pay anything while grounded, realistic waiting times are not enough. They help nerfing the income per capital invested(a good thing), but not the operational margin.

The type of aircraft that an airport can accept depends upon its runway, does it not? Heavier aircraft require stronger and longer runways, and runways are expensive to build (and need a lot of space). The control tower mechanism is not enough on its own to deal with these problems, but I'm not sure that it's inherently unbalanced.

Dealing with the speed/price problem, as discussed above, is prohibitively complex, at least for any solution involving actually balancing speed against price individually for each packet of passengers. This is because it would require complicated route finding (taking into account a specific speed/price balance for each possible leg of the journey) and for each packet of passengers to have its own route finding rather than for there to be a general standardised route finding for all. The only thing that could work is to have a fixed number of classes of passengers, the lower two of which have maximum price tolerances, but this would be impossibly difficult to balance because of the inevitable effects of a third of passengers having exactly the same price tolerance.

It might be better simply greatly to reduce (or to cap or otherwise significantly dampen the effect of) the speed bonus, but that leaves the difficult problem with aircraft that, in Experimental, people will choose them over any other form of long-distance transport even when their capacity is very limited, leading to overcrowding.
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.

DrSuperGood

The problem with airplanes is not so much the money they earn, but rather the money the player earns for spending no effort. On at 2,000*2,000 map I can plonk down 2 airports, one at each map corner, and make insane profit for spending only 5 minutes of work. Crossing the map that way with rail could take me well over 3 hours depending on how the map is shaped and how developed it is.

Firstly I would like to see minimum runway length as well as control tower requirements etc. Not so much for cost, but rather for just making it more difficult to make an airport than putting down 1*3 runway, a slab of taxiway and then a stop.Then there should be other mechanics such as landing and takeoff fees to limit minimum distance and maximum flight distance to limit maximum profit. Using airports should be viable, but not super easy.

jamespetts

On a sufficiently crowded/hilly map, I suppose that having a long enough straight runway could be quite a challenge. As to fees, these only make sense if the person landing the aircraft is not the same as the person owning the airport, which is a sort of access fee, like the tolls already in Standard. These fees already exist for ports and airports in Experimental, but are currently set to be a fraction of the revenue from the flight rather than a fixed amount, the latter of which would be very difficult to calibrate.
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

It's an interesting discussion.  The population of the UK expanded from ~5 million to ~50 million in the 300 years from 1700 to 2000.  Run a Simutrans game and you'll likely achieve far more than a 10x population growth, which compounds itself enormously with the exponential network effect.  Start a game with 5 million population, turn down the passenger generation and you'll likely have a game that doesn't expand out of control quite the same way.

As for airports, the cost of laying runways and other airport infrastructure should be sufficient that one cannot make a profit running just a couple of planes between two airports.  If you want to lay down asphalt runways and all of the attendant infrastructure to run large capacity aircraft, the monthly maintenance requirements should be large enough to force you to run a high frequency service to turn a profit.  Agreed about minimum runway length -- as planes get larger, runway length becomes greater and the base cost of operating increases accordingly.

As mentioned, however, one thing missing is a reluctance for passengers to take a high-cost form of transport if it is uneconomical to them.  The time vs. cost equation is important: as personal wealth increases, the price they are willing to pay to save time increases.  Many passengers would not choose to fly between London and Paris as there are many other cost-effective choices.
Current projects: Pak128 Trees, blender graphics

jamespetts

The issue of population growth is one that Experimental has yet to address, but this is planned with a new town growth algorithm. However, even Standard can (and perhaps should) address this by having a straightforward system of custamisable relative growth for towns: an approximate 1% annual growth rate, for example, that can be set in simuconf.tab would alleviate the excessive growth often seen. Perhaps even just a system where the existing growth settings in simuconf.tab can more readily be mapped to proportionate growth, or even just documentation for pakset developers on how best to optimise these.
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.

DrSuperGood

#28
Quote
As to fees, these only make sense if the person landing the aircraft is not the same as the person owning the airport, which is a sort of access fee, like the tolls already in Standard.
Actually they make sense from an upkeep point of view. At takeoff/landing the aircraft is strained the most so it is where the most ware occurs, eg the tyres on landing and the engines on take off.

Quote
Run a Simutrans game and you'll likely achieve far more than a 10x population growth, which compounds itself enormously with the exponential network effect.
Not at all true. If you run a Simutrans game with 1 city of 5 million people it will likely only end at 5.3 million people after 300 years of full growth. Run a Simutrans game of 5 million cities with 1 person and it will get 50 million people in under 1 month of growth. The problem is growth is tied to the number of cities and their service quality rather than overall regional population.

Quote
As for airports, the cost of laying runways and other airport infrastructure should be sufficient that one cannot make a profit running just a couple of planes between two airports.  If you want to lay down asphalt runways and all of the attendant infrastructure to run large capacity aircraft, the monthly maintenance requirements should be large enough to force you to run a high frequency service to turn a profit.  Agreed about minimum runway length -- as planes get larger, runway length becomes greater and the base cost of operating increases accordingly.
Airport runways are not a big cost when running an airport. There are airports which see only a few planes every week in real life.

jamespetts

Quote from: DrSuperGood on March 31, 2016, 05:42:11 PM
Actually they make sense from an upkeep point of view. At takeoff/landing the aircraft is strained the most so it is where the most ware occurs, eg the tyres on landing and the engines on take off.

Such a cost ought not to be thought of as a fee, but rather as a variable maintenance cost. Experimental does have (in the development version, at least) the way wear feature, which means that ways must be renewed after a certain level of usage (adjusted for weight). Do you think that anything beyond this is needed to simulate this particular dynamic?
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.

el_slapper

#30
Quote from: jamespetts on March 31, 2016, 06:19:08 PM
Such a cost ought not to be thought of as a fee, but rather as a variable maintenance cost. Experimental does have (in the development version, at least) the way wear feature, which means that ways must be renewed after a certain level of usage (adjusted for weight). Do you think that anything beyond this is needed to simulate this particular dynamic?

In my understanding, it's the plane that gets the wear, more than the track. Planes like the 777 or the A380 shall never be used on short travels, because they are limited to a smaller number of "cycles"(takeoff, flight, landing) in their operational life than a regional jet. Besides the engine & tyre wear cited by DrSuperGood, the structural fatigue due to the compression/decompression is huge on the biggest aircraft. Add to this the huge amounts of fuel burned to take-off, which is even bigger when the plane is full.

The current maintenance model might be OK for trains, even if not optimal, and wearing the train track each time it's used might make sense for trains. But planes have a different dynamic, yet in the game have the same. Which means you cannot currently balance properly the trains AND the planes. That game is made by train lovers, and I have no problem with that, but it makes planes either unusable...or cheated.

So, IMHO, extra maintenance costs for the plane when it takes off(and a punitive one), and also linked to carried passengers, would be more appropriate than costs on the track(which OTOH make perfect sense for trains, trains being the bread & butter of simutrans). And, of course, nerfed income on very long distances and very high speeds - one way or another, but I fear forbidding poor passengers from taking too costly means of transportations would be too costly in terms of coding(though would be perfect in terms of realism).

EDIT : Embraer's small regional jet family, the ERJS, are certified for 75 000 flight hours, or 60 000 flight cycles
Quote from: Embraer s offical website(.../...)That durability is reflected in the ERJ's 75,000 flight hour or 60,000 cycle crack-free design life.

jamespetts

el_slapper: this is very interesting and useful. The next major project after railway signalling is adding features for the balancing of vehicle costs, and I shall give careful consideration to your aircraft related suggestions, which are most useful. Thank you.

Edit: Incidentally, does anyone have any idea how the effect of loading on per kilometre cost or the additional wear caused by landing/taking off might be calibrated?
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.

HarrierST

Quote from: jamespetts on March 29, 2016, 11:33:01 AM
One of the main purposes of Experimental has always been to avoid these problems and make a far greater range of vehicles viable for a range of different situations:

The problem is, if you are not a programmer and do not have access to a compiler and if you did, did not know how to use it - you can not play Experimental.

Unless you play the version released a few years ago - that does not contain these new features.

I may be wrong, but I think your reluctance to release a new version only when perfection is achieved - is losing you a lot of potential followers - me included.

The instructions to update are far to complicated.

jamespetts

Quote from: HarrierST on April 01, 2016, 01:34:22 AM
The problem is, if you are not a programmer and do not have access to a compiler and if you did, did not know how to use it - you can not play Experimental.

Unless you play the version released a few years ago - that does not contain these new features.

I may be wrong, but I think your reluctance to release a new version only when perfection is achieved - is losing you a lot of potential followers - me included.

The instructions to update are far to complicated.

This is getting a little far away from the topic of the thread, which is pakset balancing; but deciding when to release is not an easy task; too frequent a schedule, and one is not able to undertake any larger projects, but too long a schedule, and people are frustrated by lack of releases.

I am not waiting to attain a state of perfection, but rather waiting until I have a specific feature set added. The reason for this is that that feature set is critical to balance (as discussed herein), and, once those features are in place, it will be possible to balance the game in ways that it are not possible now. Without being balanced, there really is only half a game.

I am aware of the difficulties that a long delay between releases causes: part of the delay in this case has been because I did very little work on Simutrans for a year in 2014/2015 whilst I was moving house. I am increasingly inclined towards the view that one specific set of features originally planned for the next release (town growth and economic integration) had better wait until the release afterwards (if I can find a way of controlling the rate of town growth using Standard's system to prevent the game-destroying explosive growth seen in the current release version of Experimental and Pak128.Britain-Ex, hence the questions above about how to calibrate town growth in Standard) precisely in order to foreshorten the release cycle.

The trouble is that, with frequent releases, a huge proportion of time is spent on making minor adjustments and releasing, and at a time when frequent releases were being put out, features that had been planned since early 2011 as critical for balance had not been started by 2013. The idea of this release cycle is to clear those things so that at least a start ban be made on balancing. Having very few people (i.e. one person) working on the coding in his spare time makes it really very difficult to set priorities and plan.
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.

el_slapper

Quote from: jamespetts on March 31, 2016, 08:11:12 PM
(.../...)Edit: Incidentally, does anyone have any idea how the effect of loading on per kilometre cost or the additional wear caused by landing/taking off might be calibrated?

Links in french, but I'll translate. A340
QuoteConsommation d'un AIRBUS A340 - 300 de 271 T au décollage, en montée initiale et en croisière:
Décollage, rotation jusqu'à 1.500 feets: 2,2 T
Montée initiale de 1.500 feets à 31.000 feets: 5,8 T
Croisière: 1 tonne par 70 Nm
==> This plane, ideal for flights between 300NM & 6000NM, drinks, when full, 8T of petrol for reaching his flight level. The same amount is enough to cover 560NM. When it pushes to 7000NM, it drinks 108T in total.

I did find here a calculator (not accurate, unfortunately), but also a few interesting figures concerning fuel - figures that are averages seen on true flights.

For cargo planes,
_when the MTOW is below 100 tons, count 107,3 liters(not tons) drunk per 100km per ton transported for a flight below 1000km, and only 76,4 liters when the distance is between 1000 & 4000km.
_When the MTOW is between 100 & 250 tons, count 64 liters drung below 1000km, and 50,8 liters drunk between 1000 & 4000km.
_When the MTOW is above 250 tons, only distance over 4000km are considered. And the total consuption between 4000km & 7000km is 21 liters(per 100km per pessenger), while it's 21,4 above 7000km.
In short : around 7000km(3780NM or so), the excess of distance begins to cost you more than the take-off. That's for the big birds like the A340 of the other link.

Fuel can be up to 35% of the expenses of a plane...when fuel prices are high, which was true a few years ago, but no more today. For more easy years, you can count around 35% in personal, 10% in airport fees, 5% in navigation fees, 20% in fuel, 15% in marketing(not taken in account in simutrans), 10% in maintenance, and the rest in misc. Airport fees are per landing, navigation fees & personal expenses are linear. The 10% of maintenance are really 90% linked to take-off and landing. Flying nearly does not wear the plane. The tough beast to count is fuel.

And my numbers are roughly accurate today. Very roughly.