Thanks! Can you give a bit of detail about the bugs you ran into?

If you save a reference to a game object in the scripting language, then if the object is removed from the scene by another system, the object pooling system will re-use the old object resulting in your script holding a reference to the wrong object! Will not be fixed to version 4.

Example, I was building a tower defense game and each tower would hold a reference to the enemy they were shooting at. When the enemy took damaged and died it was removed from the scene. The towers reference to the enemy would sometimes point to some new random object in the scene. There are workarounds, but wtf.

There is also some cyclic reference bug in the scripting language that is impossible to predict or work around.

And then there are little things, like there is no selection outline around objects in the scene, makes it almost impassible to build a complex scene. Not a bug, but a weird choice.

This is a pretty maddening bug that I ran into: https://github.com/godotengine/godot/issues/30215

To summarize, you basically can't use the built-in viewport scaling at all because it breaks mouse input.

Interesting, my experience is the reverse.

I shipped a 3D game with Godot on Steam this year and it's been pretty smooth sailing.

I wasn't impressed with defold, both editor and ecosystem.

I'm with you on this. I tried Defold for prototyping a game concept and was less than impressed. It got in the way in a framework sense, and didnt seem to provide much bang for buck (ie it consume more hours of my time learning its perculiar ways of doing things than it probably have taken to roll my own). Of course peoples mileage may vary. I was expecting things like auto atlassing, batch processing on import, proper layer z-order (versus using a 3d style z value). I recall the UI did weird stuff like sorting alphabetically, instead of by creation order or z-order. The message passing thing was annoying. I guess it was a bad choice for me. I'm probably more productive with a library and tools approach, rather than "opinionated" engine. It felt like someone was caught up in an architecture more suited to creating very large games and applied it here. It felt like it was created by too many programmers working to a feature list, rather than creating a useful cohesive tool.

Defold is definitely not for everyone and not for all kinds of games. Defold is better at 2D than 3D for instance. But it is a 3D engine so it will sort everything on z-value.

> It felt like someone was caught up in an architecture more suited to creating very large games and applied it here.

Defold is supposed to be the exact opposite. The two initial creators of Defold worked at a big AAA developer and with Defold they wanted something different from their day-to-day experience working on huge console games. They wanted a small and performant engine with quick turnaround time on changes.

This is why it is somewhat opinionated regarding certain things. To avoid some of the costly things that usually comes with huge productions and big complex engines.

It is also why you can usually build and bundle your game in seconds to any platform without any setup.

It is the reason why you can hot reload your changes into a running game to further reduce iteration time.

The Defold license: https://defold.com/license/

The only thing you can't do is sell Defold itself (ie the engine and editor). You can commercialise your games in any way you want and you can modify the engine and editor without having to share your modifications.