How's the performance of the resulting games? With unity I've found that it's a mixed bag, but it's hard to know if that's the fault of developers or the engine.
Performance is fine in most cases. While GDSCript is quite slow it's rare to be the bottleneck. You can always port perfrormance critical code to C++ (or to basically any language in 3.0). You can try to optimize game without other languages as well. I'v got two examples:
- My bro had written RTS prototype using built-in tilemap. When zoomed out, game was working pretty slow (12-20 fps) because drawing a lot of tiles at once was bottleneck. He was able to optimize his prototype using GDScript to work with stable 60 fps (he cached rendered tilemap as texture).
- I wrote simple "terminal emulator" control for Godot. It was quite slow - rendering 125x32 characters terminal was 120 ms per change. With few simple tricks I reduced it to
40 ms for full redraw and 1 ms for small change like drawing few characters.
The problem with generic engines, is that the type of game has a diffrent performance requirement. RTS can live with physic-sim updates every 0,25 seconds, which is not usefull for a jump & run or fps game. Thus the highest requirement defines the engine, which is a complete waste for some games and limits performance.
I dont know if you can configure the framerates and engine internals here.
Next problem is that you need to write a lot of partially performance intensive game logic code (pathfinding etc.).. which again makes sense to write in the engine native language.
There is a reason why game specific engine exist- and if i would dev a new game today, i would choose- the one os-game that is allready as close as possible to the idea port that to a dedicated engine.
Its way too much work to fork a generic engine to a high-performance specialisation.
I think it really depends these days. You can make a lot of games in a general case engine up to and including those that you might think need a specific set of tradeoffs they might not provide adequately. At the same time it can be easier to not have all the unwanted cruft. It's about where you want to put the time and effort and I'm not sure that's very easily generalizable right now.
I do think Unity is beginning to jump the shark a bit with what seems like a stronger focus on ancillary services rather than their core offering.
- My bro had written RTS prototype using built-in tilemap. When zoomed out, game was working pretty slow (12-20 fps) because drawing a lot of tiles at once was bottleneck. He was able to optimize his prototype using GDScript to work with stable 60 fps (he cached rendered tilemap as texture). - I wrote simple "terminal emulator" control for Godot. It was quite slow - rendering 125x32 characters terminal was 120 ms per change. With few simple tricks I reduced it to 40 ms for full redraw and 1 ms for small change like drawing few characters.