(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.
ok so it's been a minute since i got to sit down and write one of these and a lot of things have been happening since then. Shootlanzer's prototype development has been Going Great in general and I feel more and more vindicated choosing Godot for it every single day. There are a number of things that are just so much easier to do.
The major highlights:
- i've adjusted to a lot of the complaints I had about the ui stuff now that I largely understand what I'm doing and how it works (thank you @Pahsunaal). The only one that still sits is that there doesn't seem to be a nice, neat way to set up something like a tiled or repeating texture for a TextureProgressRect, which has unfortunately slowed down some of the progress I wanted to make with the hud once my fellow teammates got me some nice sprites for them.
- I realized, after a moment, that the main reason I couldn't use standard C# dictionaries the way I was used to was because unlike Unity you do have to actively initialize it with something like [new Dictionary<Key,Value>] to make it work. But once I got past that (& started doing the same with lists) things jumped up immensely. I'm not ready to look at object pooling and the like yet (which is mostly what I use lists for anyway), but it sort of reinforced that there were certain habits I just Fell Into because Unity didn't challenge me on them.
- Thanks to a friendly community developer we've got an easybake solution for displaying control glyphs on screen and I'm very happy about that. Unilke with Unity, where it took...significantly more effort to make that work out...this was pretty much a drop in and go solution and my life is much easier for it now. Truly grateful.
- Being able to keyframe pretty much any property that can be animated is a blessing. Truly. I am so happy that this is a thing. Literally able to swap in different spritesheets and just rekeying the rows/cols/texture being used on frame 0 is amazing.
- On the subject of animating itself, I needed a quick refresher on how to get animation timing down but once I did--
- Godot has nodes that automatically handle parallax elements and I could not be happier, good gracious. 4.3 is getting a changeover but even with the current system as it is implemented in 4.1 I cannot describe to you all how happy I am that it just takes a teensy script and then a few nodes and it just, works.
If you want to see all of this in action & also just like game dev stuff, come to my stream on Wednesday, April 3 2024 at 6 PM Eastern time. We'll be celebrating my 4th stream anniversary, doing more Shootlanzer dev, and kicking off a month-long mutual aid drive to help give me some cushion for rent this month whilst I keep hunting for job stuff. It'll be a cool time, you should come along and see.
Once we have some proper things that I can share expect more images, etc, of Shootlanzer to show up around this side.