Topic: Alternative ways of handling obsolesence

[jamespetts]

Before I start coding in respect of some thoughts that I have had in respect of an improved way of handling vehicle obsolescence, I should be interested in people's reactions to those ideas. By way of background, obsolescence is currently defined by a "retire_date" in each vehicle's .dat file. After that date, the vehicle does not appear in the depot window to buy (unless one selects "show obsolete"), and any line with an obsolete vehicle serving it is marked in blue. Ever since the speed bonus has been read from a file, those have been the only two practical effects of obsolescence in the game. A short while ago, I released a patch for the code that reduced the effect of the speed bonus on local journeys, and also increased the running costs of obsolete vehicles (phased in over time starting from the date of obsolescence and ending with a date specified in simuconf.tab).

However, when recently working on some .dat files for 'busses for PakBritan, several shortcomings of the current method of obsolescence handing (with or without my patch) sprung to mind. Firstly, no distinction is drawn between the date on which a vehicle stops being produced as new, and the date on which a vehicle's service life expires: very often in reality, a vehicle's useful life extends well beyond the time that production of that vehicle ceases. It can then be difficult deciding which date to use as the retire date in the pak file. Secondly, no account is taken of the actual age of the vehicle: if one buys a brand new vehicle in October 1965, and the vehicle's retirement date is in November 1965, it is treated in just the same way as if one had bought the vehicle new in January 1940. Thirdly, there is no way to refurbish an obsolete vehicle to extend its life: either the vehicle is new or it is obsolete, and that is the end of it. Finally, the consequences of obsolescence did not seem significant enough.

An alternative possibility is this: instead of determining obsolescence by the retire date, set instead in the .dat file a "service life" variable, in years. The vehicle would then become life expired that many years after it was first bought. For example, if a vehicle had an introduction date of January 1950 and a service life of 20 years, it would become life expired in January 1970 whatever the retirement date (i.e., whatever the date on which the manufacturer stopped making it). A player would then be able to "refurbish" the vehicle. That would extend its life by an amount specified in the vehicle's .dat file (a default value of half its service life being specified for vehicles with older .dat files). While the vehicle is still in production (i.e., before the retirement date), it would be able to be refurbished an unlimited number of times. After production of that vehicle ceases, it would be able to be refurbished only once. The cost of refurbishment would be specified in the .dat file, and a value of half the purchase price would be the default for older versions.

To minimise micromanagement, there would be an option to refurbish all vehicles of the same kind at the same time. The vehicle detail window would give, in addition to the date of purchase, the date of life expiry and whether the vehicle is still in production. There would be a "refurbish" and "refurbish all of this type" button in the vehicle details window, with the respective costs of doing so below each.

The concept of a vehicle being obsolete because its production has ceased would be replaced by a concept of the vehicle being life expired. There would be no consequences to running a vehicle that is no longer in production: all the consequences would attach instead to running a life-expired vehicle. The vehicle's .dat file would give the option of specifying modified features (running costs,and gear) for life expired vehicles, to simulate the extra work that might be needed to keep it going, and the extent to which the mechanics can keep a life expired vehicle working as well as a new or refurbished one. Finally, life expired vehicles should, after a certain amount of time (perhaps 1/3rd of their service life again after they become life expired, phased in progressively from the moment of life expiry) be unable to earn any speed bonus (or, with my speed bonus patch applied, any local bonus, either), although they would not necessarily receive a negative speed "bonus" unless their actual top speed warranted it. The sale price of vehicles should also be affected by whether they are life expired, and, if so, by how much.

This system ought be intuitive and straightforward, and easier to understand than a system that conflates life expiry with cessation of production. It should also give players more interesting decisions to make about whether to refurbish older vehicles or buy new ones, as well as giving players a greater sense of attachment to their vehicle fleet as representing more tangible assets that depreciate over time.

[Combuijs]

Hmm, well, something that needs an explanation this size is too complicated for me  :. I don't like the micromanagement needed for this solution.

[jamespetts]

Hmm, well, something that needs an explanation this size is too complicated for me  :. I don't like the micromanagement needed for this solution.

If one explains anything in great detail, the explanation will be long, even if the thing itself is relatively simple.

