[SXX]

> The 2D market like RimWorld could easily move to Godot.

I really all for Godot and our team have positive experience with it, but I think that it's will be hard to mantain game that is heavy on simulation with a lot of moving parts. Might be Godot 4.x will get improved profiler, but for now it's really lacking.

So unless you move everything into C++ I dont think you'll manage good performance in Dwarf-Fortress-like simulation game. Though might be I overeastimate how much simulation / physics game like RimWorld require.

[entropicdrifter]

Personally, as a professional programmer who's interested in developing a Dwarf-Fortress-like sim game as a side project, I've been keeping an eye on Bevy as an open-source game engine that would likely have good performance for a sim game with lots of moving parts. Being a Rust-based ECS game engine lends itself to a lot of potential for heavy parallelization, which you'd need to maximize that sort of number crunching performance on a modern CPU

[Jensson]

You can implement the heavy stuff in C++/Rust, compile it to a dll and import it into whatever engine you want. The hardest part about making a game like dwarf fortress is to implement a good UI, making it run fast is much easier and shouldn't be a priority when selecting engine. Game engine performance is mostly about rendering and not your custom simulation code.

[Macha]

I mean, there's rimworld for an example of "dwarf fortress with better UI but slower simulation". Commercially it's worked out for them, but I do find myself wishing for the scale of DF when playing rimworld. The new game UI does warn you away from even the larger map sizes they do have implemented though.

[Jensson]

Rimworld implemented their simulation using unity objects, if they wanted to increase scale they could rewrite it to run the simulations in custom code and thus run just as fast as dwarf fortress. Or faster if you parallelize it well. Then they could just look at the world state and render that every frame, which is super cheap since its just a bunch of 2d objects and a bit of text.

[light_hue_1]

> I think that it's will be hard to mantain game that is heavy on simulation with a lot of moving parts... C++

I don't see why that would be. Godot has bindings for all sorts of languages including C#. Why would it be any harder to write C# code with Godot bindings than C# code with Unity bindings?

[SXX]

Problem is not to write GDScript or C# code in Godot, but profiling and performance optimizations: toolset of the engine is really lacking in this area so it's really hard to find out what are major bottlenecks are and what is eating most of frame time.

Godot profiler for their "scripting" be it GDScript or C# is a dumpster fire. If you have a lot of objects and non-obvious performance drops it's really hard to find them.

In case you use C++ you will be able to use mature profilers for C++ projects like built-in one in Visual Studio or Xcode, Valgrind on Linux or some 3rd-party solution like Intel XE Studio. All of them are just 10000% better than what Godot have at this moment.

[light_hue_1]

> Godot profiler for their "scripting" be it GDScript or C# is a dumpster fire. ... In case you use C++ you will be able to use mature profilers

Why couldn't you use your regular mature C# profiler like you do anywhere else? It's officially supported. Both the mono profiler and JetBrains work.

> In case you use C++ you will be able to use mature profilers for C++ projects like built-in one in Visual Studio or Xcode, Valgrind on Linux or some 3rd-party solution like Intel XE Studio. All of them are just 10000% better than what Godot have at this moment.

You can do exactly that right now. Use the C++ profiler to find hotspots in Godot and the C# profiler to find hotspots in your code.

[SXX]

I can easily answer both of your questions. Because I obviously want to know how much time exactly game code takes together: both engine and "scripting". Using weird combinations of two different profilers is not a good day to work on code. Both Unreal and Unity have proper usable profilers and Godot doesnt.

Also unfortunately our project is usingGDScript and there is no profiler for it.