News:

Simutrans Tools
Know our tools that can help you to create add-ons, install and customize Simutrans.

Towards a balancing spreadsheet for vehicles

Started by moblet, January 09, 2011, 12:28:56 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

moblet

Quote from: jamespetts on January 31, 2011, 11:18:55 PM
The ROI equalisation/comparison process that you suggest is not, after all, opposed to an historical model of transportation economics in which the ROI is not necessarily equal (and is unequal in a number of specific, important respects, as in the examples), but is a process of ultimate calibration that can work in harmony with it?
It is a historical model of transportation economics.
Quote from: JamesI still think that there is much value in historical research as to prices where possible: the results of that research can easily be used in conjunction with the ROI model to tell us how to equalise the ROI when we equalise it, and when to deviate from it when we need to deviate, whilst the ROI mathematics can keep such deviation within playable limits. Indeed, we can use the ROI model, can we not, to model incentives that we knew were present historically fairly accurately even if we don't have the figures? Have I understood this correctly now?
Yes.
Quote from: James
I assume that all the various steam graphs are on top of each other in the straight line in the middle?
Yes, the steam numbers are all the same so they lie on top of each other. I put them in so that you could compare against different steam costs if you so wished.
Quote from: JamesI have wanted for a long time to be able to model accurately the utilisation incentives with electrification to incentivise players to make economically sensible decisions.
And Simutrans is already halfway towards capturing this. The major missing links are cost of capital (can be done with the interest rate), fixed-vs-variable cost dynamics, and somehow representing the impacts of ageing.
Quote from: JamesPresumably, there are cases on the margins where one doesn't make a loss by electrifying, but also just makes less profit?
Yes, but there is more downside risk in electrifying. Southern needed to make more profit in exchange for that higher risk, and they did.
Quote from: JamesI always think that it is very interesting to see consistent differences over time between players and how they handle the marginal cases, which would be especially interesting to see emerge over a long-term network game (e.g., player A tends against capital investment in cases of doubt, whereas player B tends in favour of capital investment in cases of doubt, consequently player B's network has electrification in places that player A's network wouldn't have them, etc.).
Our goal is make sure the way these strategies pan out is economically realistic.
Quote from: James
Yes, indeed! The next question is how we go about doing that starting from where we are now...
This is where we have so far exhibited a clash of styles. As I said previously my approach is to do two things; identify what dynamics and functionality we really want in the sim, and go back to the Standard engine and compare its capabilities with that list. I did some analysis and asked some questions on the speedbonus and trip profitability the other day, from which emerged some very significant insights:
- Standard was never designed to support timeline dynamics (i.e. playing through history).
- Standard's economic engine was never designed for modular, independent pakset development. Standard's economic assumptions and dynamics are highly simplistic, and do not support the pakBritain philosophy of using historical equipment and numbers.
- Standard is designed to drive replacement decisions by having a pakset offering very limited choices, and introducing new vehicles at intervals with superior performance that effectively compel the player to upgrade. This keeps code and paksets simple, but it is not a true economic model, and it does not support the pakBritain philosophy of offering a wide range of vehicles and having the player select what will maximise profitability on the task at hand.
- Because the assumptions, calculations, and principles for developing paksets have not been documented explicitly, those pakset developers not familiar with the code are flying blind and tying themselves in knots trying to balance their sets. (If paksets are meant to be modular add-ons then the game dynamics need to be articulated in words so that pakset developers can easily learn what they need to learn. They should not be asked to compile the source code in their heads.)
I would not try to address any of the above by simply whacking more complexity on top of the Standard engine. I would first work out what dynamics were essential to the gameplay and pakset development goals, and simple ways to model them, and then compare that with what's in Standard. From there it would be a case of switching off or removing what isn't needed, and adding what is needed. I would describe the Experimental development process thus far as one of building highly complex modules of specific dynamics of unquantified significance, and while it's not a process I believe in, or can contribute to, I recognise that it has a fair bit of momentum, and I don't wish to fragment the community. The nature of an open source project is that what people will coalesce around, will happen. If people continue to coalesce around the current approach then it will continue. If there is coalescence around the idea of stepping back and designing a project version of Standard, whether that's the "Experimental version" or not, from first principles, then it will happen. As you, James, are the driving force behind Experimental, and this is a volunteer gig and a labour of love, it probably comes down to your personal priorities and what's going to be most rewarding for you. Have you identified what rewards you are seeking from your involvement in Experimental, and what would give you the most satisfaction?

jamespetts

QuoteOur goal is make sure the way these strategies pan out is economically realistic.

Yes, indeed - an admirable starting point, I think.

As to the longer part of the post, the discussion of the origins of Standard are very interesting: I was not aware of the early historical setup. Certainly, Standard is too simplified for my tastes (and was evidently even more so in the early days); that is not, of course, to criticise Hajo, not only because tastes in preferable levels of complexity vary, but also because starting a project from scratch to run on the sorts of computers available in the early 1990s requires a greater degree of simplification for practical purposes than dealing with an already established project with numerous contributors designed to run on modern day computers. Nonetheless, the outcomes of making particular sorts of decisions in Standard are sufficiently divergent from reality to mar for me the enjoyment of playing it. That is what I have aimed to rectify with Experimental.

I take the point on documentation: pakset developers and maintainers do indeed need access to a natural language description of features sufficient for them to balance the paksets effectively. The approach that I have taken so far to documentation in Simutrans-Experimental is to document the additional features of Simutrans-Experimental myself, and leave the documentation of features shared with Standard to the existing documentation systems (see here for the Wiki). For the in-game help files, I have modified a great many of them to present a user-friendly, integrated description of Simutrans-Experimental as it stands, but that is aimed at users, not pakset developers. I have done it that way because development resources are not adequate to re-document Standard features in a Simutrans-Experimental specific documentation set. Given those limited development resources and the way in which we have handled Simutrans-Experimental documentation so far, what are your thoughts about the most efficient way to proceed to acheive a level of documentation that is adequate for the purpose of pakset developers, if possible, without duplicating work already done either in this thread or by the documenters of Standard?

Quote
I would not try to address any of the above by simply whacking more complexity on top of the Standard engine. I would first work out what dynamics were essential to the gameplay and pakset development goals, and simple ways to model them, and then compare that with what's in Standard. From there it would be a case of switching off or removing what isn't needed, and adding what is needed. I would describe the Experimental development process thus far as one of building highly complex modules of specific dynamics of unquantified significance, and while it's not a process I believe in, or can contribute to, I recognise that it has a fair bit of momentum, and I don't wish to fragment the community.

Whilst it is often tempting to say, when asked how to reach a particular destination, "I wouldn't start from here", it is from here that we are, in fact, starting, and the destination, in broad terms, is, I hope, uncontroversial. You have already helpfully identified some simulation dynamics missing in both Standard and Experimental whose absence prevents the effective balancing of any pakset in ways such as to make the game challenging but playable over the long term. Those, obviously, need to be addressed: to that extent we are agreed (I do not know what the position of the Standard developers are on that issue). Would the purpose of the exercise that you are suggesting be to identify more such issues (and, ultimately, solutions for them)? Certainly, if there are any other balance-critical issues of that nature, they, too, need to be identified and addressed: Simutrans-Experimental will never really succeed if there are unresolved balance critical issues such as those that you have identified.

Does what you are proposing have any aims beyond identifying balance critical issues and the means to address them? Given that we are where we are, and that the issue at hand is the best route from our current location to our destination, not from some location in which we had found ourselves some time in the past to that same destination, you will, I hope, understand my questioning whether it is necessary to conduct the hypothetical exercise of asking what features we might have added if we were starting with Experimental to-morrow, especially if such an exercise is not a necessary step in removing balance critical issues (a number of which you appear to have identified without undertaking such an exercise), and especially given the resource implications of such a process. (Forgive me, incidentally, if I have unintentionally characterised what I understand you to be suggesting incorrectly).

We certainly can - and should - ask, as you suggest, what dynamics are essential to gameplay and pakset development goals and how best to model them. We have started that process already, and most helpfully, and I hope that we can continue that process. Where I think that we disagree is in the next part of what you suggest, being, if I understand you correctly, to remove any feature which is not essential to pakset balancing.

That a feature is not so critical that it will be difficult or impossible to balance the game effectively without it does not, in my view, make it undesirable that it should be simulated. The view that I take is that, if it adds something positive to the game, there is no reason to remove it. Removing a feature that is already present is as significant a change as adding a new feature, and the presumption should in each case be in favour of the status quo, which presumption is displaced by some good reason to believe that the changed state of affairs (taking into account the cost of making the change) will be a better state of affairs than the current state of affairs. There is nothing in that approach, as far as I can discern, that is in any way incompatible with finding a good and efficient route to the destination that I think that we both share of producing a version of Simutrans that accurately models economic incentives whilst remaining fun to play.

There is also the issue of how to quantify significance. I have no formal training in economics, and so my method of quantifying significance of a dynamic is to look at real transport networks and discern why significant things are as they are: if there are certain dynamics that have a significant impact in reality, then simulating them, if done properly, ought have a more or less equally significant impact in the simulation. I have not had the tools or resources to conduct a numerical analysis of the impact of particular features on the game (indeed, I do not think that this has been done for Standard features, either), but have done the best that I can with the tools that I do have available: historical research and knowledge of what factors were actually significant. I have then chosen what can be modelled effectively without creating excess complexity for the player, code developer or pakset developer or undue computational load such as to impact game performance, and tried to model those dynamics in a way that simulates as closely how the things work in reality as I am able.

To continue with the example of private cars: it is notorious that the ascent of the automobile has significantly changed the fortunes of short and medium distance passenger transportation, and particularly railways. The 1950s-1980s saw a precipitous decline in passenger numbers on Britain's railways, which only began to recover from the late 1980s onwards as a result of a combination of population growth, and, more importantly, the impact of congestion on the relative desirability of travelling by car. I wanted Simutrans to be able to capture this reality and for players to have to contend with the competition from private cars in as realistic way as possible. I wanted players to be in a position to choose whether to take the Beeching approach to the problem (that is, close a great many railway lines), or whether some other alternative would produce a better result. I wanted players to be in the position of having to reduce capacity in the middle 20th century, only to have to increase it again in the late 20th and early 21st century as congestion in towns and cities became an increasing problem. All of these issues are highly significant to real-world transport planning. If they turn out not to be significant in the game, that is not an indication that the feature should be abandoned; rather, that it has not been done properly and should be fixed. Whilst, however, I have not conducted any formal testing of the sort that I think that you mean, I have looked into this feature somewhat extensively, both at the micro level with a debugger looking at individual packets of passengers choosing whether to use a private car or not, and the macro, by seeing in a developed game the numbers of passengers using public transport steadily falling at the appropriate times in history and the levels of traffic concomitantly increasing despite a gradual increase in the total number of passengers generated.

In other instances, I have added features on the basis of providing a realistic incentive to choose different types of vehicles from the range of historically accurate vehicles available in Pak128.Britain: the reversing feature (combined with the weight limit feature) to provide a balance of incentives between tank and tender locomotives, for instance, the catering feature to make it meaningful to provide catering vehicles, and so forth. The significance of these features must be seen in light of that purpose. I find that it detracts enormously from the enjoyment of the game when I know that using a particular type of vehicle in the game will have no benefit, whereas, in reality, it would have a significant benefit. That sort of significance is just as good a reason to have a feature as the significance of balance criticality.

Quote
As you, James, are the driving force behind Experimental, and this is a volunteer gig and a labour of love, it probably comes down to your personal priorities and what's going to be most rewarding for you. Have you identified what rewards you are seeking from your involvement in Experimental, and what would give you the most satisfaction?

What would give me the most satisfaction is the continued development of Experimental and Pak128.Britain-Ex to a point where delightfully intricate historically plausible transport networks emerge from players simply making decisions that are economically sound in game terms, without consciously trying to give the appearance of historical plausibility, in which there is a thriving playing and developing community (ideally involving additional paksets at least some of which have similar goals) and lengthy persistent multi-player games where players variously compete and co-operate with each other, all the while producing realistic and realistically characterful transport networks that change gradually over time in much the same way as real transport networks so change. This, of course, would require Simutrans-Experimental to simulate the necessary economic ingredients to balance properly, which is, in my view, a necessary but not sufficient condition of achieving that goal, a goal which, I hope, is not mine alone.
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.

jamespetts

Quote from: neroden on January 10, 2011, 09:42:04 PM
EDIT: If you're going to work on balancing, I suggest working on infrastructure maintenance costs first.  I am really unsure how to balance them properly, but every good way of balancing vehicle prices depends on balancing infrastructure maintenance first.  :-P

I know bridge prices need to be scaled to the scale because elevated track prices are, that would be a start...


I have now done this in my latest commit to the 9.x branch.
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.

moblet

Quote from: jamespetts on February 02, 2011, 08:36:17 PM
Standard is too simplified for my tastes
It is for mine too, but some semantics are in order here. Say, for example, "Standard's economic model is not realistic enough", not "Standard is too simple" or anything that might convince you that Experimental can only exceed Standard by being more complicated, and/or that it will exceed Standard performance in exact measure to the extent by which it exceeds Standard's complexity. I would try to get everything we want from Experimental with no greater complexity than Standard - probably not possible, but that's my goal.
Quote from: JamesGiven those limited development resources and the way in which we have handled Simutrans-Experimental documentation so far, what are your thoughts about the most efficient way to proceed to acheive a level of documentation that is adequate for the purpose of pakset developers, if possible, without duplicating work already done either in this thread or by the documenters of Standard?
I have no magic bullets on this one - must confess that documentation's never been one of my strong points - but firstly I want to make sure we document our decision making as we work through the design. I would say though that before any new feature is coded, or any code is revised, a plain language version should be worked up and circulated on this forum for discussion. Once finalised it forms the instructions for whoever's coding, part of the technical documentation, and raw material for writing help files and manuals for players and pakset builders.
Quote from: James
Whilst it is often tempting to say, when asked how to reach a particular destination, "I wouldn't start from here", it is from here that we are, in fact, starting, and the destination, in broad terms, is, I hope, uncontroversial.
Where I would always have chosen to start from, for the purposes of examining Standard's missing dynamics, is Standard. Standard is still here, so that's where I propose we start from.
Quote from: JamesWould the purpose of the exercise that you are suggesting be to identify more such issues (and, ultimately, solutions for them)?
We have to make sure we don't overlook anything, and also that we remember to document everything we include or exclude. Step one for me is to list the dynamics of Standard, highlight the ones we've thought about changing with the reasons why, and put that to the community to see what the collective thought process comes up with. This is different to asking the wide-open question of "what do you want in Experimental?" and should focus thinking on the dynamics and throw up anything we've missed. I would be very uncomfortable proceeding on the basis of only what I've thought of.
Quote from: JamesWhere I think that we disagree is in the next part of what you suggest, being, if I understand you correctly, to remove any feature which is not essential to pakset balancing.
I didn't mean specifically pakset balancing, and I forgot to articulate all the steps in my thinking. Where I'm coming from is the need to make the sim as computationally light as possible. The real world doesn't have to be computationally efficient, but Simutrans needs to be. So in considering how to model each dynamic, the computational cost of each option has to be considered. One reason for developing multiple options to choose from. We could probably safely assume that an 80/20 rule applies here - one can get 80% of the dynamical accuracy with 20% of the computational workload, and end up consuming four fifths of the computational load trying to perfect the last 20%. The same would apply to the parameter count. I'm hoping we can get ourselves a great sim without having to cross that 80% line too much.
Quote from: JamesThe view that I take is that, if it adds something positive to the game, there is no reason to remove it.
I see that as a cost/benefit equation. The costs are computational effort and complexity confronting the player. There is otherwise no limit to what could add something positive to the game.
Quote from: JamesRemoving a feature that is already present is as significant a change as adding a new feature, and the presumption should in each case be in favour of the status quo
I would more or less agree with this with respect to Standard, for some of the complexities added to Experimental I'd want to do some analysis on their significance before agreeing that they are worth the extra parameters and computations.
Quote from: JamesThere is also the issue of how to quantify significance. I have no formal training in economics, and so my method of quantifying significance of a dynamic is to look at real transport networks and discern why significant things are as they are: if there are certain dynamics that have a significant impact in reality, then simulating them, if done properly, ought have a more or less equally significant impact in the simulation.
Just remember that sometimes the decisions that created what we see were influenced by uncertainties that were present at the time, so it's not always a black and white thing, and also that we aren't likely to be able to model every last real world dynamic. Without these factors a rational player, playing a dynamically faithful Simutrans, might build a world that isn't exactly what we see in reality, but that this isn't a bad thing.
Quote from: JamesI have not had the tools or resources to conduct a numerical analysis of the impact of particular features on the game (indeed, I do not think that this has been done for Standard features, either), but have done the best that I can with the tools that I do have available: historical research and knowledge of what factors were actually significant. I have then chosen what can be modelled effectively without creating excess complexity for the player, code developer or pakset developer or undue computational load such as to impact game performance, and tried to model those dynamics in a way that simulates as closely how the things work in reality as I am able.
The process that doesn't appear to me to have been happening is analysing the behaviour of Simutrans itself as it plays out a dynamic. That's what I propose we start doing now. Turfit just provided an example of the kind of thing I believe we should be doing first: setting up simple, controlled experiments in the sim to observe what happens. So how about we select a topical dynamic, such as electrification vs steam, and contrive an experiment in Standard to see how this choice plays out over time? By comparing Standard's behaviour to our understanding of reality, and to our vision of Experimental, we can best determine how to build from Standard.
Quote from: James
To continue with the example of private cars
To model the competition between trains and cars, I would first lay out some of the modelling options, which range from simple ones like artificially adjusting car demand to match historical figures, to developing a full-on car transport demand model based on costs and congestion. There's no doubt what happened historically was significant, but there's equally no guarantee that a player will make the decisions that set this reality up. E.g., the player might never have provided extensive passenger service in the first place. There's a lot to think through in terms of modelling possibilities.
Quote from: JamesIn other instances, I have added features on the basis of providing a realistic incentive to choose different types of vehicles from the range of historically accurate vehicles available in Pak128.Britain: the reversing feature (combined with the weight limit feature) to provide a balance of incentives between tank and tender locomotives, for instance, the catering feature to make it meaningful to provide catering vehicles, and so forth. The significance of these features must be seen in light of that purpose. I find that it detracts enormously from the enjoyment of the game when I know that using a particular type of vehicle in the game will have no benefit, whereas, in reality, it would have a significant benefit. That sort of significance is just as good a reason to have a feature as the significance of balance criticality.
The impact of reversing can be modelled explicitly, or it can be rolled into the combination of capital/operating/ownership costs. I would have started out with the latter approach, because it's simpler, and seen how that panned out before adding more code and parameters. That also means that I would have laid foundations like the modelling of costs long before thinking about issues like reversing times. I'm going to be ignoring intricacies and nice-to-haves until the really basic dynamical stuff is bedded in. Not only that, I think it will be more informative, and more conducive to obtaining an efficient final sim, to test the basic dynamical stuff without these intricacies, which is one of the reasons I suggest we begin our testing work with Standard.

jamespetts

Quote
Where I would always have chosen to start from, for the purposes of examining Standard's missing dynamics, is Standard. Standard is still here, so that's where I propose we start from.

This is not my starting point, as I am the maintainer of the Experimental project. My starting point is the Experimental project as it stands currently, and I do not understand why it should be otherwise. Taking Standard as the starting point is only a logical choice if you are suggesting changes to Standard (which changes, if implemented in Standard, are likely to find themselves in Experimental unless there is a clash between existing Experimental and new Standard features and the existing Experimental features work better, but the historical precedent is that, most often, when a new Standard feature clashes with an existing Experimental feature, the new Standard feature has taken precedence).

I do not know how the Standard developers view your suggestions for, for example, limited vehicle/infrastructure lifetime, and so forth, and therefore whether your suggestions are likely to be implemented there. What I do know is that the reason that Experimental exists at all is because the Standard developers did not want to include features that I consider important, such as calculating revenue based on actual average speeds rather than the theoretical maximum speed of the slowest vehicle in the convoy, and having passengers/goods choose which route to take according to which route will take them to their destination more quickly rather than any route with the fewest number of transfers (and, more latterly, also fewest intermediate stops). I would assume that you would also consider those features important: I cannot imagine that they are any less important than limited vehicle lifetime, etc., for proper balancing.

QuoteI didn't mean specifically pakset balancing, and I forgot to articulate all the steps in my thinking. Where I'm coming from is the need to make the sim as computationally light as possible. The real world doesn't have to be computationally efficient, but Simutrans needs to be. So in considering how to model each dynamic, the computational cost of each option has to be considered. One reason for developing multiple options to choose from. We could probably safely assume that an 80/20 rule applies here - one can get 80% of the dynamical accuracy with 20% of the computational workload, and end up consuming four fifths of the computational load trying to perfect the last 20%. The same would apply to the parameter count. I'm hoping we can get ourselves a great sim without having to cross that 80% line too much.

As to computational load, the view that I take on this topic is that, although, for any given feature set, it is always better to have the most efficient possible code, but when evaluating whether to have a feature at all as against the issue of computational load, computational load is no reason not to include any feature unless its inclusion makes the overall performance unacceptable to the user. Evaluating this is greatly complicated by the multiplicity of hardware available. Until very recently, I did all of my development on a seven-year-old Pentium 4 computer with 2Gb of RAM and Windows XP, and worked on the basis that, if it performed adequately on that computer without compiler optimisations enabled, then performance is not an issue. I have a much faster computer now, so that is slightly harder to gauge, but have not added any significant features since I have upgraded, so that has not yet been an issue.

Only one feature recently has given rise to significant computational load issues, and that is the feature of private cars checking whether they can find a route to their destination, which is problematic on large, well-populated maps. The problem is caused by the fact that the information as to whether the cars can reach their destinations is not saved, and that the routes are recalculated frequently. Fixing that issue is currently a priority, which fix will involve saving the routing data between sessions and recalculating routes for each city annually rather than monthly, spread evenly accross the year.

It should be remembered that many features that have great economic significance have only a very small effect on load, almost certainly not enough to impact on performance in a noticeable way: changes to how revenue is calculated, for example, has very little effect on computational load, as the algorithm for calculating revenue is called relatively infrequently. Reversing, catering, way constraints, weight limits and comfort are all features in Experimental with significant economic impact but insignificant computational load impact.

One of the themes of the development of Experimental has been the ability to take advantage of the more powerful computer systems available in modern times that were not available at the time that Simutrans was first developed (circa 1997), and to do things which would not have been practicable in that era. That allows a more sophisticated simulation whilst maintaining acceptable performance levels.

QuoteJust remember that sometimes the decisions that created what we see were influenced by uncertainties that were present at the time, so it's not always a black and white thing, and also that we aren't likely to be able to model every last real world dynamic. Without these factors a rational player, playing a dynamically faithful Simutrans, might build a world that isn't exactly what we see in reality, but that this isn't a bad thing.

I don't think that this contradicts the point that I made about significance in the game being derived from significance in reality, although I am not sure whether it was intended so to contradict. It is true that some features of reality are sufficiently dependant on lack of future knowledge, which knowledge cannot sensibly be denied to the player, such as to make their inclusion futile: that is why Pak128.Britain does not include broad gauge, for example, even though it was highly significant in railway history, as it is highly unlikely that Brunel would have chosen it had he known that the GWR would lose the "gauge wars" of the late 19th century. However, I do not think that there is any reason to suppose that that applies to any of the features that have been included, such as loading time, reversing times, comfort, catering, weight limits, way constraints, private cars, etc..

Quote
The process that doesn't appear to me to have been happening is analysing the behaviour of Simutrans itself as it plays out a dynamic. That's what I propose we start doing now. Turfit just provided an example of the kind of thing I believe we should be doing first: setting up simple, controlled experiments in the sim to observe what happens. So how about we select a topical dynamic, such as electrification vs steam, and contrive an experiment in Standard to see how this choice plays out over time? By comparing Standard's behaviour to our understanding of reality, and to our vision of Experimental, we can best determine how to build from Standard.

I have often undertaken such experimental analysis for the purpose of balancing, and have used it recently in relation to the balancing of steam locomotive physics (setting up a controlled test track on which I could run various steam locomotives with various loads, and then tinker with the parameters until the in-game performance matched as closely as possible historically researched real-world performances). There is merit indeed in this approach. However, as stated above, my starting point is not Standard, but Experimental as it currently stands, and I do not understand why it should be otherwise. I am not building from Standard, but refining Experimental.

QuoteThe impact of reversing can be modelled explicitly, or it can be rolled into the combination of capital/operating/ownership costs. I would have started out with the latter approach, because it's simpler, and seen how that panned out before adding more code and parameters.

I'm not sure that it is simpler to roll it into costs, because rolling it into costs requires calculating precisely what the cost of these various things ought to be (taking into account the effect of the greater turnaround time on other trains operating on the same line, which impact is itself dependant on the layout of the line, the frequency of the service, etc.), and I cannot for a moment imagine that that is a simple exercise. Indeed, I would not really know how to begin doing it that way, so, if anything, the existing approach is simpler: the simulation works out the cost balance itself rather than relying on constructing a statistical model external to the simulator which must then be checked for accuracy against the simulation itself.

Quotebut firstly I want to make sure we document our decision making as we work through the design. I would say though that before any new feature is coded, or any code is revised, a plain language version should be worked up and circulated on this forum for discussion. Once finalised it forms the instructions for whoever's coding, part of the technical documentation, and raw material for writing help files and manuals for players and pakset builders.

I had tried this in the past, but it had proven somewhat ineffective, as people often struggled to understand the intricacies of the code when presented to them in full detail, so I found that it worked better to give a more generalised overview (just as professional software developers do). Perhaps there might be some advantage to having a wiki somewhere with this information on it so that pakset maintainers can access it for balancing purposes? I would assume that only features relevant to balancing (and not, for example, things such as the new map generation tools or the vehicle replacer) would need to be listed?

As an aside, we seem to have drifted from the original scope of this topic, which was to discuss how to set out a balancing spreadsheet for vehicles, to the discussion of whether the "starting point" should be Standard or Experimental (and hypothetical questions about how features might have been developed had we been starting afresh), which, as explained above, I do not fully understand. I am not quite sure how we have managed to drift in this way, especially as I think that we are now agreed on the importance of using ROI as a base measure from which to start the balancing exercise. I thought that the other topic was intended to address the features that we need to add in order to balance correctly, and this topic was intended to discuss the actual mechanics of balancing itself?
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.

moblet

Quote from: jamespetts on February 05, 2011, 02:22:52 AM
my starting point is not Standard, but Experimental as it currently stands, and I do not understand why it should be otherwise. I am not building from Standard, but refining Experimental.
This being the case, I think it's probably best that I cease distracting you and let you get on with it.

jamespetts

Quote from: moblet on February 06, 2011, 10:33:19 AM
This being the case, I think it's probably best that I cease distracting you and let you get on with it.

By this do you mean that you are only interested in helping with the balancing if I ignore all the hundreds of hours already put into Experimental and start again from scratch, or something with similar effect? Since there has never been an adequate (or, indeed, really any) explanation as to why that should be done, it should hardly come as a surprise that that that is not something that I am willing to countenance. It simply does not make sense that, if we are looking at making changes to Experimental, the starting point should be anything other than Experimental.

Given that the discourse started with a discussion of specific additions that needed to be made in order to make balancing work properly, which was extremely helpful, I do not understand why the position has now become one in which that discussion cannot continue in the same helpful manner without going back to square one on the entire project for reasons unexplained.

It should go without saying that, had I found your contributions to be no more than a distraction, I should not have responded to them in the first place.
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

Risking to causing more confusion by trying an interpretation, i shall do it nontheless.

Quote
By this do you mean that you are only interested in helping with the balancing if I ignore all the hundreds of hours already put into Experimental and start again from scratch, or something with similar effect?
No, it does not mean this has to be ignored. It means starting the analysis based on standard, identifying what standard actually models. (Remember we know quite well what your changes to that model are, but we know not much on what it is based on) Find the assumptions and approximations in that model. Continuing from there it can be identified what is needed to improve the model of standard.

Now the new features and changes already implemented in experimental can be evaluated in regard to those needs.

Here is a continuum of routes between major extremes possible: Standard team is willing to implement the identified needs, if fitting solutions from experimental can be adopted or newly coded with experimentals very valuable experience. Experimental continues as a testbed for new ideas and things not likely to be implemented in standard.

The other extreme would be standard stays more conservative. Experimental features are reevaluated and kept, improved or rejected for a newer experimental (perhaps rename it to 'enhanced'). New dynamics not coded already are implemented.

The reality would be somewhere in-between those extreem solutions.

As an example from what i see it's quite likely that standard implements weight limits, you might to drop your solution and implement the standard one. prissi et al will likely have a look on what you did in experimental and use elements. Perhaps speed boni get droped in standard altogether, or replaced by something else. In that case it would be sensible to do the same in experimental. etc.

To conclude, starting the development of the model at simutrans does not mean the implementation has to be discarded.

jamespetts

What I have trouble understanding is what the issue is with the view that I take that removing an existing feature of Experimental should require just as good a reason as adding a new feature, on which matter I must be firm. As discussed elsewhere, I am keen for Experimental to have what somebody described as a "consolidation phase" where few new features are added and the focus is on refining the existing feature set and producing a well-balanced pakset to go with it, but this is not possible whilst there are still outstanding issues that prevent effective balancing (and other significant problems that affect playability: I have been working on code this week-end which will greatly improve responsiveness in larger games in which private car routes are enabled: testing my code, I was able to load a version of your  "162" game saved with my the latest code from the 9.x branch and have it responsive instantly after loading; I will release a 9.3 when the next stable Standard is released incorporating this feature).

To conclude: fixing bugs and major playability/balance issues ought to be done now, but any major upheaval beyond that strikes me as an unwarranted waste of developer resources that could better be spent elsewhere. Se here for a discussion on the set of changes that I am planning for version 10.
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

The key is to evaluate the features already implemented with an open mindset. This means when analysing simutrans model and developing the requirements it must be completely ignored what is in experimental already. (This has the side effect that this is quite useful for standard itself.)

After the need is defined the components of experimental can be evaluated in regard to this. You can compare it with the dissadvantages they bring and the effort to implement. Those things implemented are already in an advantaged position for this, as the cost of implementation or adaption should be quite low.

It is however not a good idea starting this process with the aim not to drop anything unless completely avoidable. In systems theory a fundamental theorem is that adding something, removeing something and doing nothing at all have same chance of improvement. (expectation value for improvement would be zero) In other words: not droping some code that makes your program worse is as bad as not implementing something that is known to improve it.

Now in simutrans-experimental it is not essentially important that the model (and it's implementation) produces reliable results. When evaluating components additional complexity can be weighted less when evaluating the costs.


Also please bear in mind that in software development you don't loose anything if you discard code altogether, regardless if and how you replace it. It served it's function and is the basis on which you do your improvement. In my area it is even very likely that a model is refined with very much effort tested and then disregarded all together, if it's impact on results is not significant. An increase in complexity has much more costs than the manpower, viz computation time, sources of errors and it is contrary to the aim to have the simples model possible to model the physics. This is perhaps more extreme in ab initio or first principles approaches employed in fundamental research.

In moblets field this might be the case too. It's not difficult to say "just drop something" if one is prepared for this to happen for years of own work.

Quote
fixing bugs and major playability/balance issues ought to be done now, but any major upheaval beyond that strikes me as an unwarranted waste of developer resources that could better be spent elsewhere. Se here for a discussion on the set of changes that I am planning for version 10
this sounds as if you would call the project finished after version 10? I think this discussion has a scope far beyond version 10. What the process moblet wants to start provides is a long term scope beyond a few versions. (and perhaps beyond experimental) So far such a long term scope has not been communicated by you, and it would speak very much for you if you don't even have any solid picture there.
Bug fixing and playability issues are always day to day work.

Some of the changes you linked to are quite severe, perhaps you want to postpone then until some analysis. It would be quite dissapointing if the chance to get a solid foundation for experimental would be missed. I'm not sure how much devotion would be for the analysis and model generation, but with current levels this should be quite rapid and if really lucky there could be first visible results in a year or so already!

jamespetts

Quote from: sdog on February 07, 2011, 12:29:12 AM
The key is to evaluate the features already implemented with an open mindset. This means when analysing simutrans model and developing the requirements it must be completely ignored what is in experimental already. (This has the side effect that this is quite useful for standard itself.)

After the need is defined the components of experimental can be evaluated in regard to this. You can compare it with the dissadvantages they bring and the effort to implement. Those things implemented are already in an advantaged position for this, as the cost of implementation or adaption should be quite low.

It is however not a good idea starting this process with the aim not to drop anything unless completely avoidable. In systems theory a fundamental theorem is that adding something, removeing something and doing nothing at all have same chance of improvement. (expectation value for improvement would be zero) In other words: not droping some code that makes your program worse is as bad as not implementing something that is known to improve it.

I don't see how the chain of reasoning follows there: why must what is in Experimental be ignored whilst what is in Standard is not ignored? I do not see any reason for distinction between the two for these purposes.

Further, if, all other things being equal, adding a feature, removing a feature, and leaving things as they are are all equally likely to be good, bad or indifferent, then my position - that as good a reason is needed to remove a feature as to add a feature - is an entirely logical consequence, is it not? Since maintaining the status quo has the advantage of being free of cost, which advantage adding and removing features do not have, maintaining the status quo should be the default position. Any variation from that default position needs a good reason. There is no reason to suppose that one sort of variation (removing a feature) needs any less of a reason than any other.

QuoteNow in simutrans-experimental it is not essentially important that the model (and it's implementation) produces reliable results. When evaluating components additional complexity can be weighted less when evaluating the costs.

I'm not sure what you mean by this, I'm afraid.

Quote
this sounds as if you would call the project finished after version 10? I think this discussion has a scope far beyond version 10. What the process moblet wants to start provides is a long term scope beyond a few versions. (and perhaps beyond experimental) So far such a long term scope has not been communicated by you, and it would speak very much for you if you don't even have any solid picture there.
Bug fixing and playability issues are always day to day work.

I certainly don't intend there never to be another major release of Experimental after version 10! The idea is simply to spend some time consolidating and getting a good playable foundation: there are many other things that could be added in the long term.

QuoteSome of the changes you linked to are quite severe, perhaps you want to postpone then until some analysis. It would be quite dissapointing if the chance to get a solid foundation for experimental would be missed. I'm not sure how much devotion would be for the analysis and model generation, but with current levels this should be quite rapid and if really lucky there could be first visible results in a year or so already!

The purpose of the thread to which I linked was to instigate just that sort of discussion and analysis. It seems clear from the discussion of the ROI model that those economic features are necessary if Simutrans is to balance properly, so they should be implemented as soon as is practicable to enable the creation of a solid and playable version of Experimental together with a well-balanced pakset to be expedited.
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

QuoteI don't see how the chain of reasoning follows there: why must what is in Experimental be ignored whilst what is in Standard is not ignored? I do not see any reason for distinction between the two for these purposes.
Following a first principles approach in all consequence would mean to start from nothing. Starting the analysis at standard and evaluating it's model in the light of the requirements of a first principles model is just a practical decission.

It has two major advantages not to start at experimental. First is we know much more about the difference of standard and experimental than we know of standard. To actually understand experimental we would have to understand quite a lot of standard first. Secondly standard is slightly less complex, this helps quite a bit. Thirdly, it will be difficult to get help from some of the core devs of standard to help for an experimental only project. Remember this can be very fruitful for standard too, at least it would provide it with a documentation. At best it would redefine standard and experimental (There was hardly any transfer from experimental to standard so far, main reason was that experimental could not show that it's additions would improve standard.)


QuoteFurther, if, all other things being equal, adding a feature, removing a feature, and leaving things as they are are all equally likely to be good, bad or indifferent, then my position - that as good a reason is needed to remove a feature as to add a feature - is an entirely logical consequence, is it not? Since maintaining the status quo has the advantage of being free of cost, which advantage adding and removing features do not have, maintaining the status quo should be the default position. Any variation from that default position needs a good reason. There is no reason to suppose that one sort of variation (removing a feature) needs any less of a reason than any other.
This is in general quite correct. You just have to be careful from what 'inertial' system you view at the problem. If you view it from standard and evaluate if adding an experimental feature or from experimental and evaluate if it should be removed the outcome should be the same. Implementation costs are practically the same, patching it in or out does not matter. What matters is if the feature has a reason to stay in the simulation, is the benefit of it larger than it's costs.

As mentioned before which system is used as status quo does not matter at all for that. Pragmatic decissions can lead you here.

Quote
Quote
Now in simutrans-experimental it is not essentially important that the model (and it's implementation) produces reliable results. When evaluating components additional complexity can be weighted less when evaluating the costs.

I'm not sure what you mean by this, I'm afraid.
And that is not surprising as it is missing quite a bit of context i only mentioned later. In models in research it is most important that the model is reliably accurate. Any additional line of code could cause errors, any increased complexity of the model can cause inaccurate behaviour. The simpler the program is, the more it can be trusted. This is perhaps the whole core of first principle approaches.

As an example if you want to test classical mechanics against planetary motion of outer planets in our solar system, anything above Hamilton mechanics you put into the model will make it less worth for that purpose.  Simutrans is a game, so this can be quite relaxed. If we think reversing trains are a splendidly fun in the game, while it does not really improve the economic model it would have to go if we would do a first principles simulation of the economy of transport companies. It can (and imho should) stay in a very accurate simulation game however!

I want to say, if we find a feature does not really contribute to the model, we don't have to cancel it if it is not detrimental, the increased complexity can be excluded from the evaluation to some degree. (it still increases maintenance effort)

QuoteIt seems clear from the discussion of the ROI model that those economic features are necessary if Simutrans is to balance properly, so they should be implemented as soon as is practicable to enable the creation of a solid and playable version of Experimental together with a well-balanced pakset to be expedited.
I think this shouldn't be a short time change. Perhaps here you should be clear how the overal economic model should look like. It is nothing pressing afterall, pak britain works well enough for the moment, it is as balanced as pak 128 at least. ROI etc might be a goal for a longer time frame.

It's quite a bit out of place for me to make suggestions on what to do, but i will do so none the less, with great reluctance. Concentration on ironing out network issues, and perhaps a joint integration of the new weight limits might be a lot of work for the immediate future already, without opening this new can of worms prematurely. The industry re-linking seems to be also important.

jamespetts

#47
Quote from: sdog on February 07, 2011, 01:32:09 AM
Following a first principles approach in all consequence would mean to start from nothing. Starting the analysis at standard and evaluating it's model in the light of the requirements of a first principles model is just a practical decission.

It has two major advantages not to start at experimental. First is we know much more about the difference of standard and experimental than we know of standard. To actually understand experimental we would have to understand quite a lot of standard first. Secondly standard is slightly less complex, this helps quite a bit. Thirdly, it will be difficult to get help from some of the core devs of standard to help for an experimental only project. Remember this can be very fruitful for standard too, at least it would provide it with a documentation. At best it would redefine standard and experimental (There was hardly any transfer from experimental to standard so far, main reason was that experimental could not show that it's additions would improve standard.)

I don't agree with this analysis: firstly, the question is, what exactly is the nature of the project on which we are seeking to embark? From what I understood from Moblet's initial posts, it was an analysis of what things needed changing in order to allow Simutrans-Experimental to be well-balanced. Much of that analysis has already been done, identifying the lack of use-related maintenance cost increases and lack of a credit interest rate as significant factors preventing effective balancing between the early/late game, although how much (if any) of that analysis remains is unclear. I have not seen a justification for a more wide-ranging project, nor a clear description of what such a project would entail; in one earlier post, for example, Moblet had implied that such a project might entail the removal of features on the ground of performance alone, even if performance as it currently stands is not unacceptable. I do not consider such work necessary.

Secondly, I do not think that the reasons given are sufficient justifications for taking a starting point of anything other than where we are now in the Experimental project. Indeed, I do not fully understand some of the justifications that you give: you write that the Standard developers might not be interested in helping an Experimental only project, which further begs the question posed above about what exactly this project that is being suggested entails. A documentation project was suggested, and there may be some sense in starting with Standard there (although, again, taking into account all the existing documentation in existence for Standard and building from that rather than throwing it out and starting again), but the same does not apply to making changes to Simutrans itself: the fundamental point is that it is very different in practice to ask if one should remove an existing feature than to ask if one should add a new feature for the reasons that I gave in my previous post, and none of those reasons are displaced to any extent by the fact that Standard is simpler or that we know more about the differences between Standard and Experimental than we do about Standard itself. I don't see how those two things can address the economics of feature changing that I raised in my previous post.

It seems to be simple common sense to say that removing an existing feature requires as much justification as adding a new one. I don't see the justification for any project that entails doing anything other than that.

QuoteThis is in general quite correct. You just have to be careful from what 'inertial' system you view at the problem. If you view it from standard and evaluate if adding an experimental feature or from experimental and evaluate if it should be removed the outcome should be the same. Implementation costs are practically the same, patching it in or out does not matter. What matters is if the feature has a reason to stay in the simulation, is the benefit of it larger than it's costs.

Asking what features to add to Standard only makes sense if one is, in fact, adding features to Standard; not removing features from Experimental is not identical to adding features to Standard, and cannot be treated as equivalent. I, as the maintainer of Experimental, have to work with the code base that I have, that is Experimental. My starting point is, naturally, the Experimental code base. The Standard developers are starting from Standard. The issue of what features from Experimental should be implemented in Standard is very different to the issue of what features, if any, should be removed from Experimental, or what features added to it.

QuoteIn models in research it is most important that the model is reliably accurate. Any additional line of code could cause errors, any increased complexity of the model can cause inaccurate behaviour. The simpler the program is, the more it can be trusted. This is perhaps the whole core of first principle approaches.

Just as adding code gives the opportunity for errors to arise, equally so does removing code.  

QuoteAs an example if you want to test classical mechanics against planetary motion of outer planets in our solar system, anything above Hamilton mechanics you put into the model will make it less worth for that purpose.  Simutrans is a game, so this can be quite relaxed. If we think reversing trains are a splendidly fun in the game, while it does not really improve the economic model it would have to go if we would do a first principles simulation of the economy of transport companies. It can (and imho should) stay in a very accurate simulation game however!

This only makes me more confused about what exactly the "first principles" approach entails and what the justification for taking it is in this instance.

QuoteI think this shouldn't be a short time change. Perhaps here you should be clear how the overal economic model should look like. It is nothing pressing afterall, pak britain works well enough for the moment, it is as balanced as pak 128 at least. ROI etc might be a goal for a longer time frame.

As to the overall economic model - I was quite happy with it as it was until Moblet pointed out that, without certain further specific aspects modelled, it would not work. As a result of that discussion, my vision of the model, in general terms, has been modified to be as it is now plus the things that Moblet mentioned necessary to model in order to permit the paksets to balance properly. The idea of Experimental was only ever to make incremental changes to Standard by adding a few specific features: this discussion has so far done no more than alert me to several other specific features that need to be added.

QuoteIt's quite a bit out of place for me to make suggestions on what to do, but i will do so none the less, with great reluctance. Concentration on ironing out network issues, and perhaps a joint integration of the new weight limits might be a lot of work for the immediate future already, without opening this new can of worms prematurely. The industry re-linking seems to be also important.

Actually, it's very helpful to get an insight into users' opinions of these matters. As you may know, ironing out the network issues is a very difficult task indeed, and I am hampered by having no experience of network programming and nobody else who is available to assist on that at present, apart from general advice given very helpfully by the Standard developers. I hadn't seen much discussion on the various Experimental networking threads, so assumed that that was not the greatest priority at present; but perhaps people interested in networking have simply remained silent?
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

Perhaps, i should have asked a long time ago, what your professional or scientific background is. (i've been very curious but thought it might be too intrusive in your real life. If you want to, you could perhaps give me a rough hint via pm?) You might also want to split this from the topic, i post it here though, as it is a direct response.

It seems there is a more fundamental missunderstanding, we're not really talking the same language here. First principles and ab initio are two very important concepts for models in science. The sneaky thing is, both can have slightly different meanings in various disciplines. Slight but very serious consequences.

What they have in common is not using parameters. (in praxis this sometimes means just avoidance, here some of those different meanings are hidden)

In ab initio a set of fundamental theorems is the starting point. In general it is not possible to just calculate something from this. Here i'll take the Schrödinger equation as an example.

The Schrödinger equation is a very simple equation that (we persume) completely describes non relativistic quantum mechanics! But there's a caveat: It can not be solved directly -- except for anything but the most simple problems. One of those problems is calculating the spectral lines of Hydrogen. They can be meassured with extreme accuracy, perhaps you remember Lyman alpha lines from undergrad chemistry or even astronomy. Now we know that the Schroedinger equation is correct up to extreme accuracy (at some point one has to go to more involved theories*).

For more complex systems like Helium a model must be developed. Now you could do a numerical simulation with a couple of parameters, and you could fit them in a way to reproduce the physical properties of He. However you gain hardly anything from this, at best a prediction where you should look for the next line if you know some others. Ab inition you build your model on the Schroedinger equation again, by introducing some well founded assumptions and approximations you can get to a model from which you can calculate the He spectral lines.

This also applies for more complex atoms, and molecules. We need some advanced numerical methods too. Those approximations are well known and have a name. The approximations introduced for the simpler systems might be required for all more complex systems too. An example is Bohr's approximations that we can treat the nucleus and the electrons independently. It is very important to know what approximations were used.

In quantum chemistry those approximations go so far that they calculate the energy ground state of macro-molecules with hundreds of atoms ab initio. (The equivalent of falculating the Lyman alpha line for hyrdogen.) At this level of complexity the approach from a parameter based model, which is ridiculous for Helium, starts to make sense. Often enough there is no sufficient ab initio model, but simulations based on empirical results deliver. As a general trend ab initio is found more often in fundamental research while the other approach is very frequent in applied research. There are of course hybrids also. You might know the physical law for a system but don't know the material dependent constants in it. Here empirical parameters might be used. As an example for this equations describing the behaviour of semi conductor lasers spring to my mind. For different semiconductors and dopings other parameters have to be chosen.

In general the model itself requires a multitude more work and ingenuity than the implementation in code. Typically only the description of the model is published. The code is often either considered insignificant or sometimes also extremely involved but either open sourced or kept secret to have an advantage.

The first principles approach has a number of advantages. Foremost is testing theory. If we can test the Schroedinger equation for Hydrogen directly it shows it is correct for Hydrogen. If a first principles model of it also works for Helium and Lithium we show it is likely valid for all light atoms. First principle models for a multitude of problems in atomic and solid state physics shows it is valid for the whole field. (It's still not a proof!)

A good ab initio model might even show some behaviour not seen in experiments yet, but that is found after knowing where to look. You often hear that theory predicted something that was found/or not at LHC/Hubble telescope/anywhere else. All high energy physics and cosomology works more or less works like that. Just to much noise or data to find anything unless you know very exactly what to look for.

Another advantage is, and this is much more useful here, the lack of parameters makes it easy to apply an ab initio model if it is good. You don't have to make a large number of empirical tests to find parameters and test them. It suffices to have a lot of empirical data to test if the model is correct.

Now the biggest power lies here looking at an ab initio model that accurately models a real life system, and does so with the least possible complexity, we understand the real life system! We see what really is important, and what is completely unimportant. For example having an ab initio model of vast masses of people moving, we can see they behave exactly like sand grains flowing down. We find that it is important to have wide openings, and put an obstacle two meters before this opening to prevent clogging. As individual decissions are not important we see it doesn't matter to have detailed signs, we need just something to get them into one direction (equals gravity for grains). One can also see they do not behave like water, which does not clog in front of openings, sand does so therefor the obstacle to speed things up. This model is of course not a pure first principles model, humans are no sand grains, while grain size and friction are material constants for grain, they are likely free parameters for humans. If we get such parameters for english or chinese, we could also model other occasions where masses of people move with the same parameters! E.g model what happens if a dense crowd of people suddenly starts to spread into a large open area.

For simutrans a real first principles approach does not seem possible to me. However, building a model with first principles as an ideal in mind might be a good idea. This is opposed to just use a parameter based model that is tweaked to give some acceptable results. Following a philosophy close to first principles could avoid tweaking at all.

We would build the model as good as we can, and then we look first at direct economic data, optimize the model. If the time dependent factors are also included, at one point we should be able to reproduce some of the historical results you researched so far from the sim. Important here, doing so without tweaking it to get those results or planing the sim to arrive there.


*Here's something extremely thrilling comming up from LHC soon, precission spectroscopy of anti-hydrogen (anti matter version of hydrogen atoms). Some extremely small differences are predicted, breaking the symmetry between matter and anti-matter (CP violation). This would explain the biggest mystery of the big bang, if matter and anti-matter formed condensed from energy, why was there more matter than anti-matter. We know the last part for the simple fact that we are.

sdog

#49
now answering directly to james previous message
Quote from: jamespetts on February 07, 2011, 02:19:28 AM
I don't agree with this analysis: firstly, the question is, what exactly is the nature of the project on which we are seeking to embark? ...
Analysing the problem and building a model for a transport simulation. For practical reasons it should be deviated from first principles and started by analysing a working implementation in simutrans.

When the model in simutrans is understood, the step to simutrans experimental is very small. You know already what has changed, you documented it in part, and it is much less.


Quotefor example, Moblet had implied that such a project might entail the removal of features on the ground of performance alone, even if performance as it currently stands is not unacceptable. I do not consider such work necessary.
I really can't see your problem here. Of course should a feature be removed if it's benefit does not outweigh it's cost. Performance is definitely a cost. I also do not think moblet came to any conclusion what weights to give to any factor, including performance. If it is decided that performance has a relatively low weight a feature that gets removed because of this must have been next to useless. Denying the possiblility to remove a feature of the game at all makes the whole process pointless.

Quote
Secondly, I do not think that the reasons given are sufficient justifications for taking a starting point of anything other than where we are now in the Experimental project. Indeed, I do not fully understand some of the justifications that you give: you write that the Standard developers might not be interested in helping an Experimental only project, which further begs the question posed above about what exactly this project that is being suggested entails.
A documentation project was suggested, and there may be some sense in starting with Standard there (although, again, taking into account all the existing documentation in existence for Standard and building from that rather than throwing it out and starting again), but the same does not apply to making changes to Simutrans itself:
Documentation is a side effect of finding of developing a model. At the moment noone really knows what happens in simutrans. Some people, like prissi or Hajo have a very good understanding. But even those two do not have the full picture i think.

Quote
the fundamental point is that it is very different in practice to ask if one should remove an existing feature than to ask if one should add a new feature for the reasons that I gave in my previous post,
At best at a practical point of view. It is also not a very important issue at the moment. Also i hope i don't hurt you by suggesting this, you invested quite a lot of work. Now some people who did nothing at all come and question everything. As said before, i'm used to the thought all my work will be in vain. (This happened with one year of work for my first thesis) Try not to be attached too much to code, and don't forget at the end it is not automatic, but still your decission to keep or reject code. Afterall you would be certain it is detrimental before you would drop anything.

Quote
It seems to be simple common sense to say that removing an existing feature requires as much justification as adding a new one. I don't see the justification for any project that entails doing anything other than that.
Exactly that is the reason why it should not matter at all if you build your model based on standard or experimental. If you have feature A that has to be included in standard to make it a perfect simulation, this means also it has to be kept in experimental to make it a perfect simulation. The other way round if feature B must not be included in standard to make it a perfect simulation, it should be removed from experimental too. As if it was beneficial we would have to include it in standard. This is of course a hypothetical case, you see i used perfect simulation. In praxi you can relax the argument. Feature C doesn't really bring anything, but it doesn't really hurt either, so keep it if it's already there, but it's perhaps not worth to do anything to get it.

QuoteAsking what features to add to Standard only makes sense if one is, in fact, adding features to Standard; not removing features from Experimental is not identical to adding features to Standard, and cannot be treated as equivalent. I, as the maintainer of Experimental, have to work with the code base that I have, that is Experimental. My starting point is, naturally, the Experimental code base. The Standard developers are starting from Standard. The issue of what features from Experimental should be implemented in Standard is very different to the issue of what features, if any, should be removed from Experimental, or what features added to it.
Implementation or code base does not matter for the model. The model provides you with an end point you would like to reach, if we get there from first principles, from standard, or experimental does not matter at all. Starting from standard or experimental only makes it easier to identify what specifically is needed and what real restrictions are there.

If standard has the set of components S, experimental has E and an the desired model M. A comparison of S and M would show that the major dynamics  A,B,C are required. A comparison of S and E shows that E has the additional dynamics B,C,D. It would require A to be implemented and D which is not necessary to be tested if it is detrimental.

Now if you start from experimental, you find by comparing E and M that it would need A to be implemented and that D is superfluous. To improve standard to the state of the model, comparing S and E and the requirements from comparing M and E shows that S would require the sets B and C implemented from experimental and A needs to be newly coded.

Quote
Just as adding code gives the opportunity for errors to arise, equally so does removing code. 
at point of implementation, but if that code was superfluous for the model, not for the simulation and not for long term maintenance.
Quote
This only makes me more confused about what exactly the "first principles" approach entails and what the justification for taking it is in this instance.
see my very long previous message

Quote
As to the overall economic model - I was quite happy with it as it was until Moblet pointed out that, without certain further specific aspects modelled, it would not work. As a result of that discussion, my vision of the model, in general terms, has been modified to be as it is now plus the things that Moblet mentioned necessary to model in order to permit the paksets to balance properly. The idea of Experimental was only ever to make incremental changes to Standard by adding a few specific features: this discussion has so far done no more than alert me to several other specific features that need to be added.
in what moblet suggested above, the main work lies not necessarily in coding those features, but in finding out what is needed. Moblet showed us very impressively that a) we don't know what the sim is doing and b) the anticipated economic model is extremely ambitious. (in particular as it should hold over three centuries, with very different environment) If he manages to build a working model, and doing it rigorously, he would have material for more than one paper or a master thesis in economy.

Quote
Actually, it's very helpful to get an insight into users' opinions of these matters. As you may know, ironing out the network issues is a very difficult task indeed, and I am hampered by having no experience of network programming and nobody else who is available to assist on that at present, apart from general advice given very helpfully by the Standard developers. I hadn't seen much discussion on the various Experimental networking threads, so assumed that that was not the greatest priority at present; but perhaps people interested in networking have simply remained silent?
My guess, everyone else is just too lost or intimidated by the task. There will be massive testing required too. I avoid it like the pest, as  i still remember what a personal fiasko it was when i tried to test the network code on timothy's server just for a few moments.

moblet

Thanks for chiming in and articulating these things, sdog. And yes, I think you understand perfectly where I'm coming from!
Quote from: sdogi'm used to the thought all my work will be in vain.
One has to adopt this mindset when undertaking any research, investigation, or modelling. Edison put the most positive spin on it when trying to identify a substance that would work as a light bulb filament. After testing over 1,000 materials without success, he didn't say he'd failed to reach his goal, he said he'd successfully proven that all of those substances were unsuitable for use as light bulb filament. I'd estimate that about a third of the effort I've expended in my professional career never achieved anything as far as its intended purpose was concerned. Some of it, however, improved my skills or dynamical understanding, but perhaps most importantly the experiences of "acceptance" and "rejection" taught me how to identify why some efforts were spectacularly successful, while others were doomed from the outset. I would get excited about stuff I was doing, as I'm sure sdog did too, but I never dared to become emotionally attached to its ultimate implementation.
Quote from: sdogThe key is to evaluate the features already implemented with an open mindset.
I can't stress this enough. In this line of work it's impossible to get good results without an open mindset, and trying to work alongside someone who is attached to particular components is a red flag for me. I'm not going to commit effort to something that my experience tells me is bound to come unstuck.
Quote from: sdogAt the moment noone really knows what happens in simutrans.
Laughed when I read this, but it's true, and it's the first reason why I've been proposing using Standard as the initial reference. By this I have always meant first studying Standard, not necessarily using Standard as the first modelling iteration or for evaluation of proposed Experimental features. My gut feeling is that in practice we would, after a period of developing understanding, ultimately find ourselves working from a simplified version of Experimental, say with its introduced non-linearities switched off. Note also that some of what's already coded in Experimental can give us the opportunity to directly compare two options (e.g. of passenger trip choice algorithms), should we want to do this.
Quote from: sdogMy guess, everyone else is just too lost or intimidated by the task. There will be massive testing required too.
I think that's one reason. It certainly looks daunting until one realises that it can be broken up into little independent pieces, and each piece can be distributed to any willing player to do a test run and send the data back. It's also low-stress work, and the thinking bit can be fun.
Another reason may be that, as sdog has tried to explain, the planning and development of Experimental has not followed the route familiar to most modellers/programmers/scientists, so some may be unsure of when, where, and how to contribute their ideas.

jamespetts

To answer SDog's initial question: I am a barrister by profession, and, although interested in the natural sciences, have no formal scientific or mathematical training beyond secondary school. I was not aware that either "first principles" or "ab initio" were being used here as terms of art: "ab initio" does have a particular meaning in law, where it is used to refer to putting people back in the same position as they were before the happening of a particular event (such as entering into a contract). Literally translated from Latin, I think that it means something like "from the start". Is this what you intend here?

Do I understand you correctly that, in very brief summary, ab initio in the scientific sense refers to modelling by extrapolating from assumptions, and the "first principles" approach (is this the same as the "parameter" approach?) involves starting without assumptions and letting the model replicate the thing being simulated itself? If this is so, it is interesting to note that transport simulators (that is, professional grade, non-game transport simulators used for real-world transport planning) come in both flavours, and both, apparently, have their own strengths and weaknesses (the assumptions system being quicker and simpler, but only useful in so far as the assumptions are sufficiently complete and accurate, which itself is not always easy to measure accurately). In this context, the terms that I have heard used are "bottom up" for what I think that you call the first principles approach, and "top down" for what I think that you call the ab initio approach.

Turning to the more practical issues, the project on which we are engaged cannot, realistically, be to ask what we would do if we were starting from scratch, but rather to ask what we should do given where we are now. If we were starting from scratch, for example, I'd do away with direct specification of prices all together and instead model prices based on relative fuel/labour/raw materials costs and some sort of model for relative inflation between the various types of cost. We cannot engage in the somewhat indulgent exercise of asking what would an ideal model of a transport network look like without keeping a firm eye on questions of implementation at every step, as there is no point in designing an ideal model if the resources to implement it within a sane timescale are lacking. There is no point in undertaking an exercise of designing a model from the ground up in isolation from the reality that that model has to be implemented, and that it has to be implemented in the existing Simutrans-Experimental code.

For those reasons, I do not think that the task in which we can practically be engaged can be described as,

"Analysing the problem and building a model for a transport simulation. For practical reasons it should be deviated from first principles and started by analysing a working implementation in simutrans."

The nature of the task is not building a model for a transport simulation, it is refining and improving an existing transport simulation which already has its own (albeit imperfect) model, which model will need careful consideration in the process of the refining and improving process.

In any event, nothing written so far seems to be any reason at all to depart from what seems to me to be an obviously correct approach that removing a feature requires the same degree of justification as adding a feature. That it does not matter for the purposes of (re-)designing the theoretical model that underpins Simutrans-Experimental whether one asks whether any given feature that is already in Experimental ought be added to Standard or removed from Experimental does not mean that it does not matter at all, as it certainly matters at the implementation stage. All other things being equal, leaving things as they are is the only sensible default.

Quote from: SdogIf standard has the set of components S, experimental has E and an the desired model M. A comparison of S and M would show that the major dynamics  A,B,C are required. A comparison of S and E shows that E has the additional dynamics B,C,D. It would require A to be implemented and D which is not necessary to be tested if it is detrimental.

Now if you start from experimental, you find by comparing E and M that it would need A to be implemented and that D is superfluous. To improve standard to the state of the model, comparing S and E and the requirements from comparing M and E shows that S would require the sets B and C implemented from experimental and A needs to be newly coded.

In the above example, I see no reason to take steps to remove D unless there is some good and specific reason to suppose that Simutrans-Experimental with D is a worse game than Simutrans-Experimental without D. From what I understand from what is being proposed, D would in that example be removed, which is why I disagree with what is proposed.

It is not, incidentally, any irrational reticence to remove features simply because I have expended effort on them: I am more than happy to remove things on which I have expended effort when there is a good reason to do so (such as the original implementation of the Simutrans-Experimental routing algorithm, which was replaced entirely by Knightly by an algorithm that was superior in every way to that which it replaced). What I do not think, however, is necessary is removing (or, indeed, making changes to) features when there is no good reason to do so. There is nothing wrong with evaluating existing features with an open mindset, providing that an open mindset means a willingness to change features where a good reason is shown so to change, not a willingness to change features whether or not a good reason is shown.

I do not see why it is necessary in order properly to document Simutrans (Standard and Experimental) and to improve the economic modelling in Experimental (or both) that any features be removed where there is not shown a good reason for removing them, or why my willingness or otherwise to remove features where there is no good reason shown for their removal should be determinative of whether others are interested in working on such a project. Perhaps I have misunderstood what is being suggested, and nobody is really suggesting that at all - if so, my apologies (accompanied by a humble request for what was really meant to be re-explained). If, however, I have not misunderstood what is being suggested, I remain perplexed at the position. Given that we are all fond of Simutrans and all want to see the quality and realism of the economic simulation in the game improving, it makes no sense to be interested in being involved in a project to improve that quality and realism only if and in so far as I am willing to remove existing features even where no specific reason is shown in favour of their removal. (It should be noted as an aside that many features can be extensively tuned, in many cases to the point of being effectively disabled entirely, using simuconf.tab parameters).
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

It seems i was not very clear about ab initio and first principles, i want to correct this here and provide another example to show the difference to other models, using parameters. First principles and ab initio are used roughly synonymously. (there are some distinctions in quantum chemistry, this might be the case in other fields too)

The starting point for ab initio are, in physics, physical laws, so they are the first principles, in the meaning the most fundamental ones. Assumptions have to be made to reduce the problem to something that can be treated. For example to calculate earths orbit we neglect the rest of the universe. The assumptions define the boundary conditions and approximations to be made.

Typically ab initio or first principle methods require much more complicated calculations than parameter based models. The gain is much higher flexibility. Eg. you can get a lot of empirical data and find parameters or better coefficients to estimate the wear of a road with your pocket calculator. It would perhaps be a ponylomial (i'm guessing here, best ask banksie) a m^4 + b m^3 + c m^2 + d m + e. The real effort is in getting the coefficients. An approach closer to first principles would perhaps model energy deposition, shear and tensions into the road. Typically you have to solve systems of differential equations. This is much more effort but it might provide results for other materials or other effects. (and will perhaps be used to get the coefficients.)

QuoteIn the above example, I see no reason to take steps to remove D unless there is some good and specific reason to suppose that Simutrans-Experimental with D is a worse game than Simutrans-Experimental without D. From what I understand from what is being proposed, D would in that example be removed, which is why I disagree with what is proposed. ...

In the example D would be removed, but not without reason. And if i understood you correctly, you would remove D too, if there is a reason. The reason would be it has more disadvantages to keep D than the benefit it brings. Let me have a very direct example, and i want to point out this is only a hypothetical example:

Let us assume moblet finds the speed bonus system causes very strong distortions to the economy, greatly unbalancing the income. He finds that a system by giving trains that leave at odd hours of the day twice the money and apply black magick to trains leaving at even hours is exactly what happens in the real world and can be implemented. In that case i think you would have no objections to drop the speed bonus system?

Now modify this a little bit. The speed bonus is still fubar in this example, completely skewed results. But moblet finds that no such system at all will provide exactly the correct results. Do you think the speed bonus must be kept?

I took the speed bonus for this example not only as it might very well have a detrimental influence on balance, but also because it was coded in experimental by trying to improve a system from standard that seemd completely absurd. Providing speed boni to vehicles just because they have a higher speed.

Now we learned this was as false assumption by almost anyone around, they did it only to have an incentive in pakHajo or pak64 to use more modern vehicles or rather to compensate for the higher running costs of those. In other words it was a solution specifically taylored to a problem in a pak set. It was named a bit missleadingly and after a while other pak set creators thought it is some system to give a bonuse for fast deliveries!

This should also illustrate that we don't know anything about simutrans. In fact it is even worse, we believe things about simutrans. This might very well be wrong.

Here i understand prissis reservations towards experimental much better now. My guess is he does not have the ambition to model reality, he's quite happy with a good game that behaves plausibly or should i say believably.

If you want to put a simutrans that should simulate economy and transportation realisticaly on this. And you also have the ambition it should reflect historical developments and work stable over more than two centuries, you might be trying to build a bridge from Dover to Calais on a sand-castle as foundation.

At this point i would like to say that i do not suggest using an ab inito or first principles approach or anything near it. I don't suggest against it either. It can be extremely large gains, it could work not at all, in any case it will be extremely much and difficult work i think.
I'm not sure if moblet would pull it and be willing to do so. The good thing is, if done properly at any time it is broken off, there would be a documentation on simutrans as side effect.

Oh, and of course i would very much like to see such a project, very exciting!

I think you're at a point where you have to decide in what direction you want simutrans to move.

- A technology testbed for things to be included in standard?
- A framework to run pak britain
- A realistic simulation (with a high risk of failure)

Instead of moblets approach you might decide to tweak experimental to get some degree of balance. You might add some additional refinements to the economy, but to get some balance it is not completely unlikely you have to resort to some 'cheating'. Eg introduce artificial money sinks.

Quote
It should be noted as an aside that many features can be extensively tuned, in many cases to the point of being effectively disabled entirely, using simuconf.tab parameters.
This is very good for testing. It is, however, extremely bad coding practice to leave code that is turned off in the code. There are at least two major reasons, first you gain nothing. After a couple of revisions it will not work anymore without major rewrite. The second reason is those parts have the nasty habit of being considered to be still active (wrong assumptions), they might get turned on unknowingly (wrong model), they hinder refactoring of code or maintenance. It is a very clear rule. If it is not needed, delete it! If you happen to need it in two years, you can always get it from your backups or git repo.

moblet

Quote from: sdog on February 08, 2011, 04:40:50 AM
At this point i would like to say that i do not suggest using an ab inito or first principles approach or anything near it. I don't suggest against it either. It can be extremely large gains, it could work not at all, in any case it will be extremely much and difficult work i think.
I'm not sure if moblet would pull it and be willing to do so.
When I used the words "first principles" I was thinking in terms of us deciding, before anything else, what fundamental economic and physical principles were important to us. Having done that, then dive into understanding what Standard actually does, all the while with a vision of the "ultimate" Simutrans in the backs of our minds.
I'm quite happy to pull this initially. Once the process starts it will become apparent that it's not impossible, and is relatively uncomplicated, and others should have no problem grasping what to do and pulling it forwards themselves. From the beginning we'd need at least a group of three intellectually engaged with it, preferably many more. There would need to be some degree of organisation and succession planning though because of the uncertainties of my health, which is not predictable in the short to medium term, so it would be a case of aiming to make me as dispensable as possible as early as possible.

jamespetts

Quote from: sdog on February 08, 2011, 04:40:50 AM
It seems i was not very clear about ab initio and first principles, i want to correct this here and provide another example to show the difference to other models, using parameters. First principles and ab initio are used roughly synonymously. (there are some distinctions in quantum chemistry, this might be the case in other fields too)

The starting point for ab initio are, in physics, physical laws, so they are the first principles, in the meaning the most fundamental ones. Assumptions have to be made to reduce the problem to something that can be treated. For example to calculate earths orbit we neglect the rest of the universe. The assumptions define the boundary conditions and approximations to be made.

Typically ab initio or first principle methods require much more complicated calculations than parameter based models. The gain is much higher flexibility. Eg. you can get a lot of empirical data and find parameters or better coefficients to estimate the wear of a road with your pocket calculator. It would perhaps be a ponylomial (i'm guessing here, best ask banksie) a m^4 + b m^3 + c m^2 + d m + e. The real effort is in getting the coefficients. An approach closer to first principles would perhaps model energy deposition, shear and tensions into the road. Typically you have to solve systems of differential equations. This is much more effort but it might provide results for other materials or other effects. (and will perhaps be used to get the coefficients.)

Ahh, I think that I see - so both "first principles" and ab initio are "top down" approaches, whereas the parameter model is a "bottom up" approach? I'm not sure that I understand the distinction at this stage between ab initio and "first principles", but perhaps I don't have to understand that for these purposes. The real issue, as you write, is finding the appropriate coefficients: if there are known specific and tested models for particular things that we want to model, then using those sort of formulae may well be sensible; but if these things are unknown, then a "bottom up" approach is probably preferable. One example where there seem to be known formulae is in relation to road surface wear (as discussed by banksie_82), so it would seem sensible to use those formulae in that field.

QuoteIn the example D would be removed, but not without reason. And if i understood you correctly, you would remove D too, if there is a reason. The reason would be it has more disadvantages to keep D than the benefit it brings. Let me have a very direct example, and i want to point out this is only a hypothetical example:

Let us assume moblet finds the speed bonus system causes very strong distortions to the economy, greatly unbalancing the income. He finds that a system by giving trains that leave at odd hours of the day twice the money and apply black magick to trains leaving at even hours is exactly what happens in the real world and can be implemented. In that case i think you would have no objections to drop the speed bonus system?

Now modify this a little bit. The speed bonus is still fubar in this example, completely skewed results. But moblet finds that no such system at all will provide exactly the correct results. Do you think the speed bonus must be kept?

In your example, the speed bonus would not be removed because of a presumption that features whose benefit in terms of the economic model cannot clearly shown be removed; it would be removed because there was a reason specific to that feature (viz. that it caused significant economic distortions) to remove it. Of course, it should only be removed if there is an alternative (including the system of having flat income despite the journey speeds: i.e., having no speed bonus at all) that causes fewer distortions.

In reality, the price for a journey does vary significantly depending on travel speeds (particularly in relation to alternative travel available on that route, although this element would be difficult to model in Simutrans without introducing an affordability model, which I'd prefer to avoid to prevent players from having to, or having an incentive to and being unable to, micromanage prices), so our simulation would be lacking an important element of reality (a price incentive to reduce journey times) if it did not model what is modelled by the speed bonus in some way or another.

The approach that I take, as mentioned before, in deciding what things to include in the economic model are to discover what is, in fact, economically important in reality and model those. If, in the model, those things turn out not to be significant, then it does not mean that they should be removed, but rather that they are not modelled properly, as, if they were modelled properly, they would have the same significant effect as they have in reality (Moblet's point about the uncertainties of reality can only apply to a few economic effects, as not many significant such factors are dependant on such uncertain contingencies, and it should be easy to identify from a knowledge of reality which ones are and which ones are not so dependant).

QuoteI took the speed bonus for this example not only as it might very well have a detrimental influence on balance, but also because it was coded in experimental by trying to improve a system from standard that seemd completely absurd. Providing speed boni to vehicles just because they have a higher speed.

Now we learned this was as false assumption by almost anyone around, they did it only to have an incentive in pakHajo or pak64 to use more modern vehicles or rather to compensate for the higher running costs of those. In other words it was a solution specifically taylored to a problem in a pak set. It was named a bit missleadingly and after a while other pak set creators thought it is some system to give a bonuse for fast deliveries!

This should also illustrate that we don't know anything about simutrans. In fact it is even worse, we believe things about simutrans. This might very well be wrong.

Here i understand prissis reservations towards experimental much better now. My guess is he does not have the ambition to model reality, he's quite happy with a good game that behaves plausibly or should i say believably.

Ahh - and that is where the objectives of Standard and Experimental diverge! It is the reason that we have two separate branches of Simutrans in the first place.

QuoteIf you want to put a simutrans that should simulate economy and transportation realisticaly on this. And you also have the ambition it should reflect historical developments and work stable over more than two centuries, you might be trying to build a bridge from Dover to Calais on a sand-castle as foundation.

At this point i would like to say that i do not suggest using an ab inito or first principles approach or anything near it. I don't suggest against it either. It can be extremely large gains, it could work not at all, in any case it will be extremely much and difficult work i think.
I'm not sure if moblet would pull it and be willing to do so. The good thing is, if done properly at any time it is broken off, there would be a documentation on simutrans as side effect.

Oh, and of course i would very much like to see such a project, very exciting!

I think you're at a point where you have to decide in what direction you want simutrans to move.

- A technology testbed for things to be included in standard?
- A framework to run pak britain
- A realistic simulation (with a high risk of failure)

Instead of moblets approach you might decide to tweak experimental to get some degree of balance. You might add some additional refinements to the economy, but to get some balance it is not completely unlikely you have to resort to some 'cheating'. Eg introduce artificial money sinks.

I'd like it to be a realistic but fun simulation game - I think that my aim for Experimental I described quite precisely in an earlier post on this (or perhaps the other) thread; the aim is not the same as it would be for professional/commercial non-game software used for modelling transport networks, which is why I use the phrase "simulation game" rather than "simulation"; it must be realistic enough that, within the parameters of what is explicit to the user, a user's decision about how to manage the network will be more or less similarly sensible in the game as it would be in reality (so that, for example, using high-speed express trains on local routes would not be a sensible decision, as it often is in Standard). I'd also like it to be able to engage with the delightful intricacies of various historical features of real transport networks without forcing the player to micromanage: see the discussion of the liveries feature, for example. I particularly like the idea that, when looking at a well established and long developed game, the history of that network in the game should be readily apparent.

QuoteThis is very good for testing. It is, however, extremely bad coding practice to leave code that is turned off in the code. There are at least two major reasons, first you gain nothing. After a couple of revisions it will not work anymore without major rewrite. The second reason is those parts have the nasty habit of being considered to be still active (wrong assumptions), they might get turned on unknowingly (wrong model), they hinder refactoring of code or maintenance. It is a very clear rule. If it is not needed, delete it! If you happen to need it in two years, you can always get it from your backups or git repo.

If things are disabled at the pakset level, then they are not entirely turned off, as other pakset developers might want to use the features. There is at least one other Simutrans-Experimental pakset currently in development (Pak.German-Exp), and the developers of that pakset might want to take different decisions than the developers of Pak128.Britain-Ex about which features are used.

One thing that might be able to go for this reason, however, are the remnants of the original routing system that I had written before Knightly coded the centralised pathfinding system; these were retained in case Knightly's system did not work with the network mode. Ironically, it turned out that the distributed pathfinding system did not work in network mode, and Knightly has now modified his centralised system such that it does work in network mode.
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

QuoteIn your example, the speed bonus would not be removed because of a presumption that features whose benefit in terms of the economic model cannot clearly shown be removed; it would be removed because there was a reason specific to that feature (viz. that it caused significant economic distortions) to remove it. [...] If, in the model, those things turn out not to be significant, then it does not mean that they should be removed, but rather that they are not modelled properly, as, if they were modelled properly, they would have the same significant effect as they have in reality (Moblet's point about the uncertainties of reality can only apply to a few economic effects, as not many significant such factors are dependant on such uncertain contingencies, and it should be easy to identify from a knowledge of reality which ones are and which ones are not so dependant).
Why should something stay if it turns out not to have any effect? Either we find that an effect is needed, but it fails to model it. In that case it can be removed and something new should be coded. Or it has no effect and no effect is required. There is no reason to keep this subsystem, it can be removed, not urgently. But it would be a waste of time to keep it in other versions if it does nothing at all.

Now, here i diverge quite a bit from moblet, i think. If it has no economic effect, it might very well stay if it has not detrimental economic effect but a game play benefit, or models some other aspects of a transport simulation. Reversing trains might be a good example for this. Colourful pak sets instead of plain symbols are another.

moblet

Quote from: sdog on February 08, 2011, 04:04:25 PM
Now, here i diverge quite a bit from moblet, i think. If it has no economic effect, it might very well stay if it has not detrimental economic effect but a game play benefit, or models some other aspects of a transport simulation. Reversing trains might be a good example for this. Colourful pak sets instead of plain symbols are another.
No serious diversion. From a project management perspective I can't help thinking that there are unlimited additions that would offer gameplay benefits, so I see a need for a cost-conscious process for selecting the "best" ones, otherwise everything can be included. Simutrans isn't only about economics, it's got to remain a cute transport simulation too  :)

jamespetts

It seems that the issue on whether to remove features is a rather marginal one in the grand scheme of things, especially as it is vanishingly improbable that any given feature will have literally no effect at all on the game, whether economic, cosmetic or otherwise. My point is simply that, in cases of doubt, the default position should be to preserve the status quo. The highly improbable finding that a given feature certainly has literally no impact whatsoever on any aspect of the game whatsoever is not a case of doubt.

Hopefully having moved passed that issue, perhaps we can return to the more pressing issues of the structure of the proposed project and who is to do what? It would be very good to make some serious progress in this regard, as having a well-balanced game would substantially improve the enjoyment that can be derived from it by all.
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 February 06, 2011, 08:17:29 PM
Here is a continuum of routes between major extremes possible: Standard team is willing to implement the identified needs, if fitting solutions from experimental can be adopted or newly coded with experimentals very valuable experience.
The standard team has explicitly refused to implement the single most important change in experimental -- the switch to revenue based on average or actual speeds rather than theoretical top speeds.  This is relatively simple to implement in at least three different ways (ahem), and is absolutely necessary in order to provide any semblance of realism (the "TGV-on-sand-track" bug), but so far they have simply refused to consider it.

As long as that is the case, I do not think there is any point in considering standard as the baseline for balancing -- it cannot be balanced while being plausible because of the bug which they are unwilling to fix.  If the willingness to fix this changes, we can reconsider.

Just to point out my view here.