Simutrans experimental - My thoughts

[Djohaal]

As asked by jamespetts here are my thoughts on simutrans experimental features. I'm using the features list from the sticky thread as a guide to post my analysis.

First and foremost though I have to confess that I only played SE for some 40 minutes due to hectic university, however I plan to give it a more through testing later on. Jamespetss seemed quite eager to listen to some feedback that I figured I could at least read his feature descriptions and compare it to my experience on vanilla simutrans as I'm a long-time player (altohugh big lurker) 

Revenue calculation: Certanly an improvement over the default simutrans system (which is plain exploitable due to the max speed component). A very welcome mechanic.

Debt handling: Equally a nice improvement over the default system, the default simutrans finance simulation is quite bland IMO. As a hook, I wonder if the graph views could be reworked into a more robust system that could show up income rates and such for any time interval? Sometimes it's difficult to compare historical series based only on the per-year and per-month tables.

Industrial Obsolence: An interesting mechanic, however I'm a bigger fan of static industry chains which wouldn't jeopardize infrastructure with their potential closure. The replacement system however is a very promising idea that could allow us to enrich the gameplay in several aspects. For instance after the 90's car industries could be replaced by models that demand electronics and such. I'm planning a large expansion of the industry chain system in pak128 and perhaps such replacement system could come in handy.  Perhaps an option to allow industries to be replaced but never close down would suffice.

Passenger genaration: Another nice idea which can be turned on and off. It has potential to need some very fine balancing, however I haven't played SE enough to reliably notice what might need improvement.

Journey time tolerance: Same as above.

Private cars: An excellent improvement upon the original system.

Obsolete running costs, fixed maintenance, scale: All interesting features which can allow more flexibility of the simutrans core engine and more realism (the fact in vanilla vehicles cost maintenance only when they move is rather exploitable)

Station capacities and costs: Well all I can say is that I can't beleive vanilla simutrans keeps this "levels" system.. 

Depot traction types: Unecessary clutter. Perhaps depot monthly maintenance could be read from whether it's tile is electrified or not. I can't imagine a huge difference in structure that a depot would need to serve steam and diesel engines...

Geometry: Go euclidian, go! 

Industry generation: Another very good improvement upon default simutrans. Only issue I can imagine is a bad map gen putting all end consumers on wee-tiny cities. Perhaps some weighting of the odds could be implemented to assure at least some of them are in larger cities. The city growth bonus for delivered goods might need some balancing.

Routing and overcrowding management: Excellent improvements however I don't know what can be their performance toll on the long run in very large maps (I personally play on maps that are /at least/ 1536x1536)

Weight limits: Perhaps a bit unecessary, I imagine this could be abstracted as part of the base speed limit of ways, however it can be turned off entirely so it's not a very big problem. I have yet to fiddle with this a bit more.

Cornering and physics: They don't add excessive clutter to the game's complexity, my only concern is about performance degradation on larger maps.

Way Constraints: While an AC/DC restriction sounds a bit excessive for all intents, I can undestand the need of some kinds of constraints for metros and such.

Reversing: The function seems to be pretty automated and the usage intuitive, so I guess why not

Overcrowding: Another interesting mechanic, but my question is how to feedback this to the player in a clear and intuitive way.

Loading time: Yet another interesting approach, however could add to unecessary complexity if the player doesn't know what he is or not doing. An overhaul of the depot interface should be in order so we can add a "comments" section to our vehicles to help the player to see wether what he's picking is a long-distance train or a suburban networker would be very welcome.

Scheduling: Again clarity for the user should be the main focus.
The fractions-of-a-month interface in simutrans-standard is quite unintuitive, it'd be helpful if it could be translated to how many minutes/hours of the "day/month" it'd take.

Braking: Automation of the feature should be a key point here. The presignals you mentioned shouldn't become obligatory to be sure the system runs smoothly, for instance.

"miscelaneous" features (city electrification, convoy replacment, etc): all quite good.

[prissi]

Station capacities and costs: Well all I can say is that I can't beleive vanilla simutrans keeps this "levels" system.

Actually, what is the differences? Levels and different cost can be realized by vanilla simutrans too? Just the paks do not use this.

Industry generation: Another very good improvement upon default simutrans. Only issue I can imagine is a bad map gen putting all end consumers on wee-tiny cities. Perhaps some weighting of the odds could be implemented to assure at least some of them are in larger cities. The city growth bonus for delivered goods might need some balancing.

