Topic: When are patches included and when not?

[Fabio]

Well, actually, for quite a lot of the new developments, there are settings in simuconf.tab that can be used to revert to pre-patch behaviour, or something close to it.

so why aren't they included in the main trunk and only disabled by default in simuconf? testers should only need to update their simuconf instead of downloading a whole new release...

EDIT by prissi: changed topic.

[prissi]

Because several of those patches are either against the way simutrans should be (or I and Hajo tried to let it be), or are too resource hungry or are too unstable.

I am aware that this is a rather ill-defined and general criteria. I want to keep Simutrans on a fine balance between to much efforts and too less challenge with as little introduction into the code as possible and as much freedom to the player as possible. Especially things only for a single pakset are not very likely to be introduced. For most patches I wrote a more or less long explanaition in their threads.

Of all those features the weight limit is one which may see incorporation into the trunk someday. On the others I am much less certain.

[Fabio]

But once they are tested and deemed stable, they could enter the trunk and being disabled by default. So only the player who want those behaviours could enable them.

[prissi]

Well, this still means I have to support them. And a lot of them cannot be simply disabled, but needs their structures in place anyway. Thus the answer is really it depends.

[jamespetts]

Because several of those patches are either against the way simutrans should be (or I and Hajo tried to let it be), or are too resource hungry or are too unstable.

Can you elaborate a little more? I was not previously aware that you took this view of the patches. It would be extremely helpful to know, in respect of each patch, the reason that you have concerns about it. In particular, which ones are unstable? If you have found any bugs in my patches, please let me know so that I can fix them! And which ones are too resource hungry, and what is the extent to which they slow the game (even when disabled)? If there is a problem with the coding work that I am doing, it would be very helpful to know as much as possible about it!

[Spike]

Right now I see only one in the list which is against an idea that was decided long ago:

2. increase of running costs for obsolete vehicles, both explained further here.

Once there was a decision that this should not happen. The other patches I see as a result of the course of events that has started long ago, to make Simutrans more and more complex.

While I sometimes ponder about digging out the sources of 0.84.20.x, fixing a number of bugs there and declaring it Simutrans final, I see that some (many?) players want this kind of complexity.

At the moment I'm happy with the idea of Prissi maintaining a conservative version that strives for stability and an experimental line that tries to be more avantgarde.

Prissi is IMO right that, while he needs to maintain the code, patches that will not be used by default, but add work (*) for him, will not go into the main trunk. That's why I encouraged (and still encourage) the split of "Simutrans Experimental" from the main development line.

(*) Work not only for adding the patch, but also maintaining it, since it can very well be affected by future changes to the codebase.

[jamespetts]

Hajo,

thank you for your interesting contribution :-) Out of interest - what was the reason that you decided against an increase in running costs for obsolete vehicles?

But I do see that the approach of a conservative versus avant-guarde version (as you put it) has some merit. Perhaps I should find Simutrans-Experimental an SVN home somewhere?

[ansgar]

Perhaps I should find Simutrans-Experimental an SVN home somewhere?

I would recommend *not* setting up another SVN repository.  As far as I know, SVN cannot import changes from other repositories so you cannot import changes to the regular simutrans version easily.

Maybe you can get write access to a branch in the official repository?  Or just use Git which should make this much easier.  I did set up a mirror of the SVN repository on http://www.github.com/aburch/simutrans.

Ansgar

[prissi]

Well, this thread is slowly (or rather straight) striving offtopic:

I try to maintain a style that does not force the player to:
- transport a certain kind of goods prefareable (i.e. allowing goods only plays)
- add complexity without any advantage (thus I am still not sure about the income check and reverted to the original behaviour) For the same reason use based priced or QOS will not go into trunk I think.
- forces to use certain modes of transport (citycars with destinations would need road => not activated)
- weight is under consideration

The more simple a game is the easier is it to enter into it. You know, checkers does not need a lot of rules to be a challenging game. And Codewise I like to have the code as clear and as less complex as possible. Updating additional structure need a justification. Just "adds complexity to the game" is not enough.

On a different note the game is complex enough for most people. I have always OpenTTD as a bad example. Resently the order window is so overcrowded with options that your really need a manual to understand them. Same goes for their signalling system. They have also a zillion patches. While this adds flexibility, there are also complains that this or that is not enabled when doing multiplayer games.

If I would have to make it short I would say freedom, flexibility and simplicity (or better elegance) are the goals I try to achieve and preserver.

[jamespetts]

Prissi,

