Looking at the statistics confirms that there has been a markedly reduced amount of activity on these forums in the last two years compared to previous years. Looking at the month of September, for example, last month saw 31 new topics and 342 new posts compared to 72 new topics and 713 new posts in September 2014, 176 new topics and 1963 new posts in September 2013 and 126 new topics and 1620 new posts in September 2012.

Has anyone an idea for the reason for this apparent decline and whether the reduced forum activity represents reduced interest in Simutrans in general?

Compared to last year, there has been much less activity from most of the development team, which is also very evident in the SVN logs. There are currently no big projects underway, like double-height, lakes, removal of the Encircling Sea, JIT2, etc., which generated some discussion previous years.

The big question is whether the activity has dropped on the boards for normal players as well.

Ahh, yes, that is a good point. I wonder how one would go about measuring that?

I am interested in trying to create more interest in Simutrans in the long-term, starting with the series of videos that I am making about the new signalling features in Experimental. Once Experimental is better balanced, it will be easier to promote to a larger audience, but, without more development help, it will take a long time to get to that state, which is rather circular. This does not apply directly to Standard, of course, which is much more mature than Experimental, but I do notice a paucity of good quality Youtube videos on Simutrans.

There are no multiplayer servers and the fact the server listing server has gone down does not help.

Currently I think Simutrans lacks strong management as the people who control it have not stated where they want to go for next releases. They brought it through double height but then stopped after that was released. Since then it has been a random mash of third party developed patches (my JIT2 system), bug fixes (eg cyclic interchange recursion crash) and seemingly random patches (eg random changes to IP core and fonts or my MSVC2015 patches).

I suppose that managing a project such as Simutrans is not the easiest of things, especially for those who already have busy lives. Have you any ideas of projects that would be worthwhile implementing?

Currently I think Simutrans lacks strong management as the people who control it have not stated where they want to go for next releases. They brought it through double height but then stopped after that was released. Since then it has been a random mash of third party developed patches (my JIT2 system), bug fixes (eg cyclic interchange recursion crash) and seemingly random patches (eg random changes to IP core and fonts or my MSVC2015 patches).

A strong manager will in any case likely find himself alone. (Which actually kind of happened not too long ago, though there were other issues involved.) I haven't gotten the impression that people are sitting around waiting for someone to tell them what to do. In the sense that they are waiting for something, they are waiting for something they themselves want done differently. Double-heights wasn't much different from JIT2 in that regard, from what I could see from the outside, except that it did have a higher degree of other developers, and eventually pak set authors, joining in once the ball was rolling. That everyone has different visions for Simutrans applies to developers as well, and we seem to have reached the end of what we can all agree upon, which is probably why Simutrans forked twice in the last few years.

My long-term aim is to balance Pak128.Britain-Experimental very thoroughly, but there are a number of balance critical features that must be implemented in the (Experimental) code first which have been a long time in coming and require some considerable work and co-ordination. I am not quite sure what the position is with balancing Standard; Standard can be difficult to balance realistically, and I think that the attempt to balance Pak128.Britain (Standard) was given up a while ago, although it may yet be revived.

May be because, that not so much releases? And other exelent games was released, like Cities: Skylines for example.I'm a perfectionist. I like Simutrans 112.3 and Experimental, but 120.x is not good for me, this version need some polishing.

I suggested a release this summer, since there had been some bug fixes during the spring and no new big changes to destabilize things. But nobody had the time (or know-how) to do a release before people started doing big changes to the code again.

If there are no major projects afoot, there is much to be said for bug fixing, improving the user interface, expanding paksets, working on documentation and publicising Simutrans.

I don't know of any bugs in the core game. There are some glitches, but they are caused by fundamental issues in the design. Improving the user interface would be a major project. Plus, the motivation driving Simutrans contributors seem to be that one want something for oneself. If people can manage without changes to the user interface, pak sets and documentation, they won't do anything.

