Couldn't think of a stupid joke for the title this week.  Anyway, I started off things by reviewing my list of goals for this project and I ended up cutting a number of things from the queue. My primary goal here isn't to recreate the entirety of Super Metroid, but to use existing designs in order to get used to using Godot. to that end, I removed things from my todo list that I have already figured out how to do in the engine, which will reduce the amount of time I need to spend on this training arc before I can start building something for real.

As for the actual implementation work for the week, I didn't run into any real surprises. First up, I finally added death effects for my enemies, though I did have to use the morphball bomb explosion effect as a placeholder, at least until I can find and slice up the real enemy death explosions.

The real explosions in the game do a better job of hiding the sprite pop, but functionality wise this one is done. Next was getting enemies to drop items when they die. Again, this was pretty simple in itself; I defined all the different types of drops, made them increment the player's stats when collided with, and set up data resources so that enemies can define their own drop rates for each type of item. Thing is, Metroid actually has a bit of a system when it comes to item drops: items don't drop if the player is full on that particular resource, and the drop rates of other items that the player is missing are boosted. I did not replicate the behavior exactly as it appears in the games, but I made a close approximation. When an enemy wants to drop an item, the Drop Manager looks at the player's current status. It only takes into account drop weights of resources that the player is currently not full on, skipping over those that are already topped off, and thus making sure that only things that the player needs will spawn.

While I don't truly have logic for missiles, super missiles, and power bombs up and running yet, I did still create the full suite of ammo drops as well.  

And.... that's about it for this week. Next up, I'm planning on shifting my attention to Godot systems that I'm less familiar with, specifically camera control and scene transitions. Once I get the ability to swap rooms working, hopefully I can start to figure out how save data works in this engine.

​See you next time.

Another week down with a good amount of progress made. Following up from last week, my primary goal was to finish the player's damage interaction, which meant I had to set up a few extra systems.  First up, we need a way to actually keep track of the player's health, so that means setting up some UI. I created a UI Manager script, defined a basic "UI Screen" to hold shared functionality, and then went about making the HUD from there.  Luckily, unlike many of my past experiences with the art assets I'd been able to find myself, the sprites for the UI chunks I had needed minimal amounts of work in order to get in to "game-ready" state. So, after looking up some basic guides on how to use the UI nodes in Godot, I threw together my replica of the Super Metroid HUD.

Not bad, eh? I'm not planning on implementing grapple beam, reserve tanks, or X-ray visor for this little project of mine, so I left those bits out of my setup. Next step was actually getting those values hooked up to real player stats, which... lead me to rearrange some of my architecture first. Previously, I just had the player, level, and enemies thrown under an empty node for organizational purposes, but I ended up finally making myself a real "Game Manager" script to exercise more control over how the program runs.  Instead of just using Godot's built in "_ready" function to set up values at game start, I introduced Initialization functions to key scripts and had the Game Manager trigger those in correct load order.  In simpler terms, I needed to be able to make sure certain values were set within the player instance before I could hook up my new "Player Status" script and properly connect the HUD to that.

Speaking of Player Status, that script is effectively just a data holder used to keep track of stats. At the moment it holds the player's max and current health, as well as max and current ammo counts for missiles, super missiles, and power bombs, but it will eventually hold data on what power-ups have been collected and what items are equipped. Basically, this thing will be what I eventually turn into save data once I start working on that system.  For now though, it has been properly hooked into the HUD, which updates the relevant fields as necessary. 

Energy tanks are shown/hidden based on what the player's max health is, and the icons for your various types of ammo are set to hidden if you can't hold any of that ammo yet. And of course, this all updates in real time as the player's stats change.

As you might be able to see from the clip above, I also got my i-frame flash working as intended. That one was thankfully as simple as I thought it would be.

For next week, current goals are to get enemy drops working so that there's actually a way to make those numbers go up instead of just down, and also finally maybe make proper hit and death effects for my poor enemies. 

See you next time.

Back to work after the new year.  There's not a whole lot of visual progress this week in comparison to earlier updates, but I still got a decent amount of work done. Under the hood I made it so that weapons actually apply damage to enemies instead of just instantly killing them, made them die properly when their health hit zero, and added in functions that allow entities to modify incoming damage values.  I also setup damage property flags to represent different types of incoming damage and made it so that enemies can be set to be immune to specific damage types. That will come into play relatively soon when I start adding in bombs, missiles, and different beam types.

With that set up, I also added a little bit of polish to the damage sequence so that we now get that classic sprite flash when something gets hit by an attack:

The system I made for this should be pretty versatile, able to take in lists of colors, frame counts, and duration to create looping effects. In theory, it should work perfectly for when I get i-frame visuals up and running. Speaking of player damage, I also made it so that enemies can damage players and even apply knockback to them.

I had to at least stub in invincibility frame logic to prevent them from applying damage continuously, but I will be adding visuals to let the player know when they're active in the near future. 

That's about it for progress this time, because I actually spent a good portion of the week getting sidetracked by research.  While trying to figure out the best way to handle collision detection for enemies, I stumbled across a post talking about physics optimization and kinda fell down a rabbit hole for a bit.  Evidentially Godot has systems called "servers" that handle all of the engine's rendering, physics, and computations under the hood.  While the Node system is very user friendly, it's not the most efficient in terms of processing, and so it can start to hold you back when you have a large number of nodes active at the same time. You can apparently get around this issue by polling the servers themselves instead of just using Nodes. 

This video does a pretty great job of showing the differences in the two approaches:

It's not quite as simple as they make it sound, especially if you want bullets with non-linear/non-standard movement, but the potential performance gains are pretty obvious. Now, this isn't exactly important for my work on this project because the number of live physics objects in any given scene will always be low, but it's pretty vital information for some of my future plans. 

We'll talk more about that when I start getting closer to checking everything off my todo list for Metroid though. For now, my next goals are to finish sprucing up my enemy damage effects (VFX for hit and death), adding visuals to the player's i-frames, and then starting set up the HUD so that we can actually see how much health the player has.

See you next time.