thank you for the reply :-) However, I was primarily interested in the stability/performance issues, since the gameplay points are a matter of preference (although I would say that I choose to play a transport simulator rather than draughts for a reason...)

Ansgar,

how about an SVN repository for the patch?

[Spike]

Hajo,

thank you for your interesting contribution :-) Out of interest - what was the reason that you decided against an increase in running costs for obsolete vehicles?

Some people use Simutrans more in the style of a model railway sandbox. They want to use the vehicles all the time, just because they "fit" into their idea of the sandbox. While freeplay mode allows that even with raising maintenance costs, it's still somewhat annoying to see your balance going more and more negative (or see the ruinning cost go up more and more), like a reminder you play the "wrong style" or with "the wrong vehicles".

Thus we decided that running costs should be fixed, and people can have profitable routes with those vehicles, even long past their official lifetime.

Some changes in Simutrans already hampered this idea, but well, once it was meant to be this way.

If I would have to make it short I would say freedom, flexibility and simplicity (or better elegance) are the goals I try to achieve and preserver.

I fully support this statement.

[VS]

I believe "transparency" is one of the other words we want to be associated with Simutrans...

[jamespetts]

Some people use Simutrans more in the style of a model railway sandbox. They want to use the vehicles all the time, just because they "fit" into their idea of the sandbox. While freeplay mode allows that even with raising maintenance costs, it's still somewhat annoying to see your balance going more and more negative (or see the ruinning cost go up more and more), like a reminder you play the "wrong style" or with "the wrong vehicles".

Thus we decided that running costs should be fixed, and people can have profitable routes with those vehicles, even long past their official lifetime.

Some changes in Simutrans already hampered this idea, but well, once it was meant to be this way.

I'm not sure that I really understand the reasoning here, as, if a player wanted to play in true sandbox style, he/she could simply disable the timeline, which would then also disable the increased maintenance costs of obsolete vehicles.

But, really, it strikes me as somewhat odd to leave out a feature of some considerable importance for those who want to play with fully realistic economics (with freeplay off) simply because those who wish to play in sandbox mode (but with the timeline on) might not only notice the difference in the maintenance cost of obsolete vehicles, but be irritated by it. I don't see that as a tradeoff that makes any sense.

[prissi]

Some feature addcomplexity without any new experience. Those should be avoided for a goodgame. (In the old forum there wasalong thread on this.) Micromanagement is a nono for instance.

Also features for being more "realistic" are not useful, since simutrans in per se unrealistic. The scales are off, and so are the times. But income is time dependent thus ... Simutrans does not simulate reality (non of those games do) but provide an entertaining game.

Simutrans left lots of options out, not loans, not stockmarket, which would be available in reality. The reason is, that we want to be transportation the challenge, not maximizing the revenue. Transportation should be the core of a transport simulator.

Also in different countries different modes of transport are used. And while maybe in germany old track are constantly replace in US you can find still some of them laided shortly after the golden spike was driven into them (albeit not too often of course). And public transport by train in an anachronism in the US but reality in Japan or Switzerland. Which to take for a transport simulator? Reality is a really cultural biased thing.

Freedoms allows player to adapt thing to their liking.

[jamespetts]

Prissi,

interesting thoughts. Of course, you are correct in stating that the ultimate goal is to produce something that is entertaining (and perhaps also informative: I, for one, think that the best simulation games are ones in which one can learn about the reality of the thing being simulated by playing the game) - the complicating factor is that what entertains some people is different to what entertains other people which is why, I suspect, that some people think that adding certain features adds complexity without merit whereas others think that those features are very desirable either in spite of or even because of the extra complexity that they add: the difference is in how entertaining that those individuals find the effects of those features.

One thing with which I do not agree about what you have written is in respect of realism: it is, I think, too simplistic simply to state that, because Simutrans is not exactly like reality in every respect, there is no value in making any aspects of the game more rather than less like reality. Realism versus entertainment is an entirely false dichotomy - up to a point, a simulation game is more entertaining the more realistic that it is. People's preferences differ, of course, as to where that point is. However, a simulation game that is more realistic is, all other things being equal, easier to learn, since one only has to know about the reality of the thing being simulated in order to play it effectively, rather than special rules that apply to the game but not the reality. If things work in the game more or less like the work in real life, players will have a pretty good idea of what will work and what will not just by thinking of the game as if it were a real-life situation, which is likely to be more familiar to the player than the game itself. Also, for many, it is likely to be more satisfying to think that they are making decisions that are successful in the game knowing that the game is realistic and therefore that those decisions, in a broad sense, would likely work in reality, too.

