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.