News:

SimuTranslator
Make Simutrans speak your language.

Realism VS gameplay: a couple of balance issues

Started by Lord Vetinari, April 13, 2010, 05:33:57 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Lord Vetinari

One of the reasons because I love Pak Britain is that it lets me play in the pioneer era of railways. However, the gameplay balance of this period has some problem, especially if you are playing with Standard Simutrans.

An example: untill 1854 the LMR 4 wheel carriage is available. It carries 24 passengers, a 4 tiles train (14 carriages + engine) can carry 312 passengers. They become obsolete in 1855, so you are forced to use LNWR 4 wheel carriages (and possibly to update all existing trains). Since they are slightly bigger, you can accomodate only 12 cars in 4 tiles, one of which needs to be the end wagon, that carries mail instead of passengers. Total amount of passengers carried: 216, almost a hundred less. This means that you need to add another tile to all of the stations or add a lot of trains to the lines (and sometimes both are problems). The incrased speed of the new engines doesn't help much.

I know the amount of research that there is behind Pak Britain, so I suppose that those values are based on historical facts, but can't they be slightly altered to achieve a better gamplay balance?


kierongreen

Well it should be a slow progression as time goes on with platform length steadily increasing (up to a point of course). So sooner or later you will have to add tiles to stations. Ideally I'd want people to build a railway for the era they are playing in, then have to face the consequences and expense of upgrading as they continue with the game, not be able to build a railway which will see them from the 19th to 21st centuries without doing any work!

Lord Vetinari

#2
Well, I actually do that. On my main lines I switch to Jenny Lind as soon as it's available; I also add a couple of tiles to the stations, renew the signalling system where needed, etc.
However, I usually have a whole bunch of secondary, branch or urban lines where Patentee + 10 - 14 cars is still enough to grant a perfect service.

Another issue with that switch is that Patentee becomes practically useless, even if it's available to purchase for another five years. It's not strong enough to pull enough of those LNWR 4 wheel carriages.

The Hood

It is possible to purchase obsolete vehicles, so if you need more of the LMR carriages for whatever reason, you can still buy those right up to the end of the game if you so desire.  In reality trains have always got longer and heavier over time, especially in the early years of the railways, as comfort and speed increased that required larger carriages for the same number of passengers, which in turn requires longer stations and more powerful engines.  What you describe seems to me to be fairly accurate - part of the challenge of the early years ought to be in keeping your network up to date to take advantage of the faster speeds offered by newer vehicles, which includes signalling and platform changes...

jamespetts

It should be noted that, in Experimental, the greater comfort of the later vehicles makes them more profitable than the earlier vehicles, counterbalancing the cost of upgrading to some extent. Also, obsolete vehicles can still be used (both in Standard and Experimental). In Experimental, they begin to cost more to maintain, although I am presently considering whether to make that additional cost smaller than it currently is.

As for purchasing obsolete vehicles, there is a new simuconf.tab option in the latest nightlies (and latest versions of Experimental) that prohibits the purchasing of obsolete vehicles. I am considering whether to enable that by default in the next release. However, bear in mind that you can always "cascade" - a popular practice in real railways: buy new stock for your express routes, and use your existing, older stock on your more minor routes. You can even keep a set of older vehicles in a depot to use for future minor lines if you are in the process of expanding and think that the older stock is more economical for the time being.
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.

sbt

Quote from: jamespetts on April 14, 2010, 08:30:26 AM
However, bear in mind that you can always "cascade" - a popular practice in real railways: buy new stock for your express routes, and use your existing, older stock on your more minor routes.

e.g. LB&SCR/Southern/BR 'Terrier' Tanks - in service 1871 to 1961, the last years being on the Hayling Island line as they were the only thing around light enough for the bridge.

A good candidate for an addition to the stock list?

Rick

jamespetts

There's already a Terrier, I think - going by its more correct name of "A1".
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.

sbt

Quote from: jamespetts on April 14, 2010, 07:38:09 PM
There's already a Terrier, I think - going by its more correct name of "A1".

Great - I hadn't noticed because I've been playing in the 1750's with canals - my specialism (I restore 'em, boat on 'em and live on a boat on one).

There are are game realism issues with the canals as well BTW - look out for a steady stream of info from me.

Rick

jamespetts

Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

sdog

QuoteIt should be noted that, in Experimental, the greater comfort of the later vehicles makes them more profitable than the earlier vehicles, counterbalancing the cost of upgrading to some extent. Also, obsolete vehicles can still be used (both in Standard and Experimental). In Experimental, they begin to cost more to maintain, although I am presently considering whether to make that additional cost smaller than it currently is.

the upgrade cost was killing my company in two games with earlier experimental versions. It was mainly a problem with buses however. I consider the very high cost for obsolete equipment very good however. There only two things i consider less than optimal: The time from obsoletion of one vehicle to introduction of the next is sometimes very short, or even in the same month. This causes huge costs in a very short timeframe, since all vehicles have to be replaced within about a year, the impact on the network is also extreme. (afterall it takes sometimes two months to get from the depot to the route.)

