(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.
Right, so this is overdue, but. Let's talk some stuff about how it goes with godot.
so, generally, the thing I'm finding I enjoy more and more even knowing that C# support is not quite as robust as a lot of GDScript stuff I'm seeing is that by and large Godot's node structure kinda just really encourages freestyling for me in all sorts of ways. i was streaming shootlanzer development some hours ago and one of my teammates was like "hey so do you think we can get score popups when you destroy enemies", so I basically sat down and slapped four nodes together, threw an animation in, and wrote a quick script. worked like a charm (eventually).
a little near the end of april, I also managed to get saving of player preferences and the like down without having to worry about file i/o through json or something similar. very helpful in the overall and I'm really happy about how it turned out, especially because I don't have to do a lot of work to save new data into the configuration file. it sort of just does on its own.
the only thing I wish I'd realized sooner was the actual nature of how to best set up the internal working resolution in order to get window resizing to work well. I set the project's default size to 1280 x 720, but trying to get it down to, say, 640 x 360 doesn't allow certain things to scale down correctly & I'm not sure why yet. but setting up borderless full screen and exclusive fullscreen seems to have mostly worked out fine so I'm not complaining.
i am also immensely happier about how much easier it is in animations to call a function and have it do whatever on a specific frame. i implemented a bomb-dropping animation for Leona today and I didn't have to resort to "ok right I have to make an internal timer that fires at exactly this time to make this happen in order for this to not go horribly". i am frankly very tempted to see if I could port ULKSS over to godot at some point (because card summons will be way easier to implement thanks to that feature) but I feel like I'm going to need way more practice before I do that.
expect some screenshots a little later in the week!
first: sorry, i forgot to do screenshots for shootlanzer last month, lol. this is a recurring problem with a lot of my work because i am so busy doing the thing that actively remembering to stop, record, and Upload Stuff About The Thing is inordinately difficult for me to do. I owe the team some videos and stuff (not by mandate, but because some of them don't have the repository and can't see the changes themselves), so with any luck i will remember to get them done within the next two days or we will work out who gets to do it if I cannot.
highlights:
- i had to update from godot 4.1 to godot 4.2 to accommodate updates to a plugin, and...it went really smoothly actually? nothing has broken and everything is fine, and this is good. whilst there is still a phantom error with spawning powerups (in the sense that Godot insists i am doing something wrong, and I do not know why), everything else works great.
- pausing works now. this is made so much simpler by virtue of the fact that pausing a node pauses its children (unless they are configured to run during a pause, or always run independent of being paused, which is also REALLY GOOD). this means that you can, in fact, pause the root of the current scene you're playing and anything that is pauseable will pause, and all nodes that are pauseable generally understand how to act when paused--timers don't keep running when the tree is paused, animations are paused while the tree is paused, etc. and then all i have to do is check if the root of the current scene is paused to know if the game is paused or not. it's very handy.
- we have enemy movement patterns working! the drones specifically do not do anything more complicated than moving in a straight line, whilst the troopers have a degree of vertical tracking of Leona for a while as they move forward, and the scouts do the classic vertical sine wave waggle whilst firing and moving forward. I think this basic pattern of three is best suited for the game in its current state because we haven't had enemies that move vertically in shootlanzer before and I want to see how players react to that complication before we start conceiving of more complex patterns for enemies that haven't appeared yet.
if i do get screenshots/video sometime timely, expect it as either a 7.5 post or a separate one, whichever i can wrangle lol