Started by moblet, January 05, 2011, 01:24:14 AM
0 Members and 1 Guest are viewing this topic.
Quote from: jamespetts on January 09, 2011, 12:31:29 AMReplacer timetabling
QuoteI'm not sure at present where this one falls; may I ask - what is the incentive of having vehicles go to be replaced at a particular point in their schedule?
Quote from: The Hood on January 08, 2011, 05:55:14 PMI like the ideas regarding overhauling
Quote from: The HoodI would also suggest that subsequent overhauls become ever more expensive otherwise you could still feasibly have steam puffing away in the year 2000.
Quote from: JamesDo we really need increasing maintenance costs as well as periodic overhauls to have the economic effect of balancing the excessive profit drivers for established games?
Quote from: JamesIt would be quite easy, however, simply to remove the code that charged monthly maintenance cost to vehicles in a depot. Is this advisable, do people think?
Quote from: Jamesa simple charge per ton would be closer to reality than what we have at present
Quote from: sdogconvoys from competition automatically incur the cost at the competition, not the player owning the road. This should make integration with standard when money is transfered for way usage.
Quote from: sdoglinear relation ships are per se easier to understand to players than non linear. This is especially true if the linear behaviour is contrary to people daily experience. (example maintenance of a car.) The actual relationship doesn't even have to be displayed in the game, as in reality it isn't transparent either, without research. A CEO or a car owner can dig up some statistitcs, papers or hire Moblet to find it out
Quote from: JamesWe do indeed need to balance all of these things, too: the next element of balancing vehicle power/weight/speed is in relation to steam railway locomotives, although some work needs to be done on boats as well, I understand. Balancing goods prices against each other is a more tricky affair (any thoughts, anyone, on how to go about doing that in as realistic a manner as possible?)
QuoteI think that it's important to maintain a conceptual distinction between [...] [actions that do] not require vehicles to be sent back to the depot [...][things that] should require a depot visit
Quote from: JamesAs to sigmoid curves, from what I understand, the reality is that a vehicle's maintenance cost is actually more like a bathtub curve
Quoteafter all, in reality, the board of directors set the dividend; what incentive in Simutrans would a player have ever to pay a dividend?
Quote from: mobletIn the sim we debit an amount of money from the player and the unit is guaranteed not to fail, but it would not be realistic to charge the player the equivalent amount of money that would achieve 99.9999999% reliability in real life
Quote from: Jamesa vehicle's maintenance cost is actually more like a bathtub curve
Quote from: sdogThe increased maintenance cost should already address the costs of the frequent overhauls a new vehicle needs.
Quote from: sdogbalancing alone will not be sufficient to get a challenging game in all phases of the game
Quote from: sdogjust assume it is in a universe where everything always takes the expectation value
QuoteI agree. James, what you've outlined sounds to me like it has enough levers to mimic real-world dynamics, and none that are redundant. By my count that gives us four parameters that must be uniquely specified for each vehicle:1. Fixed monthly cost $/month2. Maintenance charge $/km3. Operating cost $/km4. Overhaul frequency /kmWe'd also have two game-wide parameters1. Overhaul cost % of capital cost2. Something to increase overhaul or operating cost as the vehicle agesIs that right? If some vehicles had more expensive overhauls than others then more frequent overhauls can serve as a proxy for this.
QuoteI'm pretty sure we do, otherwise we don't get the economic working life dynamic. Flat maintenance charge + flat price overhauls means that an overhaul returns the vehicle to new condition and at overhaul time, the decision is a simple choice between paying the cost of a replacement vehicle or paying the cost of an overhaul (the next overhaul will be due at the same time regardless). The overhaul is much cheaper so it is always the better option, leaving working life determined purely by obsolescence, not age. If an overhaul returns a vehicle to new condition then it should cost as much as a new vehicle.It doesn't really matter whether increasing the maintenance charge per km or the overhaul cost that is used to increase maintenance cost with age, but as far as I can see (about 50cm without glasses) it is redundant to vary both. I think the maintenance charge is the better one to vary, as it is charged continuously so gives more control over game-play. As for increasing costs further once the unit is obsolete, again in principle it wouldn't matter whether this was done either way, and it shouldn't need to be done both ways. If the maintenance charge was a linear or otherwise increasing function then overhaul costs wouldn't need to increase and all that coding around obsolescence would become, well, obsolete. Even if the maintenance charge was sigmoid it could be set to level out at an uneconomically high rate so overhaul costs could still remain constant.
QuoteI have a few thoughts on balancing and how to progress it, continuing on the benchmarking theme. The notion of balancing implies that there is a set of circumstances under which competing options will come out equal. We can exploit this property to generate balanced parameter sets in a semi-automatic fashion, by throwing all the fundamental performance and cost parameters into a single spreadsheet, and linking them with appropriate formulae. The demands of balancing mean that, for example, if we change the power output of a single loco for historical accuracy but don't want that to alter the balance of the game, its cost performance parameters should automatically adjust to compensate for, and effectively cancel out, the change in technical performance. This is easily handled in a spreadsheet, and adding a new vehicle to the pak can be accommodated by adding a line to the spreadsheet and matching up the new unit's parameters. We could, if necessary, include revenue assumptions so as to balance out things like speed advantages. Basically such a spreadsheet would be an extension of the comparison one I attached in a previous thread, and is something I can work on. First though, I need to get hold of the .dat file(s), which I don't know how to find/isolate. Can someone point me at them?For balancing goods prices, it's important that a player has roughly equal prospects regardless of what industries appear, since that's outside the player's control. That gives us a benchmarking target, so we shouldn't have to flail about too much on this one either. The balance can be upset by altering the productivity of an individual factory type, or the configuration of a supply chain, so I'm seeing another spreadsheet that contains factory, supply chain and price assumptions and helps us adjust them towards benchmarks that equalise financial outcomes between supply chains.It might take us a few iterations of spreadsheet versions, and many iterations of adjusting numbers, to complete the job, but this is the only controlled process I can think of for arriving at a balanced set of game parameters. It integrates performance and cost and allows us to progress on both fronts simultaneously. As repositories of assumptions the spreadsheets would also facilitate discussion and collaborative effort.These tools should also be equally useful to developers of other paksets.
Quote from: SdogThe idea here was not having such highly reliable equipment, but that one of the vehicles in the game is a token for a small fleet of vehicles. Which would just get replaced or fixed as they break. This should be integrated in the maintenance cost. (If you want just imagine at one of the stops they just replace the vehicle and send it back while the other one continues seemlessly and invisibly. So we can just look at an average. This also makes your japanese car problem much easier, as we don't have to look at one that can cause random costs but on the average for a large enough set. This is a really nice thing, when confronted with random events, get enough of them :-). If you want to go back into the displayed single vehicle picture again just assume it is in a universe where everything always takes the expectation value.
QuoteJust realised we have two concepts of balancing flying about here, and perhaps reason to further bifurcate this thread. One balancing concept is early vs mature game (make it easier to survive at first and more challenging to prosper later on), the other is the relative profitability of cargoes/modes/vehicles (so that choices between modes and vehicles are realistic and intuitive). These are independent concepts. I melded them somewhat at the beginning by suggesting that some currently absent real world dynamics are needed to address the former, and these would impact on specifying the latter. In an effort to clarify which is for what:Balancers aimed at making early play less costly and mature play more costly:1. Age-based maintenance costs2. Fixed time-based vehicle cost (coded)3. Variable way maintenance costsBalancing cargoes/modes/vehicles:Build a couple of spreadsheets to contain all the vital parameters, linked by formulae, to easily adjust the relative technical and financial performance of cargoes, modes, and vehicles. Most, perhaps all vehicle and way parameters will need to be included in these spreadsheets, so the spreadsheets will have to change to mirror consequential coding changes (e.g. maintenance cost curves).
Quote from: JamesI thought that the point of overhauls was to de-amortise long-term vehicle wear maintenance so as to enable per unit of distance maintenance charges to be balanced such that the vehicles have to earn enough over a considerable period of time to pay for their overhauls later on?
Quote from: JamesIs the point that there is also some other mechanism that dictates a necessity to have increased basic maintenance charges throughout a vehicle's life-cycle?
Quote from: JamesIt is common practice particularly on the railways to cascade older vehicles to less and less significant duties until they become completely obsolete before retiring them.
Quote from: JamesI rather suspect that flat maintenance until obsolescence and flat overhaul charges create incentives closer to the real world than ever-increasing maintenance charges for non-obsolete vehicles that cannot be reduced by overhauls.
Quote from: moblet on January 09, 2011, 01:43:34 PMYes, and the reason they are cascaded to lighter duties is because they cost relatively more to run and are less reliable. Their new duties are usually characterised by high tolerance of breakdowns and low mileage, which translates into poor utilisation that weighs against investing new capital. 4. Degrade the performance of old units, encouraging the player to move them off the busiest lines. They would also become incapable of synchronised service with newer units.
Quote from: The HoodBuses in the UK often get used only for 7-10 years, but I think that is mainly an "image" thing - the buses themselves still work I think.
Quote from: moblet on January 10, 2011, 06:13:14 AMand encourages cascading to lighter duties.
Quote from: jamespetts on January 05, 2011, 01:53:52 PMThat's an interesting suggestion: have the years/months on the existing system, but the hours/minutes on the same measure as journey times? That might work.
Quote from: jamespetts on January 09, 2011, 11:43:37 AM(1) identify precisely what changes are needed to the base code;(2) implement those changes;(3) set up a spreadsheet to give basic balancing parameters for different types of vehicles and infrastructure on the basis of the model outlined in (1) (can be done concurrently with (2) if done by a different person);(4) balance the physics of steam locomotives (and possibly boats)*;(5) balance industry production/consumption ratesl(6) implement an initial run at the balance specified in (3) (can be done simultaneously with (4) and (5) if done by a different person;(7) test the balance in game;( make further adjustments to the balancing formula or its implementation;(9) return to (7).
QuoteOne of the tricky things here is that by the time a vehicle gets old, the technology of new ones has improved, and I don't have a great sense of how that pans out in the sim. All the same I don't see how the balancing can work without a mechanism that limits a vehicle's economic life on a usage basis.
QuoteWe should think beyond rail vehicles, too, as rail vehicles have longer lives than most of the other vehicles in the sim. The typical commercial lifespan of trucks, aircraft, and bulk carriers is shorter. And come to think of it with rail vehicles, we see 50yo units in service and tend to assume that all units built 50 years ago would still be economic to run. Is that generally the case or were they just the over-engineered or underutilised ones?
QuoteI don't know if it has been mentioned already, but, generally, the life expectancy of trams and buses is about 20~25yrs.
Quote from: nerodenIt did not really work if we don't include convoy mass in calculations. I believe for locomotives fuel consumption will be quite different with empty/full convoy.
Quote from: nerodenI think the first code change which needs to be made is a saner treatment of time, distance, and speed in simutrans. Which I'm working on, with difficulty.If we can figure out the number of ticks in a "vehicle hour", then with a standard definition of 1 km = some number of tiles, Bernd's physics model should hold us in good stead
QuoteThe second thing which is needed is appropriate ("realistic") weight, power, tractive effort, and air/water resistance numbers (and capacities, but I think those are good) for buses, lorries, boats, and ships. (For ships these may be somewhat different from reality for "realistic" behavior, because ships float in water and all that.) The third is realistic weights (and capacities, but I think those are good) for railway wagons and carriages. The fourth is appropriate power, tractive effort, and air/water resistance numbers for railway locomotives.
QuoteWhat's that sound that I hear? The distinctive clunk of a can of worms being opened, I think! This issue goes to how we compute the various elements that go into the per kilometre running cost. If we imagine that per kilometre maintenance cost accounts for fuel plus regular wear-based maintenance, then increasing the per kilometre cost by a function of the load hauled and/or speed would increase, effectively, the charge for maintenance as well as fuel, and I am not sure that it is accurate. (If it so happens that the per kilometre maintenance costs increase in about the same way with speed/load as fuel consumption, then that is very convenient, but I rather suspect that they don't).
Quote from: jamespetts on January 11, 2011, 12:22:42 AMa number of intriguing conclusions can be drawn as follows:(1) the sigmoid curve is the one that starts out the shallowest and ends up the steepest;(2) the flat rate model currently in Standard is a long way behind all the others in varying incentive by use;(3) the obsolescence model is very similar to a combination of flat plus linear degradation (because that, in effect, is what it is); and(4) the obsolescence model is better than the linear increase in providing differential maintenance cost at the beginning and end of a vehicle's life.
Quote from: JamesThis is getting very complicated!...I'd very much like to see (1) a combination of the sigmoid and obsolescence; (2) a combination of overhauls and obsolescence; (3) a combination of sigmoid and overhauls; and (4) a combination of sigmoid, overhauls and obsolescence
Quote from: JamesAs to affecting performance, I am somewhat sceptical of this idea: what measure of performance would be affected? Vehicles do not generally get slower as they age, nor take longer to accelerate, nor become able to haul less weight
Quote from: JamesOne thing to consider: when a vehicle comes to the end of its economic life in reality, almost never is it scrapped and replaced with a brand new but otherwise identical vehicle: it is always replaced with something newer in design, and I do not think that this is a coincidence.
Quote from: JamesIs it not the case with most commercial vehicles that, obsolescence aside, a sufficiently heavy overhaul can generally restore them to something close to an as new condition for less money than actually buying a new one, and that the only reason that new vehicles are, in fact, bought is either that the improvements in the design of the new ones make it worthwhile or that the old ones are in some way obsolete that make them relatively less economic to run now than they were when new?
Quote from: JamesWhat's that sound that I hear? The distinctive clunk of a can of worms being opened, I think! This issue goes to how we compute the various elements that go into the per kilometre running cost. If we imagine that per kilometre maintenance cost accounts for fuel plus regular wear-based maintenance, then increasing the per kilometre cost by a function of the load hauled and/or speed would increase, effectively, the charge for maintenance as well as fuel, and I am not sure that it is accurate.
Quote from: JamesSo, we are then faced with adding a further layer of complexity, and, importantly, a further parameter that all Experimental pakset maintainers will have to add to all powered vehicles (including the vast number of vehicles in Pak128.Britain). Because of the large cost of doing this, we need to be very, very sure that it is worth the cost; I'd be interested in thoughts on that issue (especially given that developers concentrating on this will preclude us from doing other things in the same time).
Quote from: sdogIf you really want realistic, instead of game-balancing, values for the costs, just drop the costs altogether.
Quote from: sdogMoblet, are costs for material (steel, wood) or for spare parts significant for the overall maintenance costs?
Quote from: sdogPlease also remember there has been quite a change in the way vehicles are maintained. Spare replacement units are only something relatively new, started in WW2. Before only single spare parts were bought, and often almost everything was fixed themselves.
Quote from: jamespetts on January 24, 2011, 12:15:30 AMthe best approach is to start by working out what we need to model, then thinking about how we model it.
QuoteRail speed limits depending on signal spacing (requiring the player to balance speed and capacity carefully)
QuoteWhat I was driving at here was to step back a bit further and look at the complete picture, and to then assess every proposal in the context of the complete picture. [...] Doing it this way means we are aware of what real-world dynamics we aren't including, and therefore what implications that holds for executing the included ones.
Quote from: james- Variable brake forces for vehicles (vehicles with lower brake forces having to start braking sooner)- Rail speed limits depending on signal spacing (requiring the player to balance speed and capacity carefully)
Quote from: moblet on January 24, 2011, 01:42:48 PMIs there, among the Experimental documentation, a brief but comprehensive list of what dynamics are modelled? Not just of what's unique to Experimental, but of everything. That would be one starting point.
QuoteAnother process would be to start a very rough sketch of the dynamics that one might consider including if one was building a sim from scratch, e.g:Macro-economicCost of capital, or interest rateInflationMarket cyclesMicro-economicCapital vs operating cost trade-offWear on permanent wayFixed & variable operating costsDepreciationCredit rating & loan arrangementsDemographic.Supply Chains.Right-of-way.Physics.etcThen we can assess and sort these into two buckets, "include" and "don't include". Doing it this way means we are aware of what real-world dynamics we aren't including, and therefore what implications that holds for executing the included ones. We may also:- be able to think of ways to compensate for some of the omitted dynamics- find that some of them can be adequately captured within another dynamic and therefore don't require coding- be able to proceed in such a manner that we include the dynamics we know we want to include, with a design that allows us to easily add any or all of the dynamics that we aren't yet sure about, should testing reveal that we need them.
QuoteAs I'm sure you've discovered, some dynamics crash into each other too, for example if train braking distances are able to exceed signal spacing it creates potential problems that require effort to be put into thinking and coding to solve problems instead of enhancing the game. If we see these kinds of conflicts coming we can save ourselves having to solve problems post-haste, and our best chance of spotting these conflicts is to keep the system view in front of us at all times.A first question on this: in the real world, if the next signal is red, the present signal is a caution with a reduced speed limit. Has that dynamic been entertained in Simutrans development?
Quote from: sdog on January 24, 2011, 07:05:28 PMExperimental already has quite a large amount of new features. A consolidation phase would be quite good for it now. Moblets approach is quite good there. Perhaps this process should also critically review features already implemented and consider if they are required for the model, represent the reality you want to simulate and what they cost (cpu time, balancing effort, playability). Being quite skeptic there and perhaps having some hard choices could mean quite an improvement or easier development in the long run.
Quote from: jamespetts on January 26, 2011, 09:36:00 AMNo, there is no such list, either for Standard or Experimental. I'm not sure how one would go about compiling such a list - what exactly would count as a dynamic modelled? One couldn't just list features, as many or even most dynamics might well be emergent properties of multiple features, some of which may be very complicated, and some of which unintended (and, of those unintended, some may be desirable and some undesirable).
Quote from: JamesThe approach that I have taken so far when working with Experimental is, starting from Standard, to examine, after having played Standard for quite a while, where players are incentivised to make decisions that are substantially deviant from the decisions that they would be incentivised to make were the world of Simutrans the real world, then try to find what element of the simulation of reality is missing and fill it in
Quote from: JamesYour approach so far seems to have been to ask the slightly different but equally useful question of what elements of the simulation of reality are missing such that player profitability is distorted, excessively favouring established players over new players, which seems like a good way to continue.
Quote from: JamesI am not sure how one would go about listing all dynamics modelled in that way. If you'd like to have a go, however, I'd be interested to see what you come up with.
Quote from: JamesThe difficulty with this approach is that it may well not take sufficient account of the very real resource management issues that we have in developing Simutrans-Experimental that make adding each substantial new feature take many months of implementation in the code, testing, bug reporting/fixing and then implementation (if applicable) into the pakset and further reporting/testing, during which time the game is relatively unstable, and fewer people incentivised to play it (meaning fewer people testing the other features, fewer people being drawn into the Simutrans-Experimental player community, thus reducing the pool of possible future developers, etc.). I wonder whether we need a balancing spreadsheet for developers!
Quote from: JamesIn practical terms, we need to look at making the minimum changes necessary to acheive a functioning economic model (unless we can find a few skilled developers with lots and lots of time on their hands who are able and willing to dedicate much of it to Simutrans-Experimental and its paksets). That is why, I think, the approach has to be to ask "what dynamics is Simutrans-Experimental missing without which critical features of the economy cannot be simulated, resulting in significant distortions that render balancing impossible"? Being parsimonious with the features will allow us to build a better Experimental within a reasonable timeframe. Larger changes may be able to come later, when Experimental is more established and there are more developers able to dedicate their time to it.
Quote from: JamesNo - there seems to be a general reluctance amongst Simutrans users to increase the complexity/depth of the simulation of railway signalling.
Quote from: JamesI have been trying to have a consolidation phase for quite a long time! The difficulty is that significant balancing or playability issues are found in testing which then require substantial changes to the code to be made.
Quote from: JamesThis is why I suggest the parsimonious version of the above, asking which critical dynamics are omitted the absence of which makes good balancing impossible. We can then implement the minimum of new features necessary to enable balancing to work properly, and concentrate otherwise on increasing stability and producing pakset assets, tuning and testing.
Quote from: AEOChallenges that cities might ask your company to do, like linking up their town with other towns and meeting a minimum average speed for that line within an allotted time frame for a reward.
Quote from: moblet on January 27, 2011, 11:12:01 AMMight have to list both "dynamics" and "features" and see how to line them up. Every feature of the game should have been put there to represent, or help represent, some dynamic, or to help the player manage that dynamic.
QuoteI think that is a very useful exercise but is unlikely to produce a good outcome, or do so efficiently, if adopted as a development approach. It's a bit like the boy racers who bolt something on to their car to make it go faster, then bolt something else on, then bolt something else, but then their car keeps breaking because they never thought about whether each component can support the increased performance demands. Or, for another analogy closer to home, the difference between one's Simutrans city expanding in a controlled fashion, where one sets out the street grid and provides transport infrastructure (or at least the space for it), or whether the sim is allowed to bolt on streets and buildings wherever it likes without thinking about how the whole city is going to function. In the latter case some of what was built ends up having to be knocked down in order to produce an acceptably efficient city, and there is conflict between keeping what's established and having an efficient city.
QuoteThat is not my approach, that is just one of the balances that I think the game needs to strike. My approach, in as few words as possible, is to see the forest, and see every tree in the context of its place in the forest. Right now I feel like we're just running from tree to tree.
QuoteHappy to start, but is only worth doing if a view of the forest will actually get used.
QuoteThis is ultimately why I'm proposing this approach. Bolting on a substantial new feature just because it seems like a good idea and it's the tree in front of us, without an objective assessment of whether it is the best use of programming resources, or a clear vision of whether it is even relevant to the ultimate goal, carries a major risk of wasting effort, and wasting effort is a pretty good way to demotivate volunteers. We do indeed need a balancing, and prioritisation, process for development, and it falls under the "project co-ordination" task. If you see yourself as the co-ordinator of the Experimental project, then this is your job, and it's one of the most important tasks you have. You can delegate evaluation and design work but "seeing the trees and the forest" cannot be delegated.
QuoteThis is a natural occurrence when dynamics aren't coded faithfully and efficiently, i.e. in such a way that playability issues can be resolved at the parameter level. Solution: more thoroughly think through how something is going to work, and how it can be tweaked, when designing it; try to generate multiple viable designs and evaluate them against these criteria.