If a vehicle isn't sold anymore, support with parts by the manufacture continues for a little while, there usually is also a used market. The costs shouldn't therefor immediately start to increase so steeply. Maybe you could give a grace period of one or two years, change the cost increase from linear to positively curved, with saturation. (historical trains are very expensive to operate, but the costs are still limited)(did you already implement an upper limit, i can't remember?)

An alternative way would be to alter the packset to allow more overlap, pushing the date of obsolence one, two or even three years back. Since it would be an overall change for all vehicles a script can easily do it, so hardly work for The Hood.

jamespetts

Sdog,

thank you for the feedback - that second method seems more sensible overall (there is indeed already a cap (configurable, about 600% of base cost currently, if I recall correctly) - it may need to be lowered).

Which particular vehicles had you found had too short an overlap? This issue is not, I suspect, universal.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

sdog

At one occasion i was playing with pak brittain in the time frame of the late steam age, roughly beginning in the thirties, i had mostly problems with different buses having to be replaced. I couldn't remember the name, and don't have the savegame anymore. More than one type was problematic however. The steep increase of bus prices was also aggravating my problems.
(most of my problems however, were probably caused by the first version of the physics engine, since only two trains could actually pull anything, therefore i continued to use the crocodile electrics years past obsolence)

The other occasion was with pak128, i only could set up a profitable setup in the epxerimental version i used by plane routes. However when the DC3 was about to retire, all new planes were to expensive to buy at about 1 million. I just couldn't make so much profit in the 10 to 15 years i had.


sorry for being rather vague about it, but i think the games happened las autumn, or even summer.

jamespetts

SDog,

thank you for the information. I can't do much about Pak128, but can you take a look at Pak128.Britain-Ex with the timeline turned off and let me know which 1930s 'busses have their retirement dates too early? It would be very helpful for we busy developers! Thank you...
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.

neroden

Quote from: sdog on April 14, 2010, 10:03:56 PM
the upgrade cost was killing my company in two games with earlier experimental versions. It was mainly a problem with buses however. I consider the very high cost for obsolete equipment very good however. There only two things i consider less than optimal: The time from obsoletion of one vehicle to introduction of the next is sometimes very short, or even in the same month. This causes huge costs in a very short timeframe, since all vehicles have to be replaced within about a year, the impact on the network is also extreme. (afterall it takes sometimes two months to get from the depot to the route.)

If a vehicle isn't sold anymore, support with parts by the manufacture continues for a little while, there usually is also a used market. The costs shouldn't therefor immediately start to increase so steeply. Maybe you could give a grace period of one or two years, change the cost increase from linear to positively curved, with saturation. (historical trains are very expensive to operate, but the costs are still limited)(did you already implement an upper limit, i can't remember?)
"Historical" trains are *OLD*.  Remember, Amtrak operates 50 year old equipment and is only now complaining that it needs to retire it.

Quote
An alternative way would be to alter the packset to allow more overlap, pushing the date of obsolence one, two or even three years back. Since it would be an overall change for all vehicles a script can easily do it, so hardly work for The Hood.
Yes, I have to agree that this is a very good idea.  I've had serious trouble just with the different freight rail cars.  If I set up a network big enough to make a profit, when the 5t cars come out, I barely have time to get the 3t cars into the depot before they're obsolete.  I've actually had trouble replacing all the 3t cars with 5t cars before the 8t cars show up and 5t cars are obsolete.  (Remember how slow the trains can be in this period.)

In the real world, even though the current freight car standard in the US is "286K", there's still a lot of "263K" out there, which is two standards back.  In general I actually suspect that there should usually be two sizes which aren't obsolete at any given time, so that the 3t would only become obsolete shortly before the 8t become available, et cetera.  Some standards lasted longer than others, of course, so it's OK for there to only be one "current" car sometimes.

However, the lifetime of a bunch of the freight cars is simply too short: the 3t cars only have 15 years (!) and the 5t cars only 20 years (!).  This makes it practically impossible to make enough profit to cover depreciation -- these are not high-margin cargos at the best of times.  The 8t cars have a more reasonable 47 year lifespan.

We definitely need longer "overlap" periods.  No vehicle should have a lifespan of less than 15 years, and rail vehicles should generally last at least 25.  Those are minimums.

sdog

on a first glance it looks much better, like the timeline is covered much better.
is it possible that there are some new buses, since i tried it? I can't remember using the AEC Renown. (wich has really good runing costs.) I think also last time i was forced to use an AEC Q2 at some point in time.

Now i'm rather unsure about my memory, but i think that i had a problem with replacing the buses wen AEC Regal ST became obsolete in 1944, that the replacements would become obsolete in 1951 (Guy Arab) at latest. Until 1947 RT-Type gets introduced. so i had to replace buses twice in 6-7 years.

Since you had upgrading integrated, is the Regal ST suposed to be upgraded to STL?

The other difficulty was when Gloucester Railcars, and the twinsets were discontinued in January 1957 and 1955 respectively. A replacement BR Class 104 DMU is only availabe in September 1957. Since the Gloucester Parcel car runs until 1959 there shouldn't be a reason for the Gloucesters'  maintenance to become higher. Even if BR retired them probably in 1957 probably it would still be sensible to increase Swindon Twinset and Gloucester Railcar lifespan until 1958 or 1959.

The Hood

I think there is a difference here between experimental and standard which is causing confusion.  All the intro/retire dates were designed for standard as dates in which you could purchase the vehicle, not their operational life (for example we have HSTs still doing the rounds on our network which are 35 years old, no-one would build a new one today but they are still operational).  In experimental, am I right in thinking costs go up from after the retirement date?  In which case, all retirement dates in experimental should be increased to a reasonable operational life rather than purchase timeframe.  Better still, have a third date included which is an obsolecense date, after which vehicles rack up increased costs which equates to the end of service life for the vehicles, and keep the retire date as currently in the dats for the date after which you can't purchase the vehicles any more.

neroden

Quote from: The Hood on April 15, 2010, 07:22:31 AM
I think there is a difference here between experimental and standard which is causing confusion.  All the intro/retire dates were designed for standard as dates in which you could purchase the vehicle, not their operational life (for example we have HSTs still doing the rounds on our network which are 35 years old, no-one would build a new one today but they are still operational).  In experimental, am I right in thinking costs go up from after the retirement date?
Yes.
QuoteIn which case, all retirement dates in experimental should be increased to a reasonable operational life rather than purchase timeframe.  Better still, have a third date included which is an obsolecense date, after which vehicles rack up increased costs which equates to the end of service life for the vehicles, and keep the retire date as currently in the dats for the date after which you can't purchase the vehicles any more.
Seems reasonable, but it's more work for James.  :-)

Until very recently, in "standard" you could still purchase obsolete vehicles, period.  In fact, there has to be config option enabled in order to prevent the purchase of obsolete vehicles, and I think it's not enabled by default.  So I suspect most of the people thinking about obsolescence were playing experimental.

sdog

i don't think puting a third date into the dat files would be sensible. afterall it's not a fixed retirement date after which maintenance costs explode. Perhaps a much better approach would be to base the excess maintenance on a vehicles age. Make this age dependent on vehicle type, with buses and lorries having the shortest lifespan other rolling stock longer lifespans. After the time is over maintenance will increase.

When buying a vehicle that's not in production anymore, it's life will be shortened to the obsoletion date.

Examples:
Bus has a lifetime of 10 years. Bus production is stoped in 1980. If you buy it in 1978 you still can use it until '88 with normal maintenance, after that it's maintenance will slowly increase. If you buy the same model in 1985 it will get more expensive in 1990 still, not in 95.
As it is now, it's not very reasonable to buy a vehicle that'll become obsolete in a few years.

The advantage of the proposed system is that it can be implemented in code, instead of changing a lot of dat files. It also makes more sense than a fixed date.

ps.: at the Hood, maybe you want to move the later part of this thread (after reply #9) to the xperimental forum? That is if you think it's to confusing to mix pure experimental issues here with the pak britain issues.

jamespetts

This needs some careful thought, and I am grateful for everyone's input. Some time ago now, when I was first developing obsolescence, I raised the idea of obsolescent based on age. A vehicle's actual age is indeed stored already in Standard, so it would be fairly easy to accomplish.

However, an objection was raised, which I thought reasonable at the time, which was that, if a vehicle's maintenance costs increased with age, it would introduce an unacceptable level of micromanagement into the game in the following way: suppose that one has a line with 10 vehicles in 1960. The number of passengers grows, and every year between 1960 and 1975, one buys two new vehicles. They all have a lifespan of 20 years. In 1980, one has to replace the original 10. Does one then have to remember to come back every year and replace the remaining two for the next fifteen years; or does one replace them all early, and waste a lot of their value?

The idea of obsolescence as currently implemented (incidentally, Simutrans-Experimental has never prevented players from buying obsolete vehicles, and has only recently merged in the Simutrans-Standard code to allow this to be done in simuconf.tab) is obsolescence of type, rather than natural entropy of particular vehicles. As types cease to be supported by manufacturers and/or become obsolete by design, maintaining them becomes progressively more expensive.

Currently, in Pak128.Britain, retirement dates are largely based on when vehicles were actually taken out of service. This is probably not a good idea. Although it makes sense for introduction dates to be based on when vehicles were actually brought into service, the same does not apply in reverse: often, vehicles were taken out of service before they were obsolete (consider the APT), and often vehicles were taken out of service long after they were obsolete (consider the Routemaster 'bus). Latter day steam locomotives are a particular conundrum. Locomotives such as the BR 9F were retired after only 8 or so years of service, at most. They had plenty of life left in them, and could easily have carried on into the late 1980s. But steam locomotives were, arguably, already obsolete by the 1960s. British Railways was very slow on the uptake with diesel in the 1940s and early 1950s, before suddenly declaring in 1955 that steam should be abolished (the last steam locomotive being built in 1960). The running costs of steam locomotives were increasing enormously during that period for economic reasons (the cost of labour vastly increased, and steam locomotives are extremely labour intensive). That economic change was permanent, and had a fundamental impact on the way in which railways were run (steam locomotives had been getting relatively more expensive to run in the pre-ware period in any case, although railways could still turn a decent profit running steam during that time: that was not so by the 1960s, and urgent and drastic changes were required to stem vast losses being made by British Railways; there was an imperative to replace steam with diesel and electric traction).

To simulate this is somewhat difficult, as, to achieve the increase in running costs, the locomotives need to be made obsolete in the 1960s, or start with higher running costs to start with (but, if they do that, when they are made obsolete, their running costs will be out of proportion with other steam locomotives that were made obsolete earlier). However, a design introduced in the second half of the 1950s will not be very attractive if it is made obsolete in 1960. The current solution is to have them made obsolete on the dates on which they were actually withdrawn and hope for the best, but I cannot help thinking that that is somewhat unsatisfactory.

Does anyone have any thoughts on how, in general, to approach these issues?
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.

kierongreen

Regarding obsolescence dates primarily these are used to stop the depots getting too crowded. Keep that in mind when asking for longer overlaps.

sdog

#20
QuoteHowever, an objection was raised, which I thought reasonable at the time, which was that, if a vehicle's maintenance costs increased with age, it would introduce an unacceptable level of micromanagement

I was thinking something similar, right after my post i remembered how horribly annoying the system used to be in TTD. In recent open TTD versions the vehicles get auto replaced when they age. It seems to me a waste of resources to have a complicated ageing system and another complicated automated system to deal with it. Doing it the same way, as openTTD did, would be completely pointless in simutrans, with it's higher degree of abstraction.

Perhaps the first question we have to answer is a more philosophical. Is the bus we see in the game a representation for single physical, individual entity, or is it a placeholder for any indistinguishable bus? Or maybe a placeholder for a bus route of many buses, with diferent in-game buses just representing the capacity of the route?

i) If the representation is direct, of a physical entity, the only sensible way would be basing costs on individual age. I think a solution avoiding the nuisance TTD had is quite possible.

ii) If we don't have the direct representation -- a lot in simutran's approach to abstraction would speak for this view -- basing the system on vehicle age would not make a lot of sense. We can argue replacing the whole bus is already included in the maintenance cost, wich is just an average for all vehicles. In that case maintenance should increase after it's obsolence date.

QuoteLatter day steam locomotives are a particular conundrum. ...
I don't have a solution, beside scripting it. Either in vehicles dat files, or a gerneral file, comparable to speedconfig dat. Detailing maintenance multipliers for different engine types. I don't think both would be sensible. It would mean a lot of work, and it would address one of many very specific and unique real world phenomena. Some things are just way out of the scope of a model.

If a more complex economy would be introduced, an approach to model it in a very straigthforward way would be to assign every vehicle personel. Time dependent labour cost would then fix it automatically. But this would mean an immensely more detailed economic model.


Comming back on the first section of my post, i think for both views are uncomplicated and sensible approaches possible.
for i) the way could be to increasing the maintenance costs only very slowly with time and also reduce the timespan after which this effect starts. So unlike your example set the time for a bus not to 20 years but to 8 or 10. then it slowly gets more expensive. Maybe if it's 15 years old it should be 5% or 10% more expensive than a new one. The buses bought during different points in time will all have different maintenance costs, but the effect is not that strong that it really requires immediate replacement.

for ii) keep the maintenance increase based of the obsolence dates that are used in paks right now. But it would be neccessary to either introduce a grace period of roughly 1/2 vehicle lifespan. (8 years for buses?) and start to ramp up the maintenance then. Or abandon a linear increase of maintenance costs and introduce an exponential increase with saturation at factor 2 or 3. In this case too, should the cost increase not be really noticeable for half a vehicles life span.

