Sunday Show Out - 01/04/2026

School starts back tomorrow: before we get into our normal classes (for me, that’s general chemistry), we have a week-long special projects course where we can teach any subject we wish, as long as it has an academic component. I chose the early history of webcomics and how that history mirrored the culture and technological advancements of the early 2000’s. My class filled up pretty quickly: I’m fortunate that I’ve been able to effortlessly develop a good relationship with our students in my first semester.

You know which webcomic most high school kids know? Homestuck. I haven’t read much of it (and I know there’s a lot to read), but that’s one of the best things about comics: each generation can find and make the ones that speak to them.

As I’d said on Monday, I expect game development to slow down starting next week but not stop. I outlined my plan for building momentum going into the start of the semester and stated my criteria for success. Was I successful? Do I have a good head of steam going into 2026?

In short: yes.

But a devlog wouldn’t be that great a devlog if 95% of it was the developer talking about everything else other than their game, so let’s get into what I did this week.

What did I do?

I figured that adding knockback and cooldown to the combat system would be straightforward. And it would have been, had I been more experienced with finite state machines. But it wasn’t, because I wasn’t. The model was pretty straightforward:

• Knockback is initiated when Zel/the enemy takes damage
• Velocity is forced in the direction away from the attacker
• Movement is disabled during knockback
• Knockback ends after a timer
• Zel returns to the idle state/ the enemy returns to patrol/chase

I created variables for the knockback velocity, how quickly that velocity decayed, and the time of the knockback and exported those variables so I could control them in Godot’s Inspector window (this would allow me to more easily customize enemies). I ran the game and it looked like the knockback was working, but for far too short a time.

It turns out the attack state was interrupting knockback: as soon as knockback initiated, the enemy realized it was in attack range and attacked. I added logic to the enemy’s set_state function to prevent the interruption. Great, it worked!

Except now the enemy wouldn’t return to the patrol state after knockback ended. The knockback state was persisting even after knockback was applied, so I created a knockback_locked flag that set to true as knockback was applied. Now the enemy would return to patrol, but it wasn’t chasing Zel.

Well, it was, it just ended too quickly. The enemy’s ChaseRadius wasn’t large enough to keep Zel in its sights, and Zel faster and outrunning the enemy. I added a chase memory of ten seconds: the enemy now chased Zel appropriately.

With knockback solved, I moved to cooldown, at which point I realized I’d already added that to both Zel and the enemies. I’d even added it in my personal, bulleted, running devlog. Good job looking out, Past Me.

After all that, I had this:

Attacking, knockback, cooldown, and grappling objects all worked. The simple sprites don’t do it justice, but I had a working combat system that I could fine-tune to where it was, you know, actually fun.

With the week’s coding task completed, I could move onto music. I had the barest dulcimer melody for "The Place Just Beneath", but it barebones and it was jarring when looped. I laid down a chord progression under the melody, and then a mandolin bassline (look, I know the mandolin isn’t the standard bluegrass bass instrument but trust me). After tweaking when they came in/went out, I’d created a nice, short underworld theme:

I’d accomplished two of the three things I set out to do: Zel’s animated sprite was all that was left. Yeah. Just that. One small task. Sure.

I absolutely did not finish this.

I spent the better part of a morning making this:

It’s not bad! The colors are way too primary and it could use editing, but it’s clearly a girl who’s ready to throw down. The only problem is that she doesn’t fit the game. Just Beneath the Holler is a top-down, 2D Zelda-like and this sprite is better-suited for a belt scroller. I tried going for something closer to Square SNES RPGs and didn’t hit the mark, even when hitting the mark wouldn’t lead to something that fit JBtH.

Factoring in New Year’s festivities and an impromptu Stranger Things marathon, I accomplished a lot and succeeded in building the momentum I needed going into 2026. I’ve been a productive developer these past three weeks and I have a foundation that I can build off for the rest of the year.

What did I learn?

I focus on what I wasn’t able to do, instead of what I did, and I’m working on myself to fix that. It’s not fair to tell myself that I failed at making Zel’s animated sprite: I just learned how not to create the sprites I want. The time I spent in Aseprite wasn’t wasted, it just eliminated a possibility. I got closer to what I want and that’s a path to success.

It’s part of what I call the hidden time of creating. That isn’t a unique position: every endeavor has work that isn’t showy and is easily dismissed (if it’s considered at all). This week, that hidden time was concealed in fixing bugs, setting up FL Studio, and practicing Aseprite. I’m learning three new skills at the moment: coding, music production, and sprite art. Each skill has its own program, and each program its own workflow and idiosyncrasies. It takes time to learn, and more time to learn properly. That time will pay off in more efficient work weeks/months/years from now, even if it’s sometimes difficult to convince myself of that. I have a short video, a music track, and one sprite to show for this week, but hours upon hours of work went into those three pieces. I’m proud of them and know the work I did, the work you didn’t see, wasn’t wasted.

I also learned that the old joke, “It’s not a bug, it’s a feature” isn’t a joke. A quirk in the combat system emerged: Zel’s attacks are a lot safter when she hooks the enemy first. I always meant for that to be the case, as the enemy is temporarily stunned after Zel reels it in. I didn’t mean for an unhooked attack to be so risky, though. Zel has a very small window to attack an enemy before it lands and attack and knocks her back. Now, I could add an attack delay to give Zel a bigger window of opportunity, but do I want to do that? I have two basic options here:

• Keep the combat system the way it is and persuade most players to use the hook, leaving the unhooked attacks to more skillful players
• Add the delay for unhooked attacks and vary that delay for enemy types.

I’m not going to decide that now. I have a goal of releasing a prototype by spring: playtesting would reveal which, if either, option is more fun. It makes sense to let players decide.

What’s next?

I have to scale back what I consider a successful week to be now that classes have resumed. Instead of focusing on coding, music, and art in one week, I’m going to emphasize one. This week, that one is music. I’ve created a leitmotif for the antagonist, and I think it’s possible to expand that into a full track by next Sunday. I also think it’s possible to map out my next coding objectives so I can more efficiently tackle that the week after. Should I code a combo system? Begin building a rudimentary world? Create the UI? I won’t be able to actually code any of those this week, but I can decide which to choose and lay down the conceptual framework.

Whatever I choose, it’ll be in tomorrow’s Monday Map Out. Subscribing would get that sent directly to your inbox and it’d earn my eternal appreciation! In closing, I realized something while working this week: the top-down Zelda games are 2D Metroidvanias. I’m sure that’s not a unique thought, but it’s interesting.

See you tomorrow!