About it not being modular/decoupled, I completely agree, I did some work to make this better, but certainly need a *LOT* more work. Believe me it was even worse past years. I decoupled:
- Loading screen out of simgraph/simworld, improving its even management too (to a certain point, but even games like StarCraft II suffer from some kind of lock up of event processing when loading/saving, so it's quite ok right now IMHO).
- Event management out of simworld.cc to siminteraction.cc
- Camera management out of simworld.cc to display/viewport.cc
More code has been moved out by other developers, too, iirc.
Still, have to agree with you this needs a *ton* of extra work, and it's important imho. Anyway, This idea is not popular among some of our developers, that tend to like huge source files, and not "spread" code around. I can't agree on that but on the other hand I have to agree in that code is stable, and it's working, so why changing something that's working? My guts tell me the code is wrong, and I'd happily go and refactor many parts, but it's hard to make it, because some of the refactoring could imply a degradation of performance in some cases, and it's a quite ingent amount of work, plus in this community all huge changes require consensus in developers (in wich prissi often has the last word), and this consensus is hard to reach.
About german in code (and documentation), a lot of work has been donde to make it better, again, it was much worse in the past.
TLDR version: Good luck if you try to change some of this, but our developers are quite flexible on reasoned proposals, if you got something in mind, the work will be incorporated, at least partially.
As I see it, karte_t, simworld.cc, is basically a class to *CONTAIN* the map, and all objects included in it. Plus, it handles the logic of world time stepping (map item "movement"), taht's what iirc you are referring by interactive().
iirc, I had a plan to move all this code to another class, some like map_scheduler_t(), but never managed to finish that project. There are many other things that can be taken out of that monstruous class that's karte_t.
The game also lacks of a proper game_loop_t , of the idea of sub-systems, and code isolation. It lacks a "central" part, because simmain.cc doesn't really do it (it maybe should do it), the code jumps around.
About threads: Threads didn't even exist when this game was created, it's normal it's not designed to take advantage of them, our current thread systems was designed like 2 years ago, and it's specifically designed to handle just the display.
But as I said, it's old code, it's working and performing good and it's not bad designed, having in mind how many work has been receiving. But it's quite "exotic", one of a kind. Have in mind this game worked on MS-DOS.
As I said, i'd suggest anyone interested into changing this, to make a proposal, but have in mind game speed has to be the same, or better, never worse.
An example is that simutrans cannot be minimized (from full screen) when loading a map at certain stages.
Again, this was worse time ago, when the loading screen was on, the game did not process events, so no minimize/resize/maximize/click could not be done on it while the screen was on. Also, this events caused simutrans as be marked as unresponsive in Windows, for example. Now it's checked each update (not ideal, but good enough).