Sunday Show Out - 03/29/2026
(REMINDER: Download keys will be sent out Monday, May 4th. If you want to playtest the Beatdown in the Holler prototype, either subscribe or email me at pete@petemakesgames.com.)
The prototype is finished, five weeks ahead of schedule.
That doesn’t just mean the game is in a playable state (which it is), or that I squashed all the major bugs I could (which I did). The prototype itself wouldn’t be effective without feedback, so “finished” also means:
- the itch.io page is live;
- hollergames.com is live; and
- the feedback Google Form has been finished.
So, how did I get there? I'm glad you asked (in this scenario I assumed you'd asked).
What did I do?
In the last update, I’d estimated that the prototype was “mostly complete”. There were only two more issues keeping it from being actually complete and I spent all of Friday morning sussing those out. It was more difficult than I’d anticipated, however, as two issues turned out to be three.
The melee attackers (which I’ll call Orange Guys, or OGs), would “glue” themselves to Zel if she approached them from the bottom. Any other direction and they’d attack Zel and knock her back. However, if Zel was below them, they’d stick to her and she wouldn’t be able to shake free or push them out of the way.
There were some clues I could use to help sort out the issue. Zel could still attack and kill the OG, which would allow her to move freely again. The OG itself, though, wouldn’t attack while it was stuck to Zel. Zel could also “unstick” herself if the OG got hung up on a corner and Zel pulled away from it. These clues told me that it wasn’t an issue with the enemy finite state machine (FSM), at least not an issue with the enemy getting caught in a particular state. If it was an FSM issue, it should have affected all enemies the same.
I decided to focus on the attack (or lack of) behavior the enemy exhibited when attached to Zel. I inserted a print statement to check func can_attack() and realized that, when the enemy was attached to Zel, its attack trigger couldn’t fire. So, I enabled visible collision shapes and, wouldn’t you know it, the collision of Zel and the enemy (at least from when Zel was below the enemy) was one pixel larger than the attack trigger radius. So, I bumped up that value by two pixels and the enemy started attacking again.
The enemy was still stuck between attacks though. I had to sit with this issue for a bit. Why did the sticking happen this way? It felt like the OG was falling onto Zel. Falling. . .oh, yeah, enemy motion was set to Grounded. In Godot, Grounded motion is used for 2D platformers, while Floating is used for top-down games. Beatdown in the Holler is a top-down game, but the OG was acting like it was in a side-scroller. Gravity was pulling that little guy down and causing it to stick to Zel. It wasn’t affecting the other enemies for reasons I haven’t quite figured out, but that is a Tomorrow Problem.
Two issues, masquerading as one.
Two issues, fixed.
The last issue was minor, and I feel like kind of a doofus for not figuring it out sooner. When Zel pulled an enemy towards herself from a vertical position (above or below), the enemy would “snap” to Zel’s side. It took a few minutes, but I realized the snapping was to prevent Zel and the enemy from overlapping. That was an easy fix: I increased the hook offset (the distance at which the enemy ends up from Zel, after it’s reeled in) and the enemy behaved normally.
The last issue, fixed.
All major bugs, fixed.
The prototype was finished.
What did I learn?
It’s difficult enough to find bugs when the behaviors they generate are caused by a singular issue. It becomes much harder to determine the problem if two bugs are working together to create the behavior. I was fortunate in that the “sticking enemy” issue was the result of two obvious problems (default enemy motion and simple collision). Had the issues been more subtle, it would have been more difficult to isolate and fix them. But that is a skill I’ll have to develop as I continue making games, and I plan on making games for a long time.
I also learned that making a game is only part of the game development process. I’ve had to make websites, create promotional art, write a feedback form, and put it all together in a way that doesn’t deter people from signing up for playtesting. Every decision has to be made with “will this make it easy for people to play my game?” in mind. I’m still not great at that but, once again, it’s a skill I’ll have to develop.
What’s next?
The immediate future holds me promoting Beatdown in the Holler to potential playtesters. I’ve never been a fan of self-promotion, but it’s time for me to get good at it. I just need to focus on my love of community and how I can contribute to it, not take from it.
My goal is to release the full version of Beatdown in the Holler by the February 2027 Steam Next Fest. That’s ten months away, which is simultaneously forever and tomorrow. I’d like to take a victory lap for finishing the prototype, and I may spend a few days doing that, but I need to set up my workspace. Whether virtual or tangible, I work best with a clean desk with everything in its place.
As always, come back tomorrow for next week’s plans. Thank you for joining me on this journey and I’ll see you then!