As it is at the moment, the game becomes rather hard to play due to a strong replacement pressure and moreover it causes a lot of the annoying micromanagement.

EDIT: went over the text again to make it a bit more comprehensible.

jamespetts

Sdog,

thank you for your careful and interesting analysis. I don't have time to respond fully now, but I should be extremely interested in anyone else's views on these issues. One thing to note is that I am hopeful at some point this year of getting hold of some quite detailed real-world data about vehicle (especially rail vehicle) running, purchase and maintenance costs that might cast some light on how to approach some of these issues.

Thank you again for your thoughts!
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.

The Hood

I agree with kierongreen, especially given the very large number of vehicles already present in pak128.Britain.  Depots get very clogged, and this is not user-friendly.  Doing anything which increases the clutter in the depot is a bad idea IMO.  Hence the period of time in which a vehicle can be bought (without using the show obsolete function) should be limited.

For the following discussion, I think it best to define some terms:
introduction date: the first date at which the vehicle becomes available for purchase
production end date: the last date at which the vehicle becomes available for purchase (broadly similar to the retire date in current simutrans standard)
obsolecense date: a date after which maintenance costs for the vehicle increase sharply

I would still strongly argue for the current system in standard (the standard economic model tends to create a natural obsolecense for older, slower vehicles over time anyway without increasing costs in real terms).  For experimental, I would have three dates as defined above.  I think this is the best solution as it allows the pakset author to define sensible service date ranges for each vehicle.  So routemasters, HSTs and the like could have an obsolecense date for long after the end production date to reflect the fact that these vehicles provide(d) a valuable and viable service long after their introduction.  In the case of HSTs, it would even be possible to combine this with the "upgrade" feature so that it makes economic sense to upgrade existing fleets to life-extend them, as is likely to happen with the HST fleet in the UK.  They mostly already have brand new engines which outperform their originals, and further major work is suggested for them to keep them going into the 2030s, i.e. 60 year service life!  On the other hand, 9Fs would have very short obsolecense dates after introduction to reflect the fact that they were already old technology when built which quickly became uneconomical, even though the machines themselves were perfectly servicable.