I was under the impression that experimental uses the same placement routines are standard. At least this was stated by james just in the other thread. Thus the placement should be the same. What is different is the city placement.

[Djohaal]

Actually, what is the differences? Levels and different cost can be realized by vanilla simutrans too? Just the paks do not use this.

My ignorance then. I should check the differences properly later.

I was under the impression that experimental uses the same placement routines are standard. At least this was stated by james just in the other thread. Thus the placement should be the same. What is different is the city placement.

Yes it apparently does, although the city placement routine was overhauled. My point is that if it picks random cities to place the end consumers, you might end up in a map that has a severe bottleneck at the consumer industries if they all end up in small cities.

Again as I stated on the first post, those comments are based mostly by comparing his feature list and my tradition on playing simutrans vanilla. I intend on doing a through testing of SE and writing up a more informed review

EDIT: Also james I'm on the IRC atm. I can't seem to be able to send PMs yet, guess it's anti spambot rules.

[jamespetts]

Thank you very much for your feedback - that is most useful. Note that the AC/DC constraints are pakset specific and not part of Experimental itself. The feedback for overcrowding is that the names of overcrowded lines/convoys are shown in purple.

As to the industry placement: the placement itself is unchanged from Standard, but very recently (version 9.4 and above), consumer only industries in towns have their consumption rates determined by the relative size of the town at the time of placement (always within the existing range of consumption rates).

[Djohaal]

Thank you very much for your feedback - that is most useful. Note that the AC/DC constraints are pakset specific and not part of Experimental itself. The feedback for overcrowding is that the names of overcrowded lines/convoys are shown in purple.

As to the industry placement: the placement itself is unchanged from Standard, but very recently (version 9.4 and above), consumer only industries in towns have their consumption rates determined by the relative size of the town at the time of placement (always within the existing range of consumption rates).

I've given pakbritain and SE a spin this afternoon. What I can think off the top of my head is that most features aren't as overbearing as they seem by reading. Their implementation on the game was (mostly) quite smooth. However here are some concerns:

1: User interface cluttering: I think a submenu system for different ways could be in order to allow us to pack up so many speed/tonnage combinations in a single place. Although I think pakbritain's icon design also has a bit to blame as the ways are all so similar. Perhaps slightly bigger icons with annotation of their speed/tonnage on them would ease up the job of picking the proper way when building. Bridges are specially confusing.

Although I beleive a submenu system which could be edited via the pak system would be most helpful to pak creators. Say, you could create a button "masonry viaducts" in the road section, and when you click on it you open a submenu with all such viaducts.

2: tonnage: The hard limit on tonnage is a bit annoying because often the loaded vehicle might exceed the tonnage of the bridge it pathed, so you get late alerts of tonnage exceeding. Perhaps instead of forbidding pathing, ways could accept up to 50% higher tonnage than their limit, while imposing a progressive speed penalty the heavier the crossing vehicle is.

[jamespetts]

Thank you again for your feedback. I am glad that you find that things work smoothly in practice - the idea of Simutrans-Experimental is to be swan-like in complexity. The issue of the ways with PakBritain is that we have not got around to drawing subtly different graphics for all of the different ways yet - but your suggestion of adding text to the icons for (for example) light, medium and heavy variants of each type has much to be said for it. As to submenus - did you play with the timeline on or off? With the timeline on, the options are far fewer, so there should be less clutter.

As to weight, Simutrans-Standard, I understand, is soon to implement weight limits, which, taking from the experience of Experimental, will always use the loaded weight to determine the weight limit, to avoid the issues about a vehicle being fractionally over the weight limit when loaded. My preliminary view is that it will be sensible to implement the system from Standard into Experimental, when it becomes available, so as to synchronise the two versions.

[Djohaal]

Thank you again for your feedback. I am glad that you find that things work smoothly in practice - the idea of Simutrans-Experimental is to be swan-like in complexity. The issue of the ways with PakBritain is that we have not got around to drawing subtly different graphics for all of the different ways yet - but your suggestion of adding text to the icons for (for example) light, medium and heavy variants of each type has much to be said for it. As to submenus - did you play with the timeline on or off? With the timeline on, the options are far fewer, so there should be less clutter.

