Is there a current development direction or list of priorities for Simutrans?

[victor_18993]

I have been contributing several small fixes and improvements recently, and I wanted to ask whether there is any current roadmap, list of priorities, or general development direction for Simutrans Standard.

I am not asking for fixed deadlines or a formal release plan. I understand that this is a volunteer project and that development often depends on the interests and availability of each contributor.

My main reason for asking is coordination. Before spending time researching and implementing a change, it would be useful to know whether:

• there are particular areas where contributions are currently most needed;
• larger changes are already planned that could overlap with a proposal;
• some parts of the game are intentionally being kept stable;

• there are features or technical issues that maintainers would especially like contributors to work on.

At the moment, priorities and ideas seem to be spread across bug reports, feature discussions and individual forum threads. Even a lightweight list of preferred development areas could help contributors choose work that is more likely to fit the direction of the project.

If no such roadmap exists, would it be useful to create a simple community-maintained thread listing current priorities, accepted ideas and areas where help is welcome?

My intention is simply to align my contributions better with the needs of the project and avoid duplicating work or developing changes that do not fit the intended direction.

[Yona-TYT]

Greetings, I'm very happy to see you contributing so actively, thank you very much for that.

I think some of you here have your own lists of projects in the areas you like best or are most familiar with.

On the other hand, there are several interesting requests to improve Simutrans, however, due to the difficulty of implementation, they have remained just proposals.

[Andarix]

Well, there is a todo.txt in the source code.

However, I cannot say anything about how up-to-date they are.

What would be important to me right now.

What I don't like so much about the current versions is that industries are always built on the lower level. Such sunken industries look terrible.


And the current city growth (deep trenches or high embankments) doesn't look very good.

[victor_18993]

Thank you both for the replies.
The

Code Select Expand

todo.txt file is useful as a starting point, although, as Andarix says, it is difficult to know which entries are still current, which are already partially solved, and which ones the maintainers would still like someone to work on.
The examples about factories being placed too low and cities creating deep trenches are exactly the kind of issues I had in mind. There are many potentially valuable improvements, but before investigating or implementing them, it would help to know whether they fit the current direction of the project and what scope would be acceptable.
I am not suggesting that Simutrans needs a strict roadmap with deadlines or assigned developers. That probably would not suit a volunteer project. Even a small, periodically updated list could be useful, for example:

• areas where contributions are currently welcome;
• proposals that have general approval but still need implementation;
• tasks that require further discussion before coding;
• old items that are no longer considered relevant.

This could reduce duplicated work and make it easier for contributors to choose something that has a realistic chance of being accepted.
For specific ideas such as the factory placement and city terrain issues, I think it would be better to discuss each one in its own thread, so that its behaviour, desired result and technical scope can be examined properly.
It would be especially helpful to hear how the maintainers currently decide priorities and whether they think a lightweight community-maintained list would be useful.

[Andarix]

Some very old "bugs" are listed here.

[prissi]

The todo.txt is relatively recent.

Some larger projects which large contributions to game play and design would be (from me):

Elevated way with pillars for every ground below and a match elevated way builder (maybe even with a tool bar for one N S E W up down) to build higher elevated ways over any ground.
In order to allow for pixel graphics, maybe consider each corner separately.

Directional wayobj making the way a single directional object and ha different graphics left to right or right to left.

Routing based on distance. If route 1 is heavily overcrowded, thez alternative. Needs some deep thoughts how to implement.

Loaded station graphics with animations (for pax) or maybe reuse pedestrians for this.

[makie]

Extend the way-building tool that it  can also build bridges across rivers and small sea.
Also Tunnels? Maybe double-track lines at once?

For Android devices with their small screens and big fingers, more automation in the construction tools is necessary.

[ceeac]

In general, I think that UX improvements to building actions is generally appreciated for a game that is mostly about building stuff . Like
 - terraforming: Flatten area, ignore adjacent occupied tiles (that contain buildings) for raise/lower land.
   There was a post by Roborin (I think) that suggested improving the terraforming to be more like RollerCoaster Tycoon/Locomotion style terraforming, but I cannot find the thread right now.
 - Improvements to tunnel building: No need for tunnel entrances, connect tunnels across multiple height levels etc.
 - General small GUI improvements like hiding small station labels when zoomed out

Personally I am still working on the new graphics renderer (nothing to show yet), and occasional small bugfixes and (code) improvements so it's unlikely any other feature work will conflict with my changes.

[prissi]

The waybuilding tool can build tunnel an bridges and limited terraforming (as can be seen by the building AI). However, specifying which tunnel and bridge to use would require quite some gui extension.