I don't know how the increase in maintenance works currently, but I would suggest it increases gradually (or even exponentially) over time after the obsolecense period, so that to start with it's not so bad but eventually becomes too much.

The only other thing to worry about is how this should be displayed to the player.  Surely BR would not have built the 9Fs if it could see into the future and realise that they would only get 8 years service before being forced to retire on cost grounds.  So if obsolecense dates are advertised, then some vehicles become stupid investments (although it has to be said a lot of first generation diesel units also had very short lifetimes too, so maybe if all vehicles are "bad choices" in the late 50s and 60s then it approaches reality!)

sdog

First of all, i don't know much about british rail, so please correct me if i am mistaken.

Likely british rail is the only, or at least the main customer for train systems as the 9F. It's obsolecence, or rather the manufacturers ceasing to provide spare parts, could in that case be a direct consequence of the rail operator to retire the train, or not to do it. In that case introducing an obsolence date in the pak set wich would cause a harsh increase of maintenance, thus forcing the player to retire the vehicle would be problematic. It would force the player for a management decission for the sole reason that the real operator of the vehicle did so at that point in time.

This is of course different for buses or lorries, they're typically sold to a wide range of users. So it's likely the manufacturer who decides to discontinue support, when to few customers for the product are left, or he want's to force them to upgrade to his new product. I don't know to what degree those signature british buses were sold to the commonwealth, or how independent transport operators outside of london where.