As to weight, Simutrans-Standard, I understand, is soon to implement weight limits, which, taking from the experience of Experimental, will always use the loaded weight to determine the weight limit, to avoid the issues about a vehicle being fractionally over the weight limit when loaded. My preliminary view is that it will be sensible to implement the system from Standard into Experimental, when it becomes available, so as to synchronise the two versions.

Sometimes in timeline it still has too many ways. At least 1960 (the primary year I played around) has a lot of railway bridges specially. Another foreseeable issue is when playing through very long games (With pak128 I like to start on 1930 and go all the way to 2000 or more) there'll be needed constant way upgrading. Usually this isn't very smooth on very long ways and ways with diagonals (specially double ways). Perhaps a dedicated upgrade way tool or keyboard shortcut could be implemented to make the upgrade call only be applied on already built ways much like cantenaries?

Another troublesome issue is the multiple traction depots. I didn't really find any useful gameplay enrichment from them, just clutter...

[jamespetts]

As to the ways, that's an interesting suggestion about the way building tool (note that holding down CTRL when building ways can constrain them not to join each other, making diagonals easier); that might be a worthwhile suggestion for Standard  (as ways need to be upgraded there, too). 1960 is somewhat of a transitional time, however, so you might find more ways than normal at that moment in history. Things will be somewhat better, I think, when there are different graphics for each type of bridge, as is eventually planned. The necessity to upgrade ways over time is realistic, of course.

Incidentally, a game starting in 1930 and ending in 2000 is not, in the grand scheme of things, a long game for Pak128.Britain-Ex: it is designed to be able to run from at least 1830 to the present, and has some capability to start as early as 1750 (although options then are limited). Certainly, a realistic development of railway networks over time is not possible starting in the 20th century, and any realistic canal developments require an even earlier start.

As to traction types: this is pakset dependant, so pakset authors who do not find the feature useful do not have to include it.

[Djohaal]

Now for a question. Was the map generator algorythm for rivers changed? Because even when I copy the parameters from SE into simutrans-standard I don't get such rich and interesting hydrographies.

[jamespetts]

Yes - Experiemental's river generation system is slightly tweaked (actually, simplified) from Standard so as to produce more rivers.

[fbfree]

I'll second the concern that the scaling of time is not obvious to the user.  It would be nice to have a simple conversion between the travel time of convoys from a terminal stop to the required number of convoys on the route for a given frequency in inverse months.  There seems to be a factor of about 1.2 to 1.4 between them.

On the topic of rivers, I have found river generation to be unphysical.  I often find that rivers will remain on high terrain, even going through mountain passes, in order to find a path to the nearest ground water.  If one constructed a Simutrans simulation of North America, a river starting in Denver would likely run south, hugging the mountains before turning west across the less intimidating passes through the north of New Mexico.  Instead of going towards the nearest ground water, it would be preferable for the river to seek out the nearest drop in elevation.  This method would however present challenges when one is surrounded by higher terrain.

[jamespetts]

Fbfree,

thank you for your feedback; I am not sure what you mean, however, by "inverse months" here - perhaps I am being a little dim, but I should be very grateful if you could clarify.

As to the rivers - have you noticed that the river generation behaviour is significantly less realistic in Experimental than Standard, or does the observation apply equally to both?

[inkelyad]

required number of convoys on the route

It is impossible without calculating route length in minutes. Which is not constant and very problematic.

[fbfree]

Thank you James,

As to the rivers - have you noticed that the river generation behaviour is significantly less realistic in Experimental than Standard, or does the observation apply equally to both?

I've played simutrans-exp more often, but checking just now in standard, the behaviour is the same.  Rivers wrap themselves around mountains instead of going down them.  I've included two screenshots showing rivers that demonstrate this on a map of New Zealand's North Island http://maps.simutrans.com/downloads/NewZealandNorth_2048x3328.zip.  For gameplay, the current behaviour places many wide rivers at high elevation, produces more wide rivers, and removes engineering challenges from the valley bottoms for railroads and roadways.

By inverse months, I mean the frequency units used in the schedule dialogue to control the spacing between convoys in cnv/month.

[jamespetts]

The point about rivers is interesting, but not specific to Experimental if the behaviour is the same in Standard. Perhaps post an extension request for Standard in the appropriate subforum?

As to the required number of convoys, Inkelyad is right, I think: there is no straightforward computation that could produce that figure.