Flatten area is somewhat possible (dragging the lower/raising tool) but is not very realistic. At least it was the consortia a long while ago, building should reflect the struggle to build lines at low costs and not roller coasters ...

Flatten land is rather trivial though, if there is really demand and if it is made forbiddingly expensive compared to raise selected tiles.

[victor_18993]

Thanks for the replies. This is exactly the kind of discussion I hoped this thread could create.
I think many contributors have their own lists, ideas, or problems they would like to address, but that information is usually spread across different threads, messages, and files such as

Code Select Expand

todo.txt. Having one place where we can see which areas are considered important, what somebody is already investigating, and what is still open could help us avoid duplicated work and choose more effectively where to contribute.
In fact, some of the ideas mentioned here are already starting to be worked on. For example, I am developing a separate prototype for building two parallel ways in a single operation. I am also reviewing Makie's suggestion about automatic bridge and tunnel construction, because while looking through the code I found that part of the implementation already existed, but was not connected to the interface.
The intention is not to mix all those projects into this thread. I think the most useful approach is to use this as a meeting point for identifying needs and priorities, and then move each specific investigation or patch into its own thread, where it can be discussed and reviewed properly.
Andarix, the two terrain issues you mentioned are good examples of concrete problems that are clearly visible to players:

• industries ending up sunken relative to the surrounding terrain;
• city growth creating unnatural trenches or excessively high embankments.

I have already started looking into the first one. There is a difference in how the base height is calculated for single-tile and multi-tile buildings, and that may be related to the factory issue. I do not consider that a confirmed diagnosis yet, so the first step should be to reproduce it under controlled conditions and investigate it in a separate thread.
I will also review

Code Select Expand

todo.txt against the current code and project history. Some entries may still be relevant, some may already have been implemented, and others may require design decisions before it makes sense to start coding them.
In any case, I really appreciate having a thread like this. For those of us who want to contribute, it is very useful to know which areas are already being worked on, which problems are still open, and which improvements maintainers and experienced players consider genuinely valuable.
Please keep sharing ideas, even if they are large projects or their scope is not yet fully defined. Even when something cannot be addressed immediately, knowing that it remains a real need is already valuable information.

[prissi]

Maybe work the cloning pipette on convois too? It is often requested to add another identical convoi to a line. Must handle depot search too ...

[makie]

The waybuilding tool can build tunnel an bridges and limited terraforming (as can be seen by the building AI). However, specifying which tunnel and bridge to use would require quite some gui extension.

I don't really think so.
Just select a available bridge or tunnel with a suitable speed.
A player doesn't do anything else, either.

[isidoro]

One interesting (but titanic work) would be to isolate simulation from view.  Afterwards, render Simutrans in real 3D with free rotation of the camera, zooming, etc.  A lot of the presentation is done now with tricks, for instance, rotation, slopes...  That would simplify a lot of code.

Once you have a 3D rendering (which if view and simulation are isolated properly, it could live together with present rendering), one could focus in designing 3d models for a 3dpak.  A compatibility mode would import a 2d pak and make "blank" buildings or vehicles carry pictures of the objects of the 2dPaks.

Incidentally, some of the paks have real 3d models now, from which the 2d views are generated.

[makie]

Incidentally, some of the paks have real 3d models now, from which the 2d views are generated.

That is correct.

Pumuckl999 created almost all the objects for pak128.german as 3D models. Unfortunately, he is no longer active with us, and we only have the 2D graphics, not the 3D models.

Therefore, at least pak128.german cannot go the way to 3D.

[victor_18993]

It would certainly be interesting to see Simutrans in true 3D at some point.

At the moment, however, there is already ongoing work on the graphics side, especially ceeac's renderer work. Some recent changes that have entered trunk also improve or indirectly support the current rendering architecture, even when they were not specifically developed as rendering features.

I am not sure where an MVP for "Simutrans 3D" would begin, because even a small proof of concept would require quite a lot of prior investigation: how far simulation and presentation are currently separated, what can be reused from the renderer work already in progress, how existing paksets would be represented, and whether a 3D view could realistically coexist with the current 2D one.

On the other hand, I really like how this thread is developing as a brainstorming space. A lot of ideas are being brought together and channelled in a way that could make them easier to evaluate and eventually bring into Simutrans.
It feels like we are entering another phase: some ideas are still only discussion, while others are already beginning to turn into investigations, MVPs, new features under development, or changes moving towards integration.
Of course, any of these ideas would still need to fit the technical and product direction defined by Prissi, together with the rest of the development team and contributors. That alignment is what ultimately determines which proposals can move from brainstorming into actual implementation.

So I see 3D as an interesting long-term direction, but one that would first need architectural research, coordination with the rendering work already underway, and agreement from the project's technical direction before any realistic implementation scope could be defined.

