itch.io

Hah, "rant" is indeed the correct word.  I hope, at least, that when I rant, I rant constructively (or fun).  To counter my own criticism of Phaser docs a bit, when I was deep in it, I found a startup doc project that was pretty helpful: https://rexrainbow.github.io/phaser3-rex-notes/docs/site/.  It did a much better job of sorting out all the config-object/setter-methods/helper-methods/properties confusion and showing only what you need to know to get something done.  On the other hand, it was also (understandably) focused on so many next-version features it was often misleading.  It could use some version tagging and/or filtering as it evolves.  Thus, I spent a lot of time flipping between it, the official docs, and the examples site.

The one thing I liked about Phaser was its arcade "physics" and how it helped get arcadie movement and collisions up and running quickly(ish).  On the other hand, it just might have been the inconsistent ordering of arguments in the physics function calls that broke the camel's back here (but was probably the inconsistent use of `update()` across objects).

So, yes, "despite the trouble, Godot is the new goto."  My note of caution here is keep in mind that open source may never catch up to some of the commercial products.  Some things in Godot will likely never be as easy to rig up as in Unity and the others (and we both know Unity ain't exactly wonderful to use either).  Particularly in the 3D realm, I hear.  Although, 3.4 made significant improvements there, I also hear.  Simply put, you have to be willing to do more lifting in Godot.  You have to want it more.  A weird statement considering many find it easier than Unity to get started in.  Godot gets naughty quickly when you start reaching for the stars.

As to engineering, I found it more similar to Unity than dissimilar.  Yes, the lingo is weird/unhelpful and throws you off but, really, a "game object" in Unity is loosely a "node" in Godot (game objects and components cross over with scenes and nodes), a "prefab" in Unity is a "scene" in Godot, and a "scene" in Unity is the abstract "owner" scene in Godot (I guess).  Godot appears to be heavily hierarchy oriented, but I found it to be no more or less so than Unity when it comes down to it.  In short, I found the component system to be similar to Unity and found myself making many of the same kinds of decisions as to whether to build something up in the GUI editor or in code.  I lean heavily towards the code side but still split it here and there.  Some tools are very odd and need to be looked up to get.  I found the animation tool onerous for busy sprite sheets and redid those in code instead (with no help from the docs when it comes to exemplifying code workarounds).  Stuff like that pops up here and there.  Also, there is something very wrong with how scenes/nodes and node classes are wired to each other.  I'm not enough of a language engineer to describe what it is, it just doesn't quite grok with me.  It feels wrong, for example, that instancing a scene does not run the _init() constructor in attached classes -- that only a new copy of a class made from code will init it.  I get the data differences, but the diff feels not tangible enough and, thus, unnecessarily confusing.

And, just to throw another wrench into the conversation, Unity would still be the right choice for my other game, GRITS Racing.  The 2D physics in Godot is too simple compared to Box2D, and Godot's package library (while pretty okay) can't yet compete with the pro quality of some Unity packages.  There are some Box2D plugins to Godot but, like I said before, you've got to want them more to use them (I say to someone who writes his own physics regardless).  Some of the other packages I use in GRITS Racing have no replacement in Godot.  But... I'm ready to leave much of that behind in many of my planned projects.