As discussed briefly
here (http://forum.simutrans.com/index.php?topic=985.0), there might be some substantial merit in adding to the existing "beginner" mode an "advanced" mode that includes additional elements of economic and operational complexity over and above the existing game, and also things that might add function but affect the performance of the game, but within the bounds of what is still playable on a reasonably high-performance computer.
The reason for such an innovation would be that, as I have found when suggesting new features that add economic and operational complexity, there is a great difference of opinion in whether such additional complexities would make the game more fun, or whether they would make it too difficult and/or confusing for newer players. An "advanced" mode in which the more complex features are activated would enable those who want those features to use them, whilst not adversely affecting those who do not want them.
It should be fairly easy to implement on a code level: all that would be needed is a single bool flag in the options class for "advanced mode" with a get accessor that returns false either if that flag is set to false
or if the beginner mode flag is set to true (one cannot be in advanced and beginner mode at the same time!). Some thoughts as to possible features of advanced mode:
- way constraints (discussed here (http://forum.simutrans.com/index.php?topic=985.0));
- weight limits for ground-based ways (apparently, there is already some code for this, but it is not complete);
- long-term economic fluctuations, perhaps including cyclical demand, and modelling the effects of increased car use over the years on passenger numbers;
- a more proactive public service player, perhaps slowly building power stations and inter-city roads during the game; and
- a requirement that all electrification be connected to a power plant/substaiton in order to work.
I should be interested in any thoughts on the idea of an advanced mode, and what might be included within it.
I should be noted, that I wanted the game to be deterministic, i.e. without random event like depressions and so on.
Moreover, power stations are now constructed during normal growth.
The biggest problem I see, is that after a certain level money is of now importance, i.e. is not the incentive to sucessful game play. Rahter the wish to provide full connection to very station or so.
Prissi,
thank you for your reply :-) It is always interesting to know from you what your ideas about what Simutrans should be are. Economic fluctuations need not be random, as discussed in this (http://forum.simutrans.com/index.php?topic=1024.new) thread. Thank you for pointing out about power stations: that is an interesting development.
As to the finances, indeed, making the game more financially challenging in the later stages is something that could be developed in Simutrans. Even if one takes as one's goal the public service aim of simply connecting stations, that itself is lacking in challenge if funds are overflowing: even government backed transportation companies do not have infinite wealth, and have to work within considerable financial limits. Even if the ultimate aim is not to make money, therefore, financial constraints are still important to ensure challenging and fun gameplay (and for those who dislike financial challenge, there is always -freeplay).
I have been hesitant to say anything about these ideas for fear of being labeled as someone who is just always negative. However due to the number of suggestions and my feeling about the trend of all of them, I must speak up.
Complexity does not necessarily equal fun. As proof I offer the example of chess. Complexity is often no more than a necessary evil in a game. Often it takes complexity to offer choices in a game and choices, I believe, are key. Being able to see two moves away and having several choices is interesting. Finding out five moves later that you made a good choice is fun.
Having a lot of rules to learn and follow is only interesting until you learn those rules. Once learned, the process can be repeated indefinitely. To me, anytime something is added to the game, unless it is out of necessity, the aim should be toward adding something that gives the player choices in the way to proceed; not in the mechanics of how to proceed, that should be clear; the outcome of the player's choice should be unclear with many, if possible, pathways to both success and failure.
What I like about Simutrans is the almost infinite ways that you can play it. There is no fixed target, no best way of playing and there are like 100 options you can change. I'm playing it quite heavily (a few evenings in the week) for two years after I rediscovered it (played the 81-84 versions a few years before that) and I'm still enjoying it very much. I usually do freeplay, so I'm not (too) worried about finances. I normally just want to connect all that can be connected. That's a different approach than yours and (for me) it's fun. It's fun because you must solve the problems of overcrowded stations, non-producing factories, vehicles that get stuck (some way I always manage to do that...).
I don't mind there being an advanced mode, but the "advancedness" (I'm quite jealous of jamespetts mastering of the english language, though things could be shorter ;)) for me is in those mass of options you have. So in my opinion an advanced mode is not really necessary.
As to what it should contain: well, the best approximation to real life, but within limits of what is technically possible. I think THE main attraction of Simutrans is the way it smoothly handles a complex transportation network. That's by no means an easy task. But there are limits to what you can do. Whatever happens, I would like to keep it smoothly. If I ever have to choose between reality and performance, I would have the latter.
Just my two cents... eh ... Simucredits.
How about making a new project "Advanced simutrans project".
In that case, you can change everything without asking prissi.
After that, you could release your test version for players, and could get more feedbacks from them.
But I don't know this forum allows you to make a new sub board or not.
Thank you all for your replies :-) Roads: of course, extra complexity does not necessarily make the game more fun: but the right kind of complexity can make the game a great deal more fun - for some people. Other people prefer relative simplicity. As Combuijs pointed out, one of the good things about Simutrans is the number of options, which enables Simutrans to cater to a range of players with different preferences; and he raises, I think, a good potential alternative to "advanced mode": instead of having all the advanced features that I suggest turned on or off at the same time by a binary "advanced mode", let the player choose which features to turn on and off individually. Which features are turned on by default ought perhaps be a question for Pakset authors who write the simuconf.tab files. That would certainly be an easier approach as far as coding is concerned: just add new features one by one connected to options in simuconf.tab, then document them and let people turn them on if they want to do so. If the new options are coded such that entirely absent the new parts of simuconf.tab, the new features are disabled entirely, then the status quo is preserved by default.
Z9999, your idea is an interesting one, but I think that the difficulty with that is that I, at least, do not have the time to maintain an entire branch of the code. The position might be different if there were others who had the time and inclination to do so. However, if the individual additional options were added to the main code one by one and made entirely optional individually, as suggested above, then there would be no particular need to have a separate project; indeed, would it not be better to have a single Simutrans with lots of options rather than two Simutranses, each with different settings? That would seem to be more efficient in terms of developer time overall, and far less confusing to new (or even seasoned) users.
Yes jamespetts I think that is an excellent idea for the user in advanced to mode to have the ability to select which options he wants to play. Like Combijus, I play an entirely different game from what I suspect most people play and I love that Simutrans allows me to do that. I would hate to see development effectively suspended on normal Simutrans in favor of advanced, only to see a lot of features in advanced mode that I dislike but must tolerate in order to play the ones I do.
As I've stated before I like very small networks, very few trains (and, sorry but I despise double tracking also); I never play freeplay and always play with "obey chronology." I hope that further advancement does not make this type of game impossible as other enhancements are added.
Roads, I suspect that there are almost as many different ways of enjoying Simutrans as there are Simutrans players, and the more that that can be extended, the better. I understand your concern about development priorities - it is a matter of sharing development time amongst different features, not all of which will be of interest to all players. I was considering coding some of the advanced features myself, leaving the main developers to do nothing more than test them and add them to the main code (although some of the more sophisticated additions I may not be able to achieve without some assistance from the main developers).
I think what Combuijs suggested was not to have an "advanced" mode at all, but just put all the "advanced" features into the game as options that can individually be turned on and off, which would add flexibility, and which would be rather easier to code than adding a whole new mode of play.
Incidentally, it is very interesting to me to see the different ways in which people like to play Simutrans. I tend to play Simutrans (except when testing, which is a different matter) with freeplay off, with obey chronology on, and tend towards large, complex and interconnected networks, with particular interest in rail networks. I tend to like playing from the mid 19th century to the modern day, and am particularly fascinated by the idea of historical trends that have shaped real railway/transportation networks independently shaping my network in the game, even though I am playing simply with the aim of maximising profit and/or service quality. I am very keen on simulation games with complex and interesting emergent properties of the various layers of gameplay, especially when those emergent properties are highly realistic and make the game world turn out very much like the real world, without the player being motivated by anything other than success as defined by the game (even though the player's decisions end up being very similar to the decisions of people in the real-world equivalent situations). I like games in which the player can succeed without excessive number-crunching, where the player has to deploy heuristics in order to make good decisions (because the raw numbers are too complicated and/or hidden from the player for number-crunching to be the most successful strategy), and especially where those heuristic decisions are exactly the same heuristic decisions as would lead to success if the thing that was being simulated by the game was real. The "advanced" features that I have been suggesting, therefore, are, perhaps unsurprisingly, features that, I hope, will tend to make Simutrans (at least, with the appropriate options set) tend more in that direction.
The key issue is: If you are not doing it,who is it to do then?
As z9999 pointed out, branching is quite ok and expected for Open Source. Then of course a branch must maintained. You know I had less than two hours simutrans time per evening for the last two years and still I had to manage translations, pak64 (and pak japan to a lesser degree) and bugfixing and programming sometimes new stuff (or more recently to integrate patches).
There is always time, if you really want to do something ...
Prissi,
the point was more that branching would involve me doing work that wouldn't have to be done by anybody if the code was not branched at all, but the changes integrated into the main code and made optional. I am looking at producing patches for at least most of the suggestions that I have made (I am still testing an updated version of the passenger destinations patch at present), and those that make gameplay more complicated can easily be made optional by settings in simuconf.tab.
Edit: Perhaps instead of branching the code, my patches could be integrated into the main code but turned off in the default configuration files, and I could just branch the config files, and provide a set of files with the advanced features turned on by default? If that was done, pakset authors would have control over which, if any, of the additional features to apply, and there would not be two separate sets of code to maintain.