(gentle heads-up: i am not asking for resources advice here, just making some observations.)
so I've been working with godot lately since i finally managed to shake the malaise of "wow unity absolutely turbofucked my options for working with THAT engine, huh" and since then things have been...going ok?
i'm consciously aware that I'm probably botching a bit of "good Godot practice" but at this point i'm reminded of how i approached mugen back in the day: it doesn't matter if it's not best practices as long as you fuckin' finish something, so that's what i'm trying to do. it definitely helps that i have the option to use C# instead of trying to use GDScript, so I can focus more on using the syntax that I know and just try to get my head around The Process instead of having to stop to translate things into GDScript and back again.
the code will probably be a mess because i understand signaling but probably have entirely too many botched setups. trying to get health increases/decreases to work and that is not going great per se, but either which way we're getting there.
so it turns out that the healthbar stuff not working correctly is largely a tragic misunderstanding of what a TextureProgressBar means when it says "over" versus what I understood "over" to be.
me, coming from mugen and ikemen: "oh, 'over' is the actual progress bar that drains down when the value is changed, got it."
godot, being sensible: "no, goofus, 'over' goes over the progress bar. 'progress' is the actual progress bar."
aside from that, mostly everything else I've been doing since then works, minus that I can't seem to get explosion effects to play their nice boomy boom sounds.
ok so I streamed some more today and now that I've been messing around with this engine for a while my brain is starting to put together the pieces, little by little. i hit that point where while I was on stream break partway through stream my brain started translating things I've done in unity into similar godot structures, which strikes me as a good sign because it means I'm actually starting to get the underlying structure of the engine in a way that makes sense.
Best example of this: the game I'm working on for stream is a shmup that has a mechanic where your character does a spin to go invulnerable for one second. spin is then on cooldown for 3 seconds. I made the timer for spinning by just adding a timer node to the player and tweaking a few things (once I remembered that timer nodes count down, not up), then realized, oh, this makes the player invulnerable for the whole duration of the spin, that's not the right behavior.
I then fixed this by adding another timer node as a child of the first timer node, slapped some signals down, and called it a day--but I was able to follow my own line of logic straight through and even clean up some redundant code here and there, where the last time i tried this with Godot that was not the case lmao.
I attribute this to C# letting me focus on the underlying problems because I'm not trying to learn both the programming language and the engine at the same time. It is entirely possible that there are certain things I can now translate from Unity into Godot from my existing prototype projects now that my brain is starting to plug things in.
So hey
The project that I've been working on in Godot, Shootlanzer, is officially going into production w/the co-op I helped co-found. This is exciting (because it helps push the project forward a bit more) and scary (because I'm lead programmer), but I'm also looking forward to the challenge.
A thing I am beginning to realize rather quickly is that maybe the one thing I happen to like better in Unity than Godot so far is the way that laying out UI stuff works. Godot's UI controls like buttons and so on tend to completely lose the ability to control their own size when placed inside of things like horizontal or vertical layout containers--thankfully setting up navigation of the buttons themselves with both keyboard and mouse is a lot less of a pain in the ass, but at the same time I find myself wishing that you could throw things inside of a container without having them forcibly expand to that container's size.
One of the things I'm definitely looking forward to is putting together a state machine--for controlling menuing and the like it'll be critical to have that set up, and I have a state and state machine pattern I can import from my Unity projects without too much trouble, just needs to be adapted to Godot later on. I'm probably going to knock out the other required things for the game's current sprint during tomorrow's stream, so if you want to see that, come by the twitch channel at 6 PM eastern time--link's in my profile.