Freedom does indeed allow players to adapt things to their liking, although, in terms of a game, at least, freedom includes the freedom to choose to be constrained by interesting rules, requiring the player to make interesting decisions about how to succeed within those constraints. As to "micromanagement", again, it is a matter of taste to some degree - one person's micro is another's macro. The real criticism of true micromanagement that extends in most cases beyond mere preference is a game that requires a player to take a very large number of trivial (and therefore uninteresting) decisions in order to succeed and do well. The best games are those that give the players all the interesting choices, that let the player be creative and exercise intellectual problem-solving skills, and leave all the uninteresting choices (cases in which there is always a single obviously right answer, or cases in which the correct solution can simply be calculated by some fairly straightforward arithmetic - a game in which the player has to perform frequent arithmetic in order to do well is not, in my view, a fun game at all) to the computer to perform automatically.

Whilst I appreciate that the patches that I write, therefore, might not be to everybody's taste, I do not agree that they give rise (unless as an unforeseen consequence, in which case I should very much like to know about it) to any micromanagement in the sense that I describe above.

Incidentally, you didn't reply to my previous question asking about your comment on instability and resource consumption - did you mean that in respect of any of my patches? As I wrote before, if you have found any bugs or unacceptable performance hits from my patches, please let me know so that I can try to rectify the problems!

[prissi]

Realistic games are flight and train driving "simulators". The simulated train from Newton to Brighton takes eaxctly the 1h44min it takes in reality. Any real simulation (i.e. without predefined outcome) is by default less complex than the reality. Or where is the fully functioning brain simulator. For scientific simulation you need to be as close to reality to be meaningful.

For games it is more difficult. Especially OpenSource games. You do not want to scare people away by too complex rules. You cannot allow to make everything customable or documentation would get more meaningless as it already is. You cannot expect people to wait 20 years for achieving meaningful growth. Or lets take SimCity. It feature earthquake, town fires and reactor meltdowns in a frequency which is usually only seen half of it for the entire world. Apart from bribing and what other stuff has gone in there since I played it last time ten years ago.

But SimCity and Simutrans need not to simulate reality, as they are no simulators, despite their names. They are strategy games. As such reality is only needed as motivator. (I will comment on patches later.)

[jamespetts]

The question really is the degree of realism: everyone agrees that trains shouldn't be allowed to fly and money shouldn't grow on trees: the live questions are whether stations should be able to accommodate tens of thousands of passengers, or whether the proportion of people willing to use trains and 'busses should be the same in 1990 as in 1890, and things of that nature. But physical operational simulators are not the only sorts of games in which realism is significant: economic realism can be just as significant as graphical or physics realism, and, in many cases, more fun.

Obviously, some element of simplification is required for a game to be entertaining. Again, different people have different preferences as to the degree of realism. But it is most emphatically not true that it is always useless to make something more realistic in a game. Whether it is useless or not depends on what it adds in terms of gameplay function. What rules are "too complex" is, again, a matter of preference.

Finally, I do not agree that the only function of realism in strategy games is "as a motivator": the importance of realism is, as noted above, that people can understand how the game works by understanding how the reality works, and understand more about the reality by playing the game. Even with enough simplification to make it a workable game, that is still a worthwhile objective. It can, in and of itself, make the game more fun.

[Spike]

The question really is the degree of realism.

Simutrans was meant to be lenient with realism. Realism never was a goal per se.

Time, size, proportions, were not meant to be realistic. I know many people demand this, and it has changed over the years under the ongoing pressure to become more realistic. But it's not been my goals, and as I understood, also not Prissi's goals.

I, and I think Prissi, had the goal to develop a working transport simulator. Working in the sense that there are goods, producers, consumers and vehicles to transport.

A side goal was, that it should be fun to develop the transportation.

It was not, and is not, required to be realistic in any level. In the beginning I even voted against vehicle names that exist in real, but someone just changed the translation files to realistic names, and I was too lazy to change them back.

But really, I chose sizes, timescales and such only in order to make the game work. Realism was not my intent.

And actually, I think the structures of Simutrans are not very well suited to a realistic transport simulation. They suit better for a slightly abstract game.

Anyone is free to take the sources and change that fact. I'm just telling how it started, and how it was maintained a long time. For me "more realism" is not immediately linked with "more fun". I like games that abstract from reality.

[jamespetts]

Hajo,