Now back to trains, I think the 9F is a steam locomotive, built in the 60s? Thus an anachronism alredy when brand new? From what i read this seems to me more like a political decission in BR. First they rigidly relied on steam, then they abandoned it completely very hastily. Probably the wages rose in the same time causing the steam engines to be unbearable.
But this would then not be a specific feature of the 9F, but of steam in general. And it was foreseeable in the real world that it would happen.
Having an 8 year lifespan for the engine in game would seem completely arbitrary for the players. If you really want to address what james called a "latter day steam locomotives [...] conundrum" a general cost increase for steam vehicles has to be implemented.

In that case the player will likely refrain from using the 9F at all, or use it mayber for 5 years, or maye for 15 regardless of the cost, as it was probably better as the early diesel engines. It's not really good to force him to repeat the bad management of the past, unless he has knowledge of the history and can avoid it.

wing044

May I add my views to the discussion.

I think it is useful to define 'obsolescence'. The dictionary definition is that something is becoming old fashioned and no longer useful.

Vehicles may be out of date in terms of technology, but they can still be useful. For example, the Leyland Atlantean AN68 was produced 1972-86, its replacement Olympian was introduced in 1980. Therefore last batches of the Atlanteans are all technologically old fashioned, despite that they are still very much useful for their intended purpose as a passenger vehicle.

Sometimes vehicles don't really become outdated. Think of diesel shunters, there is no compelling reasons for them to be replaced.

The Standard Class 9F is obsolete because it is both technologically old fashioned and also no longer useful due to rising labour costs. However, many countries continued using steam locos into the 70s and 80s.

I think Pak128.Britain should take a more liberal approach and allow players to choose a different outcome. The pak should set the start and end dates for the PRODUCTION of vehicles. However players should be encouraged to use the vehicles in their own different ways.

Lord Vetinari

#25
Quote from: The Hood on April 14, 2010, 07:27:13 AM
It is possible to purchase obsolete vehicles, so if you need more of the LMR carriages for whatever reason, you can still buy those right up to the end of the game if you so desire.  In reality trains have always got longer and heavier over time, especially in the early years of the railways, as comfort and speed increased that required larger carriages for the same number of passengers, which in turn requires longer stations and more powerful engines.  What you describe seems to me to be fairly accurate - part of the challenge of the early years ought to be in keeping your network up to date to take advantage of the faster speeds offered by newer vehicles, which includes signalling and platform changes...

