Similarly to Alternative ways to fix the performance this is something that has come up multiple times in the past so I wanted to try to write all the information about this to a single place. That thread I just linked to already has some info about the downsides and upsides of moving stuff to C++, but I’ll try to cover the basics here as well. And also similarly to that other thread, this is not something I think I can work on in the near future, though this would be a much more approachable starting point to one of the approaches I covered in that other thread.
The basic facts are that C++ is about 3 times as fast as C# so if we were to convert some of the core heavy computation components into C++, we would be able to make them faster. For example the compound clouds and membrane geometry generation are heavy computation parts that are relatively well decoupled from the rest of the game and could probably be quite easily programmed in a different language than the rest of the game (see the thread I linked above for why converting all gameplay code to C++ would be a really tough project). So those parts of the game could be made probably about 2-3 times faster than currently. Or perhaps even more, the compound cloud updating needs to call a Godot method separately for each pixel in the fluid simulation, so if C++ is given direct buffer write access in Godot, it could be even faster than the base language speed would indicate. That sounds super nice, right? But there are quite many downsides which I’ll cover next.
The biggest being that we’d now have native code components that need to be compiled for each target platform we want to release Thrive on. So that would impact my release making workflow and also have some impact on our CI setup. Neither of those are very big problems but still would take some time to solve. Especially continuing mac support as compiling for mac would probably require a mac to do that on (I made a thread about starting official Mac support: Demand for official Mac (OSX) support). I do now have one personal mac which I bought for this purpose, however it is one of the new m1 macs, so having a second mac to test on that’s older would be pretty important. Also doing code signing to make macs not complain about the software would require registering an Apple developer account for the association.
That would be mostly on me, but this has a much wider impact as well. After this move everyone doing Thrive development would need a C++ compiler to compile the native code parts. However, this also has a solution, which is having precompiled binaries that can be downloaded. With just a few core parts of the game being in C++ these precompiled binaries wouldn’t need to be updated that often. Still scripts and a new feature in the ThriveDevCenter are needed to make the downloading and uploading precompiled binaries work. The devbuilds system also probably should hook into the system. These are definitely doable but once again will take additional development time, also these make running Thrive through the Godot editor slightly more complex for everyone as they’d need to run the scripts needed to download the precompiled binaries whenever they change. So in addition to programmers this would affect all team members who use Godot editor to quickly test their changes or new assets.
One last downside is that I doubt this would actually fix the game performance and care needs to be taken to make sure that the calls between C++ and C# don’t sap a lot of performance, so making small operations in C++ most likely is slower than doing them in C#, so only relatively decoupled components could be converted.
Overall this would be doable in a month or two of my development time. After this has been done once, moving additional components to C++ or if we want to use any other native code dependency libraries or something, would be much easier.