I don't think this is uncommon for non-profit amateur projects. It also applies to some more professional open source projects. Even Wikipedia suffers from problems motivating contributors these days, especially the ones for less common languages. Larger projects like Linux keep going because there is money involved. Businesses use them, so they pay people to contribute.

Interesting - I dream of a time when Experimental and Pak128.Britain-Ex is sufficiently complete in its core balance that I can work on pakset expansion, documentation, publicity and the like, with a few non-essential features and refinements here and there.

The absence of the server listing is definitely a significant problem, although that antedates the decline that I document above.

It is intended to be playable by the average person if you mean by that phrase somebody who is not a software developer or familiar with the inner workings. It is at this stage somewhat experimental in the sense that it is not fully balanced, although I have been working on that slowly, but there is much more to do. The long term plan is to rename it to something like "Simutrans-Extended" once a reasonable game play balance is achieved.

Edit: To clarify, I was referring to Simutrans-Experimental in general, not the pakset in particular, but the pakset (Pak128.Britain-Ex) is the version of Pak128.Britain that goes with Simutrans-Experimental.

I am a devoted fan & player of simutrans and have been for many years now. I visit the forums on average 2 or 3 times each week, mainly to keep abreast of develpoments and get ideas on how to help my gameplay. I have never been a vocal contributor to hardly any topics in the forum, I just plod on with the game LOL.

One thing I will say is that altho I use Linux I am really a newbie linuxer, having been a Windows user all my computer life - I went over to linux cos I loath the way Windows works and Linux gives me some sort of control over the way I use the computer.

I wish I could help you guys in someway but my skills are very limited - I am still getting to grips with the game, Simutrans, easy to play but hard to master ( you never stop learning)

Reading your topic has given me a gentle push to start asking for help in the forums, so thank you for your thread James and all who replied.

Hats off to you all for keeping the flame burning for Simutrans - kudos to all involved.

I've a fair bit going on in real life at the moment which keeps me from contributing to Simutrans much at the moment. As Ters indicates though - there's not many obvious avenues to go down in terms of improvements to Simutrans. Projects I think about involve adding features, but the question is are they really needed, and will they really add much to the game? It's easy to go down the route of Simutrans Experimental where you just make things more and more complicated in an aim to get closer to real life (and Experimental has carved out that niche), but that doesn't necessarily make gameplay better overall.

One substantial way of improving Simutrans-Standard might well be to improve the documentation: make video tutorials, up to date step by step guides, indeed, even add an in-game tutorial mode. One worthwhile new feature that wouldn't add much complexity is the separation of tunnel graphics and way graphics that was discussed previously. That is all dependant on developer time, of course, and that is often limited, but, developer time permitting, there should never be a shortage of worthwhile things to do.

If any developers have spare time and are wondering how to fill it, assistance on Simutrans-Experimental would be much appreciated, as there are plenty of projects there that could do with lots of work.

Of course, it may be that the developers, having reached that happy nirvana of having no outstanding projects, and a mature game, would rather spend their time playing their creation than working further, which would be quite understandable.

[...]As Ters indicates though - there's not many obvious avenues to go down in terms of improvements to Simutrans. Projects I think about involve adding features, but the question is are they really needed, and will they really add much to the game?[...]

I can't resist the word play: I disagree, but in my opinion, avenues are one of those obvious avenues to go down in terms of improvements to Simutrans.

That includes two-lane one-way roads where all lanes are fully used, not to mention the possibility to have 4-lane, 6 lane, etc. one way roads...

I think there have been some nice gaming options to explore, of late. The new Cities: Skylines and Train Fever come to mind.

I sort of lost interest in Simutrans-Exp due to bugs in the last release version I tried to play, and then trying to surf the current development effort was not worthwhile. Might be worth putting in a little effort on a "stable" branch of Exp, cherry pick bugfixes. I've gotten pretty comfortable with github at my day job so this is the sort of hobby I might conceivably take up.