Sorry to go back this much.
I know it's realistic, that's why I talked about realism vs gameplay. In Simutrans we have some gameplay limitations and/or mechanics that doesn't apply in real life, so my point is that being too realistic with vehicles sometimes can be a boomerang in gameplay terms, especially when playing Simutrans Standard.
For example, in RL adding a couple of feet to the platforms of a station doesn't increase it's catchement area (which in Simutrans can have effects on the whole network).
Curves and tunnels are another limit too: in RL there are a lot of station on curves, or stations that are half in a tunnel and half in open air, both because they were born that way or because of later upgrades. In Simutrans, however, we can't build stations on curves and diagonal tracks (nor it can be easily fixed, I remember Prissi discussing this proposal), nor on tunnel entrances, and destroying half of a city to lay down windy tracks to accomodate longer platform is a little bit of an extrema ratio, especially if the amount of passengers doesn't require it. Given my experience, the core engine of Simutrans seems programmed for a linear increase of vehicles capacity and capability.
Also, older vehicles earn less as the speed bonus doesn't apply after they became obsolete.

I'm willing to upgrade my network as new needs arise (more passengers, city growth, etc.), that's part of the fun of the game, but I think that I shouldn't be forced to do that if nothing has changed.

jamespetts

We have some very interesting discussions here, that raise quite a large number of inter-related and complicated game balancing issues. I shall start with SDog's philosophical question (is the 'bus representative of a single, specific 'bus, or a number of 'busses in the abstract?). I don't think that there is a single clear answer in Simutrans, as I suspect that it has been developed without minds being concentrated on that question, but I tend to think that the way in which Simutrans works goes towards the latter, the more abstract interpretation. Individual vehicles do not break down or get taken out of service for overhauls or to be refuelled. They seem to represent a number of abstract vehicles serving the same diagram. Steam locomotives, after all, need to spend a very large proportion of their life being maintained (having their tubes cleaned out, their fireboxes raked, etc., then the 3-10 hours to fire up the things in the first place after every such episode), and the only way to represent that in Simutrans is to increase the running costs to account for the notionally lower availability (and consequent need to have more actual locomotives). That would then seem consistent with the current mechanism of increasing maintenance costs with obsolescence.

As to the complexity of the economic model, if I were writing a game like this from scratch, I wouldn't put the actual purchase and maintenance costs etc. in the individual vehicles' data files. Instead, I'd have those figures calculated from an abstract value in the vehicles' data files specifying the unskilled labour, semi-skilled labour, skilled labour, materials, fuel costs, etc. for each, and then having an economic model that factors those various costs over time (either by interpolating between pre-defined values, as with the speed bonuses, or using a semi-randomised model). However, we are not starting from scratch, so we have to be somewhat more conservative: we only have limited programming resources, and limited pakset engineering resources, which need to be focussed on producing something that balances well sooner rather than later. The challenge is then making something that works without taking too long to program (and debug) and then implement (and balance and re-balance) in the paksets. Simplicity is to be preferred in so far as it balances properly.

SDog's and Kieron's comments would tend to suggest that there is much merit in beginning to increase the obsolescence cost sometime after the obsolescence date, as doing so would allow for a shorter vehicle availability window (and thus a less crowded depot) without subjecting players to excess (and perhaps unrealistic) early replacement pressure. This makes sense in another way, too, in that it makes sense to go on using vehicles of a particular type long after it stops making sense to build vehicles of that type new. Combined with the new feature prohibiting the purchase of obsolete vehicles (from Standard), this might add interesting things to the balancing mix. As The Hood pointed out, upgrading in Experimental can also be used to add depth to this feature.

However, when looking at implementation in depth, this could get very complicated. Firstly, I understand from an expert in the field (railways in particular, but I suspect that it applies to most things) that the upkeep costs of vehicles form what he called a "bathtub curve" (imagine a conventionally shaped bathtub in profile). In other words, not only is the cost increase when obsolete capped, but it is also exponential rather than linear, and new vehicles also cost more to run than mature but non-obsolete vehicles (and the image of a bathtub suggests that the cost of new vehicles is equivalent to the cost of obsolete vehicles). The reason that new vehicles have higher costs is because they often have initial problems that are, after experience in use, fixed with minor modifications to the design. So, in Simutrans, if a vehicle becomes available in 1950, but nobody buys one until 1955, does the cost begin to fall from 1950 or 1955?

Further, as The Hood asks, how should this be represented to the player? Should it all be obvious, or hidden? If it is obvious, it might make certain decisions a foregone conclusion; but if hidden, users who had played the game before would know it all in any case (and likewise users who look at the .dat files). Should it be randomised? If so, there would then potentially be a departure from the practice of using real-world numbers wherever possible. I tend to take the view that it is somewhat futile to try to hide things from users that can easily be found by having played in the past or by looking in the (open source) .dat files, and so try to balance things such that there are at least some good reasons to buy each kind of vehicle. For example, steam locomotives, although much more expensive to maintain, were probably a lot cheaper to build (I am awaiting real-world data on that one). Furthermore, I am about to implement a feature in the next version of Simutrans-Experimental that will involve different sorts of depots for different types of traction: players would have to buy a new type of depot (expensive to buy and maintain) to be able to build diesel locomotives, which would not allow them to buy or upgrade steam locomotives, which would be an additional incentive to continue using older technology even if not otherwise economical.