I could simply have written: instead of vehicles becoming obsolete at their retirement date, they will have a service life set by the vehicle's author. If they are older than their service life, they will be life expired, and will cost more to maintain, and may perform worse (details will be set by the vehicle's author). Life expired vehicles will also not get a full speed bonus. Vehicles can be refurbished, which will extend their life (again, details such as the cost of refurbishment set by the vehicle's author). They can be refurbished any number of times before they go out of production, but only once afterwards. Vehicles can be refurbished individually, or all of a certain type refurbished at the same time.

Can you elaborate on why you think that that would involve additional micromanagement to the present arrangement?

[emaxectranspoorte]

Vehicles can be refurbished, which will extend their life (again, details such as the cost of refurbishment set by the vehicle's author). They can be refurbished any number of times before they go out of production, but only once afterwards. Vehicles can be refurbished individually, or all of a certain type refurbished at the same time.

Can you elaborate on why you think that that would involve additional micromanagement to the present arrangement?

What about if a player has enough (makes enough) money, shoudn't they be able to refurbish them every now and then? For the same and/or any other old vehicle. Like in "reality".

Anyway, just thinking ...  :-\

[Fabio]

Although it would need a whole new GUI, i would really like a Fleet management window. It would show all your vehicles, in tabs according to their type, and grouped/groupable by line, life, etc...
There, with simple buttons, you could send them to the nearest depot to refurbish and, once done (let's say one simutrans month) back to service, move a vehicle from one line to another, sell one vehicle and replace it with a new one. These operations could be ordered also for a group of vehicles.

This idea is far beyond the purpose of this topic, but it would definitely reduce the amount of micromanagement needed.

[Combuijs]

Can you elaborate on why you think that that would involve additional micromanagement to the present arrangement?

For every vehicle I use, I have to decide every certain period (say a year) whether it should be kept as it is, or should be "refurbished" or should be replaced by something new. So if I'm having 500 convois, I have to make about 1000 decisions (one for the engine, one for the wagons) every year, which means 1000 calculations. Well, that's what I call micromanagement.

I have to admit, your proposal is more true to life then the current implementation. On the other hand, if I had a big transport company in real life, a full unit of people would be implementing the vehicle-manegement. Unfortunately I have no full unit of people available when playing this game (but you might volunteer  ).

[jamespetts]

Combuijs,

hmm, perhaps you have misunderstood the idea? I am not sure why you would need to make a decision every year about whether to refurbish any given vehicle, any more than, as things stand at present, you need to make a decision every year about whether to replace any given vehicle. Certainly, the intention was that players would not be troubled with thinking about refurbishment under the proposed system any more than they are troubled thinking about replacement under the current system, but, when they do have to think of replacement, they would have a new option: refurbishment. Is there a particular reason that you think that players would have to consider whether to refurbish for each vehicle in each year? From what I can see, it would only be necessary to think about it (1) just after the vehicle has become life expired (one should be told with a ticker message), and (2) just before it goes out of production (perhaps there should be a "vehicle of type xxx will go out of production on one year" ticker message).

emaxectranspoorte,

the reason that I suggested only one refurbishment after the vehicle went out of production is to simulate the fact that there comes a time when any given vehicle simply becomes too obsolete to keep going indefinitely, and further refurbishment will not help. If one was allowed to keep on refurbishing a vehicle indefinitely, then one would be able to continue using a 'bus that went out of production in 1925 in 1985 without any sort of penalty, which is both unrealistic and lacking sufficient challenge for the player.

Fabio,

very interesting idea. Not a necessary prerequisite for the implementation of this one (which could be done, as stated in the original post, using the vehicle details window), but might be worthwhile on its own. I am not sure that vehicles should have to spend a month being refurbished, though: after all, when one buys them new, one does not have to wait a month for them to be delivered.

[Fabio]

For every vehicle I use, I have to decide every certain period (say a year) whether it should be kept as it is, or should be "refurbished" or should be replaced by something new. So if I'm having 500 convois, I have to make about 1000 decisions (one for the engine, one for the wagons) every year, which means 1000 calculations. Well, that's what I call micromanagement.

In a way, avoiding this is the purpose of my fleet management idea...

very interesting idea. Not a necessary prerequisite for the implementation of this one (which could be done, as stated in the original post, using the vehicle details window), but might be worthwhile on its own. I am not sure that vehicles should have to spend a month being refurbished, though: after all, when one buys them new, one does not have to wait a month for them to be delivered.

thank you! for the month, you're totally right, although i would really like them to need to go to the depot and immediately after to leave refurbished...

[Combuijs]

I am not sure why you would need to make a decision every year about whether to refurbish any given vehicle, any more than, as things stand at present, you need to make a decision every year about whether to replace any given vehicle

Perhaps you don't understand the consequences of your own idea  ?

To give you an example:
Say I have one truck line transporting coal from a mine to a power station. The first year I start with one vehicle, the next year I add another one, a year later I add another two, and still a year later I add another four, to make a total of eight vehicles servicing this line. It then works to full capacity, e.g. everything that is produced can be transported. (This is by the way a very efficient algorithm to get to the right capacity for a certain line). I'm a happy transporter then, from now on this line works as best as it can, and there is no need to look at in detail every time (just take care there is not too much coal left from the mine, and that no vehicle gets stuck).

Now with you proposal after some years the first vehicle starts performing worse and will cost more. The latter will probably go unnoticed because the line as a whole makes a healthy profit still. Worse performing might however lead to a chain of trucks lingering behind the vehicle, which might affect the whole transport system. So the line that was taking no extra time from me, is now jeoparding the whole transport system, and I must make a decision now what to do. No problem to do that for one line, but for a hundred lines you are getting crazy (very slowly, but still...)

[jamespetts]

Perhaps you don't understand the consequences of your own idea  ?

To give you an example:
Say I have one truck line transporting coal from a mine to a power station. The first year I start with one vehicle, the next year I add another one, a year later I add another two, and still a year later I add another four, to make a total of eight vehicles servicing this line. It then works to full capacity, e.g. everything that is produced can be transported. (This is by the way a very efficient algorithm to get to the right capacity for a certain line). I'm a happy transporter then, from now on this line works as best as it can, and there is no need to look at in detail every time (just take care there is not too much coal left from the mine, and that no vehicle gets stuck).

Now with you proposal after some years the first vehicle starts performing worse and will cost more. The latter will probably go unnoticed because the line as a whole makes a healthy profit still. Worse performing might however lead to a chain of trucks lingering behind the vehicle, which might affect the whole transport system. So the line that was taking no extra time from me, is now jeoparding the whole transport system, and I must make a decision now what to do. No problem to do that for one line, but for a hundred lines you are getting crazy (very slowly, but still...)

That should be dealt with by the gradual phasing of the effects of life expiry. If, for example, the running costs were set to increase by 300% and the performance reduced by 15%, the reductions would not take full effect the moment that their life expired: they would instead be phased in over a period of perhaps five or even ten years. In the first year, the running costs might increase only by 30% and the performance degrade only by 1.5%. So, with your line of vehicles added over a period of four years, you would not have to replace or refurbish each individual vehicle as it became life expired: you could replace or refurbish all the vehicles in that line at once when some of them were one or two years' life expired, and other were about to become life expired, or, refurbish all of them when the last one has become life expired, etc.. Is that worse than suddenly having to replace all vehicles of a certain type scattered throughout the network on dozens of lines every time that a particular sort of vehicle goes out of production?

[VS]

You don't replace vehicles when they go out of production. You merely stop buying them.

Replacing takes place when you get a new, better option.

[isidoro]

I think we have here some mixed concepts:

• On one side, the question of a vehicle not being produced any more => cannot be bought any more
• On the other side, degradation or, if you want entropy
• Finally, a fleet management tool

Will the player have to deal with degradation?  Only for vehicles?  Why not for stations, roads, etc.?  Shouldn't those be refurbished as well?  Only degradation with time and use?  Why not disasters: earthquakes, tsunamis, volcanoes, etc.?  And what about breaking down?  And accidents?

Up to now, degradation is kept apart from simutrans and is under the concept of "maintenance cost".  All those have been denied before.  Degradation, if at all, should be something automatic.  If wanted, either the vehicles loose performance (a) or increase maintenance (b) with age or both.  But then, if replacement is automatic, there will be unexpected costs.  And if not automatic, as Combuijs says, you can't have a static situation, you have to replace/refurbish things once in a while.  With big maps, it can mean doing nothing else.

Also the fleet management tool has been denied before, although I don't agree here.  A good fleet management tool will do no harm, but has to be good 

[jamespetts]

Isidoro,

the concepts are already mixed in the current game: the idea of obsolescence, until recently, automatically took the vehicle out of being counted as part of the average speeds of vehicles for the bonus (now, it is done manually, but usually based on the average speeds of non-obsolete vehicles). The purpose is quite clearly to penalise players who use vehicles that are too old. But a vehicle being too old is not the same as a vehicle that is no longer manufactured: public transport vehicles (especially non-road transport) often greatly outlive their manufacturing window. It is confusing for pakset authors and players alike to have a single date for a vehicle no longer being produced and being too old to be used without a penalty of some sort. The question when deciding what date to put as a vehicle's retirement date when modelling a real vehicle (for example, the London Routemaster 'bus) is often a difficult one: does one take the date that they stopped being manufactured (1968)? Or the date when they were (mostly) withdrawn from service (2005), by which time they were arguably already many years obsolete? Or some arbitrary date between those two points? Why should a vehicle purchased in October 1965 be regarded as obsolete and carry the penalty of obsolescence in December 1965 because production stopped in November 1965? If lines with obsolete vehicles are to be highlighted in blue, after all, obsolescence must mean something.

The position is different for ways and stations, since they do not become obsolete (as far as I am aware). It is the fact of obsolescence that means that older vehicles have to be upgraded with time: there is an element of micromanagement there in any event, no doubt present because that particular sort of micromanagement was considered fun (and, I think, correctly so). (The reality is that, stations and roads/track, unlike vehicles, are not usually replaced wholesale, but upgraded bit by bit, which is no doubt why there is no retirement date for those sorts of assets).

So, if micromanagement of vehicle fleets to handle the replacement of vehicles that are too old is considered acceptable (and, indeed, desirable), subject to being able to be turned off by disabling the timeline, it makes sense that adding an additional element of choice to that micromanagement (refurbishment) would, if the option makes sense in gameplay mechanics and realism terms, be a good thing, and likewise if the choices were made against a realistic and gameplay-meaningful background of the life expiry of vehicles. To put it another way, the idea is not to increase the number of times that players have to think about how to deal with obsolete/life expired vehicles, but to make the choices that they have when they do more meaningful and interesting.

To deal with the point about additional micromanagement raised by Combuijs earlier (with the example of a number of vehicles of the same type bought over a period of time), if having to plan ahead and buy vehicles with their eventual replacements in mind is not considered desirable, an alternative method of dealing with the original suggestion would be for vehicles not to become life expired during the period when they are still manufactured, no matter how old that they are, on the basis that it would be easy to obtain spare parts for them if they are still being made. After they stop being manufactured, vehicles over the service life would become life expired straight away (but the consequences phased in from the date of cessation of manufacture, not the (earlier) date of life expiry), but younger vehicles still within their service life would still be fully serviceable with no penalty until their service life had expired.

There could then be a warning one year in advance (on the ticker) before any vehicle goes out of production, so that players could decide to refurbish them once just before they go out of production, to allow them to refurbish them once more afterwards to maximise their working lives, as newer vehicles are not always necessarily better. Additionally, these various possibilities could all be coded, and set as options in simuconf.tab, to give players and/or pakset authors maximum flexibility.

[prissi]

Micromanagement to replace vehicles (like needed in TTD) is the result of very bad game design to hide shortcomings and the fact that only seven engines are available. I will never ever include this micromanagement nightmare into simutrans. Simutrans has good enough gameplay and challenges without forcing onto the user this kind of micromanagement.

The aim of simutrans is to provide transportation. If one feels the income (or capacity) of a line is too low, then it is up to the user to update that connection. But as written further up: A static connection should be working the same for all times (with the exeption of the income).

[jamespetts]

Prissi,

why is income an exception, but not running costs? The shortcomings of the speed bonus with local transportation have already been discussed, the summary of which discussion is that the speed bonus system alone does not work properly for local transport. Once one disapplies the speed bonus to local transport, there has to be an alternative way of penalising obsolescence. The question is then how one defines the obsolescence that one is penalising: should it simply be based on when the vehicle is no longer manufactured, or should actual age be relevant, too? Ought players have the opportunity to extend the lives of vehicles rather than replace them? It is that chain of thought that has given rise to this proposal.

Can I ask - do you think that my proposal would involve players having to micromanage more (i.e., have to consider the question of obsolescence more frequently than they do now)? If so, there is some error in my design that I have not spotted, as I specifically intended that there would be no need for players to have to consider obsolescence more often, just have more interesting and meaningful choices to make when they do consider it. If you do not think that players would have to consider obsolescence more frequently, might I ask why you think that, nonetheless, micromanagement would increase, and what you mean by "micromanagement" if you do not mean to refer to players having to make more frequent decisions?

[prissi]

Your suggestion of vehicle slowing down after some time certainly require additionally micromanagement (MM) to keep line capacity which constant production.

Simutrans as a game should be as much a possible free of any MM. MM is usually introduced when there are serious shortcomings in gameplay (like the missing challenge in original TT due to no destinations, giant margins and bad AI). In such cases MM keeps the player busy but with "useless" stuff.

I personally (and Hajo too, as far as we talked about that) saw Simutrans more like chess and less like civilisation or simcity (to name some other games with heavy MM). The challenge is to provide transportation. If you ever filled a 512*512 map with decent connection for every industry and every town (i.e. owning more than 2000 convois and moving millions) you do not want to be hapered by MM. This is challenging enough.

And income is infofar no exception, since it does only matter in the beginning and is deterministic, i.e. is the same for every vehicle of the same type. Furthermore, at the beginnign obsolete vehicles play no role at all, since they are not in service long enough.

As the "obsolete date" (why inventing new names here, btw?): These are in most paks the date from first appearance to end of service. Most vehicles were only built a few years (less than five typically) but where is service often ten times longer. To avoid empty depots, the retire date (not obsolete by the way) is set the the, well, date of retirement from active service.

[jamespetts]

Prissi,

thank you for your reply :-) I see the point about vehicle performance requiring reconsideration of the schedules/capacity of the line as a whole - but that part is not integral to the basic idea. The performance stipulations can be removed, leaving only the additional running costs, which would still be worthwhile in itself. If the performance degradation element was removed, would there be any additional micromanagement involved in my suggestion (i.e., any increased frequency of player interaction with the vehicles or related matters)? I cannot immediately see any. As originally stated, the idea of this proposal was specifically not to increase micromanagement, but to make what elements of management (micro or otherwise) that there already is more interesting and realistic. Indeed, I considered specifically that point at great length before positing the proposal, so I am concerned at any suggestion that it gives rise to additional micromanagement (and concerned to find modified versions where potential for additional micromanagement is identified, as above).

As to "obsolete dates", I use the word "obsolete" because it is used both in the interface and in the code: in the interface in the "Show obsolete too" option in the depot window, and in the code in simconvoi.cc and simconvoi.h in the "has_obsolete" bool flag. Also, you wrote in this post when I posted a patch modifying the speed bonus in relation to local transport:

I think you are acting against the purpose of the speedbonus, which is making replacemnet of obsolete vehicle more neccessary. Why should it be ok to run hoerse carriages on short lines, but need the newest on longer lines?

I got the impression from that that it is important to create a sufficient disincentive to using obsolete vehicles. "retire_date" may well be the name of the date in the code, but once something is "retired" it becomes "obsolete" by the definitions above, and attracts a penalty (on purpose, as you explain in the quote above). My suggestion was aimed at modifying the handling of that penalty, and giving players extra options in dealing with it, as well as making the nature of the penalty more interesting and realistic.

Somewhat tangentially, I disagree that SimCity and Civilization (SimCity and the latest version of Civilization in particular) involve excessive micromanagement as a result of lacking gameplay. Both are among the very best computer games ever made (in particular the later versions of each), and neither can sensibly be said to be lacking in depth. Some of the earlier versions of Civilisation unintentionally gave rise to micromanagement by design flaws that meant that players who micromanaged in unintended ways gained an advantage thereby, but that has been suppressed considerably in Civilisation IV. What micromanagement that they do have is (for the most part) not excessive, but conducive to a good mix of realism and gameplay.

As to preferring a game like chess to a game like SimCity - it is a matter of taste. Some people prefer one approach, others another, others still some mix of the two. The Simutrans game engine is good enough and flexible enough to accommodate a range of different playing styles from the same basic code, simply by providing the players and/or Pakset authors with a range of options either in the interface or the simuconf.tab file. There need not be any conflict between players who like different styles of play (I, for example, prefer SimCity to chess - but that doesn't mean that I think that SimCity is better for everybody than chess - it's just what I find fun): many different sorts of players can simultaneously be accommodated by providing for options. Any issue as to which features get the priority of coders' time can simply be resolved by allowing individual coders to express their own preferences in setting priorities for their own work: that is the beauty of an open-source project. There is enough common ground in Simutrans to make that worthwhile, and the broader range of players to whom the game appeals, the more potential contributors to the project, and the more that can be done.

[whoami]

I support the idea of not marking vehicles as obsolote as soon as the pre-defined end of production happens. The pak maintainers would then have to add a line in the .dat file for each vehicle, in order to define a suitable suggested end-of-service date.

The actual end of use should depend on the player's choice, resulting from the speed bonus of the time, and other needs like capacity and interaction with other vehicles.
Vehicle degradation need not happen, because the vehicles are always under maintenance, paid for by the deducted cost per kilometer.

[jamespetts]

Whoami,

as discussed here, using the speed bonus alone to deter obsolescence causes real problems with local passenger transport. Some other deterrent must be found. But then it is important to define obsolescence properly, and give players options on how to deal with it (in respect of which, see all the discussion above).

It may be that not all players like that way of dealing with things: that being the case, it can be made optional. But those who want local passenger transport to work properly in terms of revenue and who want a realistic penalty for obsolete vehicles should at least have the choice of something that works to acheive those ends.