[Isaac Eiland-Hall]

I only wish to say that one of the criticisms of Simutrans by many potential players is about the graphics. If we did go 3D, I suspect we might be able to attract more players and people willing to work on the game and make paks for it. Also it would allow for smoother animations - really going around curves instead of straight-diagonal-straight images.

[prissi]

Machinsky is more or less Simutrans 3D, i.e. a grid based landscape with 3D capabilities. It seems possible and give impressive videos.

[victor_18993]

Isaac, I agree with your point. Since I started learning more about Simutrans, I have repeatedly seen comments suggesting that a move to 3D, or at least a significant graphical improvement, has been discussed for many years.

I personally support exploring that direction. Simutrans has a very deep simulation, but its graphical presentation is probably one of the main barriers for new players before they have the chance to discover that depth.

What is not clear to me is whether this possibility has ever been investigated in enough technical detail. I do not know whether Simutrans could realistically be adapted to a full 3D renderer, or whether it would be possible for a 3D view to coexist with the current isometric view while using the same simulation underneath.

Prissi, was there ever an earlier attempt or technical investigation into this? Was it studied whether the current Simutrans architecture could support a real 3D renderer?

My main technical doubt is the transition from the current rendering system. As far as I understand it, the current graphics are composed and rendered mainly on the CPU, without a GPU-based 3D graphics pipeline. 

Moving to 3D would therefore not seem to be only a matter of replacing sprites with models. It could require introducing GPU rendering, a new representation of the world, cameras, materials, lighting and a clearer separation between simulation and presentation.

Perhaps the first useful step would not be to promise a 3D version, but simply to document the current rendering architecture and determine whether a small experimental renderer could read the existing simulation state without modifying the game logic.

That would at least tell us whether this is a realistic long-term direction, whether both views could coexist, and which parts of the current architecture would need to change first.

[isidoro]

If I recall it correctly, there were attempts to do the 2D presentation with (old, preshader) OpenGL by Hajo, the original developer of the game.  But, of course, that's completely different from going real 3D.

I've tried to search in the forum to no avail...

[Isaac Eiland-Hall]

This thread perchance? https://forum.simutrans.com/index.php?topic=22227.0

[victor_18993]

Yes, I also found the thread where Simutrans is being prepared for OpenGL:
https://forum.simutrans.com/index.php/topic,23493.0.html

[Yona-TYT]

OpenGL rendering with semi-static geometry

https://forum.simutrans.com/index.php/topic,11796.0.html

Hardware accelerated display, OpenGL back-end & Simutrans 3D
https://forum.simutrans.com/index.php/topic,4151.0.html

[Andarix]

If I recall it correctly, there were attempts to do the 2D presentation with (old, preshader) OpenGL by Hajo, the original developer of the game.  But, of course, that's completely different from going real 3D.

I've tried to search in the forum to no avail...

https://forum.simutrans.com/index.php/topic,22227.0.html

The selection of packsets there is also very stylish.

[prissi]

The was a branch for 3D rendering of new graphics and canvas the old one. It is still in the svn, but lack 7 years of updates.

[victor_18993]

For my part, I have opened a research line in the laboratory around SDL3.

At this stage, I am not proposing a full migration or an immediate replacement of the current backend. I first want to determine whether SDL3 can be introduced safely and maintainably through small cuts that are easy to review and rebase onto trunk, without compromising compatibility or Simutrans' normal development.

The tests are still at an exploratory stage. I am currently analysing the dependencies of the existing backend, the required API changes, the build system, and which parts could be separated without changing existing behaviour. There is no integration proposal yet, and trunk is not being modified: the current goal is to establish technical feasibility and identify the real risks first.

My initial objective would be to explore an accelerated 2D backend while keeping the current visual representation and paksets. I think this would be a much more realistic and useful first step than trying to move directly to a 3D environment.
I also want to make clear that this research is not intended to replace the great work ceeac is doing on the graphics-system refactoring and OpenGL preparation. They are different but potentially complementary lines of work: his refactoring can improve the separation and modernisation of the rendering system, while the SDL3 research focuses on the platform layer, window creation, events, input, and possible acceleration paths.

If both lines prove viable, they could eventually converge into a cleaner architecture with accelerated 2D rendering that is better decoupled from the rest of the engine. In the longer term, that foundation could also make a hypothetical 3D renderer easier to explore without necessarily abandoning compatibility with the current paksets.
Once the MVP is complete and has passed the planned tests, I will present it together with the technical documentation and the results obtained. From there, we can assess together whether it is worth continuing and which parts could be integrated progressively through small cuts.