Returning to end dates, one possible way of doing it is to have a specified gap between the "retirement date" and the "obsolescence date", a specified time lapse to the maximum cost increase, and a maximum level of cost increase. But should these be set in each individual .dat file (a lot of work), or universally in the code (inflexible)? Perhaps there could be a default setting in the code (or simuconf.tab) that could be over-ridden by individual .dat files where there is a desire to create an exception; but should the default setting be a single, universal default, or should it be different from ships to road vehicles, from steam locomotives to electric multiple units, etc., and, if so, what should the different defaults be? Should the increase be linear (easiest to code and understand), purely exponential, exponential then linear, or exponential, then linear, then logarithmic (as in a true bathtub curve)? Similar considerations apply for new vehicle cost increase.

Turning to Wing's comments about the concept of obsolescence, this, too, is complicated, as there are lots of different reasons why older vehicles cost more to maintain. Firstly, they just plain wear out. As, as discussed above, Simutrans uses an abstract concept of vehicles, this is difficult to model directly, but can be approximated by using time lapsed after the last date on which they could possibly have been built new, especially if the time during which they could have been built new is quite a narrow frame. Secondly, older types of vehicles do things in old-fashioned ways, which are no longer current practice, and do not fit easily into modern maintenance regimes: they would need special sorts of spare parts, special tools, people would need special training to use them, etc.. This would cost more. Thirdly, the spare parts would be harder to come by: eventually, that entire type of spare part might have to be built specially as a one-off rather than bought off the shelf. This would greatly increase the cost. Finally, economics may have changed, such that (for example) a labour intensive machine that was once economical becomes uneconomical due to the greatly increased cost of unskilled labour.

Turning finally to Lord Vetinari's points: I am not sure what is meant by Simutrans being programmed for a linear increase of vehicle capacity and capability. For a long time, Simutrans-Standard has used speedbonus.tab instead of the average of current vehicles to determine the speed bonus, so the increase can be as linear or non-linear as one likes. Whilst it is true that it can be harder to squeeze in infrastructure to densely populated areas in Simutrans than in reality, I think that, in the context of the issue raised about vehicle lengths and capacities, the issue is somewhat marginal: the game would not be realistic if one didn't have to lengthen one's platforms at some point in the 19th century (and would be impossible to balance if it required having the same platform length from start to end).

Thank you to everyone for the detailed feedback on this issue; I should greatly appreciate everyone's thoughts on what I have written here.
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.

Lord Vetinari

#27
Quote from: jamespetts on April 17, 2010, 03:56:40 PMTurning finally to Lord Vetinari's points: I am not sure what is meant by Simutrans being programmed for a linear increase of vehicle capacity and capability. For a long time, Simutrans-Standard has used speedbonus.tab instead of the average of current vehicles to determine the speed bonus, so the increase can be as linear or non-linear as one likes.

You're right, I didn't explain myself, sorry. I ment that, in my experience, the gameplay is smoother if each vehicle generation is somehow faster, powerfull and can carry a little bit more passengers than the previous ones, while I feel that there are some big gaps in the early years of Pak Britain.
Another small example, this time is the opposite of the previous one: in 1847 Jenny Lind becomes available and suddently I can run 8 tiles trains at full speed without any problem, when all the previous engines could pull only a 3 tiles train at full speed and the Patentee alone could manage to pull a 4 tiles train whith a bearable speed penalty.
From Jenny Lind onward, there will be no problems at running full length trains (24 cars in the consist is the maximum limits) until 1870.

Again, I understand that those gaps are historical facts, I'm just looking at the gameplay side of the question.

Quote from: jamespetts on April 17, 2010, 03:56:40 PMWhilst it is true that it can be harder to squeeze in infrastructure to densely populated areas in Simutrans than in reality, I think that, in the context of the issue raised about vehicle lengths and capacities, the issue is somewhat marginal: the game would not be realistic if one didn't have to lengthen one's platforms at some point in the 19th century (and would be impossible to balance if it required having the same platform length from start to end).