Another concern for me is the graphics. I can deal with isometrics in a 3D gaming world, sure. But I recently got a 4K monitor .. now I have to squint at pak128 on full zoom. If I were more clever I'd look into hacking in a highdpi scaling factor (just double the pixels...) ... the other thing I noticed, on Linux 64-bit with SDL, is the UI is sluggish. I can play Train Fever or Cities Skylines or even World of Tanks in a Windows VM on this system but even a beginning game of Simutrans-Standard on default settings felt like wading through Jello while squinting. Maybe the compiled version I pulled off the forum was not compiled with optimal settings ... I might look into that.

I know a lot of the pak gfx come through Blender ... back to the 4k issue ... I wonder if it miht be worthwhile to try and simply scale a pak128 into a pak256 or even a pak512 ... chunky pixels, and turn up the size of the in-game font ... might make things more playable on a high-DPI display, then if anyone wanted to port their graphics renderings to a high-res pakset ... that would come after I see if I can tune the performance of Linux-compiled Simutrans.

The other thing, while I'm blathering, is I'd love to see some stuff ported over to Standard ... passenger route selection, and the concept of passengers walking from station to station, so that they could cross between player networks without the need to create public stops. That and convoy upgrades ... I find Exp very interesting but of all the effort there it is the more natural and intuitive behavior of passengers navigating across the terrain that I find most gratifying. (Also, the ability to set a service frequency at a stop ...)

Anyway, thanks again to all those who help build and enjoy playing the game.

The slow graphics would only be marginally helped by larger paks. The slowdown is mainly down to shear pixel pushing. Fortunately this is an area where multi threading helps immensely. Are you using builds with support for more than one core?

Experimental back ports are not a simple matter, both due to the gameplay philosophy behind the Experimental and differences in the code base.

The other thing, while I'm blathering, is I'd love to see some stuff ported over to Standard ... passenger route selection, and the concept of passengers walking from station to station, so that they could cross between player networks without the need to create public stops. That and convoy upgrades ... I find Exp very interesting but of all the effort there it is the more natural and intuitive behavior of passengers navigating across the terrain that I find most gratifying. (Also, the ability to set a service frequency at a stop ...)

I am sure that raises the resource requirements immensely and in the last release of experimental it was very buggy (although apparently that has improved in nightlies).

The walking mechanics is something that maybe should be looked into. Especially since I recently revised the logging of passengers it had me thinking of what if really short walk journeys automatically happened. Additionally the path finder might assume that passenger stations in range of each other walk. Mail and other goods could also share such a mechanics, representing a transfer service offered by your stations for the goods, possibly with some financial penalty or even bonus.

The other thing, while I'm blathering, is I'd love to see some stuff ported over to Standard ... passenger route selection, and the concept of passengers walking from station to station, so that they could cross between player networks without the need to create public stops. That and convoy upgrades ... I find Exp very interesting but of all the effort there it is the more natural and intuitive behavior of passengers navigating across the terrain that I find most gratifying. (Also, the ability to set a service frequency at a stop ...)

The whole point of why Experimental was forked out is because these things are unwanted in Standard. This is partly based in philosophy, and partly based in the vastly higher system requirements, both of which may alienate existing players.

Actually, I am working on that. SDL (as well as GDI) allows you to scale the bitmap on the fly, which would also scale all windows and everything (which may want anyway on a 4K display, as buttons will become tiny too). Windows 10 even does this automatically, and applications must switch this off manually. That would save a lot of CPU time, since the scaling of bitmaps is done by the hardware.

Another option would be independent copying of landscape and GUI. That way you could scale the landscape by OS functions (fast high quality zoom in using shaders), and the dialogues independently. That would make most sense for zooming factors above 2.

The display routines have several options to reduce CPU demand. If they cannot cope, they will switch to multithreading and then even allow for some more clipping errors before giving up. If you reached that point, then there are simply too many pixels.