thank you for the interesting historical perspective! Aside, for a moment, from the question of how much realism is desirable, there is the capability in Simutrans, from what I understand of it, to introduce additional elements of economic and operational realism without making the game unbalanced. It might be thus less desirable to those who prefer it in its current state, but, although Simutrans is designed for a certain degree of abstraction, that is not necessarily incompatible with realism.

In any event, I do agree with your earlier comments (and comments on another thread) that there is something to be said for giving the users a choice as to how much realism that they want to have by choosing between different branches/distributions - with opensource, one can please all of the people all of the time (well, more or less)...

[Spike]

Some people demand realism as in correct proportions, scales, speeds, timeflow and such. This is the kind of realism that deos not fit well into Simutrans. The graphics engine and map structures are not designed for that. Still many people try to have big/long vehicles, despite all the problems that come with them.

Economic changes, or changes in the passengers behavior, in order to get closer to realism will fit better into Simutrans. Well, at least the structures are there and flexible enough to allow such.

In this case we just need to take care of those people who want to play a sandbox railway system, or similar. Also the casual players who are not into railway signaling so much, and who already struggle a lot with the complexity that is present nowadays.

In the forums often economic experts, transportation experts or railway experts speak up, and request their most favorite part of the game made more realistic and complex. The casual players have little voice in the forums, and requests like "make it simpler, for the people who just want to play and move goods around for some moneys", will seldom be told - the people who want that are either not here, or don't dare to speak up because the "experts" have such a strong, and also well founded, opinion on how things should be.

So it's rather difficult for a game designer and project maintainer to find the right balance. In forums like this, about 1% of the players speak, but the other 99% who also play have no voice, but must be considered as well in project development decisions.

[Dwachs]

So it's rather difficult for a game designer and project maintainer to find the right balance. In forums like this, about 1% of the players speak, but the other 99% who also play have no voice, but must be considered as well in project development decisions.

How to develop a game for these 99%? Everything would be based on pure guessing! And arguments, which try to take care of these 99%, are very weak.

I wonder why nobody refered to the KISS-principle yet: http://en.wikipedia.org/wiki/KISS_principle

[Spike]

How to develop a game for these 99%? Everything would be based on pure guessing! And arguments, which try to take care of these 99%, are very weak.

I just wanted to point out why I'm reluctant to base decisions solely on the voice of what I think are 1% of the players population. Also tried to point out that there are more players than just the people who speak in the forum. I think these facts get forgotten in discussions way too easily.

I agree that we cannot know about the opinions of those who are not here. But we should keep in mind they are there.

I wonder why nobody refered to the KISS-principle yet: http://en.wikipedia.org/wiki/KISS_principle

I hope, no one mentioned it, because it is well known to everyone and people keep it in mind all the time.

My personal opinion is that it works great for technical questions, less for questions of entertainment, though.

Edit: Dwachs message reminded me why I'm pro splitting the project and developing variants: There are so many opinions and wishes, it's not possible to get together in a discussion easily, and most likely the demands of the players are as varied. So I'm happy that James started his own variant, and that Prissi maintains another one.

Edit 2:

How to develop a game for these 99%? Everything would be based on pure guessing!

Another answer from a game developers forum: Basically one doesn't. Maybe if you are a business, but independent developers don't. One makes a game that one likes by oneself. One includes the ideas that deem the right and good ones. One listens to players, but makes ones own decisions.

There is a rule of thumb: players know, if something is wrong. Players do not know what the right solution is. So listen to complaints, but do not listen to prosed solutions for those problems. One should find ones own solutions, that work well with the game.

This is not entirely my own opinion, but I'm leaning strongly towards it.

If the ideas do not catch players, it will tell you that you are fairly alone with your wishes, but doing what you like to do, and make a game that you like, is most likely the better driver for a hobby, than to make what others want you to do.

Edit 3: Simutrans no longer is a hobby, thus the last point is not very relevant. But what I said in my first "edit" is most likely the best what we can do in the current situation - widen the scope of Simutrans, and offer different versions for different audiences. "One size fits all" usually just means it doesn't fir well for most. So better have a few choices. PAK64/PAK128 and the other PAKs already started it, and branches of the executable will take it a step further.

And now I'll try to remain silent again for a while. Sorry for the big amount of text.

[Dwachs]

Thank you for your answer!

One makes a game that one likes by oneself. One includes the ideas that deem the right and good ones. One listens to players, but makes ones own decisions.

There is a rule of thumb: players know, if something is wrong. Players do not know what the right solution is. So listen to complaints, but do not listen to prosed solutions for those problems. One should find ones own solutions, that work well with the game.

Sounds very reasonable! Thank you for sharing your thoughts.