Sorry, that's not what I ment. The game doesn't know that it's 19th century (or, better said, it works exactly the same way in 19th and in 21st century).
As soon as I expand the network and/or connected cities grow, there will be "natural" reasons to update the infrastructures, way before the end of the 19th century, as the amount of passengers will rise, thus requiring trains with more cars. This is perfectly fine, it's fair game challenge. I'm saying that is not good gameplay to force the player to expand the stations just to have the same amount of cars that carries the exact same amount of passengers as before (especially given that, in game terms, the size of the station is related to the catchment area and doesn't just affect the amount of cars that can load and unload there).

neroden

Quote from: Lord Vetinari on April 18, 2010, 04:55:30 PM
You're right, I didn't explain myself, sorry. I ment that, in my experience, the gameplay is smoother if each vehicle generation is somehow faster, powerfull and can carry a little bit more passengers than the previous ones, while I feel that there are some big gaps in the early years of Pak Britain.
Another small example, this time is the opposite of the previous one: in 1847 Jenny Lind becomes available and suddently I can run 8 tiles trains at full speed without any problem, when all the previous engines could pull only a 3 tiles train at full speed and the Patentee alone could manage to pull a 4 tiles train whith a bearable speed penalty.
From Jenny Lind onward, there will be no problems at running full length trains (24 cars in the consist is the maximum limits) until 1870.

Again, I understand that those gaps are historical facts, I'm just looking at the gameplay side of the question.

It all behaves rather differently in experimental due to the different physics engine and the much larger number of cars allowed in the consist.  In the early years I run humungous 32-car horse-drawn goods trains, so I have 4-tile stations already; by the time Jenny Lind comes in, it can't haul much more than 5 tiles worth of goods cars at full speed (which is a *lot* already)....

So I guess I'm just saying, be aware that pak changes may have totally different behavior in standard and experimental.  I suspect we're stuck with this for quite a while, it's just worth remembering.


jamespetts

Lord Vetinari,

I know that, traditionally, Simutrans paksets have indeed had every generation of vehicle faster, more powerful and more capacious than the last (not necessarily in a linear way, however), but I'm not sure that that's necessary (possibly not even with Standard).

Returning to your original issue, it may well be that phased obsolescence as discussed above is the only sensible way of dealing with it: you would at least then have more time during which to upgrade your infrastructure. I am not sure what else could be done without breaking things.

As to the gaps, it may be that more research is needed. I notice that the Jenny Lind has four times the power of the next most powerful locomotive (the SDR Derwent) when it is introduced. I am not sure whether that is realistic or not - I do not know where those figures came from. It is hard enough to get accurate information about the tractive effort of very old steam locomotives, let alone their power. It might be that either some new locomotives need to be added, or the power of existing locomotives tweaked to more realistic values, if these are known or can be inferred. I notice in particular that nowhere that I read about the Jenny Lind does it suggest that it revolutionised rail transport, which suggests that it probably was not four times more powerful than the next most powerful locomotive at the time.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

The Hood

A lot of the early rail vehicles have complete guesses for power, and this discussion indicates the guesses may need to be changed.  The other thing I found when researching is that there is very little information on locomotives between the 1840s and 1870s - most sources I could find either discussed very early locos (like the lcoomotion and rocket) or picked up the story when longer, faster trains became more common (e.g. the Stirling single etc.).  I reckon there are some gaps early in the timeline, so if anyone can make some suggestions for locos in that period, I'll happily add them.

In any case, a major rebalancing of the standard pakset is long due, but I'm waiting to have sea and air vehicles done so I can get the balance between all of the properly.

jamespetts

#31
If anyone has the first clue where to find more accurate information for rail locomotives in the all elusive 1830-1870 time period (I've checked Wikipedia, and no doubt so has The Hood), then that would be much appreciated!

Edit: Pertinent to earlier discussions on the topic of obsolescence: it was not only in the 1960s that steam locomotives were scrapped after only 8 years of service: here is an example of one scrapped after 8 years of service in the 1860s...
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.

AP

#32
Quote from: jamespetts on April 19, 2010, 06:54:20 PM
If anyone has the first clue where to find more accurate information for rail locomotives in the all elusive 1830-1870 time period (I've checked Wikipedia, and no doubt so has The Hood), then that would be much appreciated!

Dare I say it, but perhaps, books ? ;)

There is a huge amount of print material for steam locomotives and railway history. I know, for instance, that the magazine "railway modeller" each month has always had a 2-page-spread on a given historic steam locomotive, with drawings and full stats. And they've been going since the 1950s - so 60years x12 = 700 locomotives detailed.

I'm quite sure if you want to know the weight of a given coach, the tractive power of the locomotive, its acceleration, it's probably documented somewhere. I mean, the working timetables for many Victorian routes still exist, so putting 2 and 2 together isn't too tough by itself.

The trouble, of course, is finding someone with that data, the books or magazines, (because it isn't online!) and, more significantly, the will to collate it. It starts being quite a mammoth research project by itself.

Alternatively, we need to find somewhere where someone else has done it already, and *borrow* the information. Any other UK rail sims?

AP

#33
http://www.steamindex.com/ seems to have quite a lot in the way of referencing, but finding those references might be a mission (since half of them are things like "Railway Gazette 1935 Feb")


Edit: hmm, see what you mean about 1870...
http://www.britishsteam.com/ has a massive database of locomotives at the grouping but no weight/power data.
http://www.railuk.info/steam/ has a searchable database by loco class, but again only based on those surviving at 1923... nothing built before about 1875.

jamespetts

AP,

the idea of books had occurred to me - but, the question is, what books? I don't mind buying a book or two from Amazon if it'll be useful enough, but I don't want to buy book after book on the off chance that it might have a snippet of useful information. I have posted a message in the forum of a model engineering club of which I am a member to see whether anyone there knows; perhaps knowledge will eventually be forthcoming!
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.