Yesterday I was actually experimenting with a larger font, using the "larger" theme ... that could look very nice, but would take a bit of effort to get working: some dialogs worked better than others. If you can get scaling to work with minimal effort that's probably plenty, but I might dig at the font thing a bit more as an opportunity to learn the UI.

There is a 50% unfinished work to use freetype fonts, as a first effort into scaling. Scaling the whole display is very easy, you would just have to translate mouse buttons in simsys and scale the GDI when displaying. If global scaling is really in demand, it could be added in a weekend or so.

I think I have adjusted to the tiny tiny pixels now. Performance feels less sluggish with pak128.Britain versus pak192.Comic, but is totes playable.

If you were to hack in global scaling, I would put "arrange to get prissi beer next chance I visit Germany" on my bucket list, but honestly that's already on my bucket list ... along with a visit to Miniatur Wunderland.

As a user who plays Simutrans once in a blue moon and comes here every few months, I am attracted to games like Cities: Skylines because of the development support. Then again, I don't even have that game because I believe in Simutrans and I don't play games very often.

As someone who has friends who play SimCity and Cities: Skylines, they never heard of Simutrans upon me asking. By creating a new version of Simutrans that counters SimCity and Cities: Skylines by focusing on rail, sea, roads and transit instead of buildings, leaving them up to mods, I think Simutrans can really succeed against these games.

For example, I think Simutrans can implement things like real intersections such as the parclo or stack interchanges.

I think there have been some nice gaming options to explore, of late. The new Cities: Skylines and Train Fever come to mind.

I sort of lost interest in Simutrans-Exp due to bugs in the last release version I tried to play, and then trying to surf the current development effort was not worthwhile. Might be worth putting in a little effort on a "stable" branch of Exp, cherry pick bugfixes. I've gotten pretty comfortable with github at my day job so this is the sort of hobby I might conceivably take up.

Another concern for me is the graphics. I can deal with isometrics in a 3D gaming world, sure. But I recently got a 4K monitor .. now I have to squint at pak128 on full zoom. If I were more clever I'd look into hacking in a highdpi scaling factor (just double the pixels...) ... the other thing I noticed, on Linux 64-bit with SDL, is the UI is sluggish. I can play Train Fever or Cities Skylines or even World of Tanks in a Windows VM on this system but even a beginning game of Simutrans-Standard on default settings felt like wading through Jello while squinting. Maybe the compiled version I pulled off the forum was not compiled with optimal settings ... I might look into that.

I know a lot of the pak gfx come through Blender ... back to the 4k issue ... I wonder if it miht be worthwhile to try and simply scale a pak128 into a pak256 or even a pak512 ... chunky pixels, and turn up the size of the in-game font ... might make things more playable on a high-DPI display, then if anyone wanted to port their graphics renderings to a high-res pakset ... that would come after I see if I can tune the performance of Linux-compiled Simutrans.

The other thing, while I'm blathering, is I'd love to see some stuff ported over to Standard ... passenger route selection, and the concept of passengers walking from station to station, so that they could cross between player networks without the need to create public stops. That and convoy upgrades ... I find Exp very interesting but of all the effort there it is the more natural and intuitive behavior of passengers navigating across the terrain that I find most gratifying. (Also, the ability to set a service frequency at a stop ...)

Anyway, thanks again to all those who help build and enjoy playing the game.

I agree. There is nothing wrong with the basic mechanics of Simutrans to me, it's really the UI and the graphics that feel suck in 2000.

I think that Simutrans has an advantage over the SimCity saga and Cities:skylines: the simulation is deeper. The latter are better of course regarding graphics.

Once you dominate the games, SimCity and Cities:skylines soon become boring. Popular games are, by definition, easy games. A game that needs time to master isn't popular, but once you do master it, it is much more fun than an easy game.