Godot 4.2 / C#. Godot is an amazing engine and I highly recommend it for indie devs. The iteration cycle is a few seconds. IMHO, using Unity will absolutely slow you down, as a designer/programmer. I can't comment on the reality of a 3d game with a complicated art pipeline, however. But for a game like Ballionaire, Unity or Unreal would have been a mistake.

Ballionaire was fun by day 3, the first time a ball dropped and hit a trigger that caused an effect. It was luck a bolt of lightning to me. I am a VERY pessimistic person. So the fact that it felt compelling that early, and like, anyone who saw it could understand it and felt the fun, was a huge sign to me. Unfortunately, not every game has a premise that allows for that. I don't think you could hope for the same kind of feeling while making a 4X for example.

But if you're making a game that ultimately should feel fun from moment to moment, like these kind of quick-play games are, well, I think you can get there quickly and with little work, if the idea is solid. And if you can't get it to feel fun, I would be wondering if the idea is solid, versus it needing more time/polish etc.

>I can't comment on the reality of a 3d game with a complicated art pipeline, however. But for a game like Ballionaire, Unity or Unreal would have been a mistake.

Going from Zero to Working 3d Game is very quick in Unity as long as you do everything the Unity way.

Going from Zero to Working 3d Game if you need to create functionality from scratch in Unity is a heartbreaker.

I am actually planning to take one of my old projects and rebuild it from scratch in Godot, for exactly this reason.

A fellow Godot enthusiast here. Love to see Godot being used in commercially successful indie game like this. In 2021-22 time, I tried (unsuccessfully!) building educational video games for maths using Godot and I have fond memories of being in the flow state while working with Godot. IMO Godot fits well with programmer's brain much better than Unity etc.

> I realise you can make games in any language/engine

It's actually a bit more constrained than people realize ... Well, for desktop, you can literally use anything. But for mobile it's a bit harder because of specific platform quirks, i.e. on iOS you can't make a language that relies on a JIT compiler, so for a Java/libGDX game the best option is https://github.com/MobiVM/robovm which compiles the JVM bytecode to LLVM IR and then to native machine code.

And then for consoles (switch/xbox/ps5) it's way worse because you're relying on commercial stuff, and the only support you get is from the engine makers themselves (Nintendo/Microsoft/Sony) so there's a lot less open source options. Basically you're stuck with C++ at that point (which Unity actually compiles your C# to under the hood for non-desktop platforms).

Not what you asked, but I found out this stuff a while back and find it interesting, hopefully it's interesting to you too :)

Technically you can ship an FNA-based game with a commercial fork of .NET's NativeAOT that works on Nintendo Switch: https://viridiansoftware.com/blog/csharp-on-game-consoles Of course Xbox can just ship C#-written game normally AFAIK. So it's not like you're stuck with just C++ but yes, mobile platforms usually are highly constraining.