Sunday Show Out - 01/11/2026
My special projects course was a success, although we changed its focus halfway through the first day. We covered a brief history of webcomics and their early themes on Monday morning and spent that afternoon writing a script. The students were far more into creating than studying, so we spent the rest of the week making comics. While some students had more-developed art skills than others, and some were better writers, all give it all they had and enjoyed it. The result was a mix of funny comics, serious comics, personal comics, and unfinished comics delivered with a promise to finish them this semester (not finishing a comic is kind of a webcomic tradition). I learned a great deal from the students, mainly:
- Every generation will create its own sprite comic/comic built using game assets.
- Cartoonists who settle on four-panel gag comics will feel inferior to those that create pages while evoking some of the most visceral emotions.
- Holy muffins, Megatokyo is still running.
The most pertinent lesson, however, is one I already knew but about which I needed reminding:
Plans can change, as long as progress is made.
What did I do?
I woke up early each day, got ready, and spent about 45 minutes before work, working on Just Beneath the Holler’s prototype. I’d planned on finishing “Silver and Gossamer” this week, but it turns out making music isn’t necessarily a straightforward process. I opened FL Studio most mornings, added a chord progression, realized the progression didn’t fit the melody, changed the chord progression, listened to the chords wash out the melody, changed their instrument, lowered its volume, and, finally, change the half-notes of the chord progression into a metal gallop/reverse gallop rhythm. The song is still unfinished, but it’s already much better:
I get a nu metal vibe off the rhythm guitar, but who’s to say the fae don’t like Limp Bizkit?
The bulk of this week’s work was spent “revisiting” the infinite-scrolling code I’d written for the first version of JBtH and fixing its bugs. I’d only planned on importing the scene as-is, looking through the code, and making a few notes about how to fix it next week.
But I really didn’t like the tileset I’d chosen. So, I whipped up a new tileset.
And it’d have been weird for me not to immediately implement that tileset, so I replaced the old map with the new one.
I thought, “Hey, I need to run it a few times to figure out where the bugs are.” I noticed a lot of jitteriness and realized it was an issue of how I’d set up my “teleport” box.
So, I broke out graph paper and colored pens (three of them!) and drew my repeating terrain block along with its dimensions.
Then, I took a look at the scripts for the four Area2Ds/CollisionShape2Ds and realized that, when Zel contacted one, she was being respawned in the wrong place.
That’s such an easy fix, I said to myself, now that I’d plotted where she’d need to respawn. So, I edited the scripts and re-ran the scene.
And it worked flawlessly.
All I’d meant to do was import the scene, look it over, and take some notes. But plans changed, much like my students’ plans changed in the special projects course. And much like that course, I rolled with it and made sometime beautiful.
So, how does it actually work?
In the screen above, you can see a 3x3 repeated block of terrain with a blue box whose borders are just a bit beyond the edges of the center terrain block. That border is made of four Area2Ds with corresponding, pixel-wide CollisionShape2Ds. Each one has a script attached which triggers Zel to be teleported to the side directly opposite the wall she touches. The wall is an entire body-width outside of the terrain block but repositions her a half-body-width inside the terrain block on the opposite side. The result is a seamless motion that gives the illusion of an infinitely-scrolling world that loops back on itself.
The blue lines represent the teleport box.
The Place Just Beneath is going to be a lot larger and have areas that are blocked off until Zel has the abilities needed to access them, but the idea will be the same. And hey, that was the first item on my prototype to-do list, so I’m that much closer to releasing it. I have to count this past week as an unqualified success in terms of getting stuff done.
What did I learn?
Apart from the main lesson (things change, and I need to roll with those changes), I reinforced that I learn best with tactile feedback and old-school tools. Pens, rulers, and graph paper served me well and allowed me to fix the infinitely-scrolling code faster than if I’d just stared at a screen and waited for the answer to appear. Younger coders have that ability, I don’t. And that’s okay! Game development is a state function: the path isn’t important, just the destination.
As the weeks progress, I’m learning that I can actually do this. I’m capitalizing on the momentum I built over the holiday break and I’m continuing to work towards the prototype. I honestly believe that I can make a game now, something I didn’t quite believe even a month ago. There are a lot of moving parts, and each part is a challenge, but when should I ever let a challenge stop me? Sure, I wasn’t able to finish “Silver and Gossamer,” but was that a failure, or a learning experience I can use to get it done? I discovered a new tool in FL Studio that should help me finish the track and move on. And moving on, finishing one thing and going to the next, is what I do best.
What’s next?
There are a few items on my prototype to-do list that I can tackle next. The most pressing of those are the user interface (UI), sprites (both Zel’s and the enemies’), and finishing “Silver and Gossamer”. I’ll have a detailed map out tomorrow but, for now, I just want to enjoy what I’ve done and spend the rest of today fiddling around and letting myself explore.
Come back tomorrow (or have tomorrow directly delivered into your inbox) to see where we’re headed next. As always, thank you for being part of the journey!
