Sunday Show Out - 01/18/2026

This past week was my first “normal” week back, with a regular class and duty schedule. We had our normal beginning-of-year meetings, and I volunteered as a server for our first community dinner of the semester, so it would have been easy for me to write off this week and excuse myself from getting any game development work done. I knew this would be an excuse instead of a reason, though, and I refuse to let myself make excuses.

Instead, this was one of the more productive coding weeks I’ve had in a long time. While I only had one objective (to enable enemies to teleport when Zel does, to preserve the illusion of the infinitely-scrolling world), I’ve learned enough to know that would be a more involved task than it looked. While it was, and I spent a good deal of time fixing problems of my own making. I succeeded in that objective while also shoring up the enemy finite state machine (FSM). Even from my own, sometimes demanding, standpoint, this week was a success.

What did I do?

I added x_offset and y_offset variables to the four teleport scripts that equaled the distance between Zel and individual enemies. I then applied that offset to each enemy whenever Zel teleported. Zel teleported and, sure enough, the enemies went with her. Of course, it wasn’t that easy.

If the enemy lost track of Zel, it would go back to its original patrol point. From the camera’s perspective, it looked like the enemy just sauntered off to pace in circles somewhere else. That was a bug that needed to be fixed. I had already experienced other bugs, and I knew more would follow suit, so I sat down and began playtesting.

Up until this point, I tried to fix a bug as soon as I spotted it. That worked, but it didn’t feel terribly efficient. I tried something new this week: conduct a more extensive playtest and chronicle every bug I could. Then, fix those in order of importance/ease.

The persistent enemy FSM bugs were the most important to clear up first, as I didn’t need any bugs in the enemy teleport mechanics to be compounded by issues with the FSM itself. I added line of sight (LoS) code to the FSM so it wouldn’t lose Zel around a corner, directed the enemy to chase Zel as long as she was in distance of its $SightRay (even if its back was turned), and to chase Zel after knockback. The LoS code still isn’t rock-solid, but it’s much better and I felt confident I could now go onto enemy teleport issues.

I wasn’t terribly happy with my teleport system. Four Area2Ds, each with their own CollisionShape2Ds, were a good idea, but I had four different scripts to govern the rules for the teleport box. In my estimation, it would be cleaner to create a scene for each wall of the box, with each scene containing an Area2D and CollisionShape2D. I could then write one script and attach it to all four walls. The script has export variables for direction (“top,” “bottom,” etc.), the scene for the opposite wall, and the offset distance. After about an hour of redesigning the scene tree and another hour of coding, I had a re-written, working teleport system that used three fewer scripts and, more importantly, implement on other levels more easily.

Now I could finally sit down and work on the enemy teleporting issues. I created a new group, WorldShiftable, and added the enemy to it. I also created a new function in the enemy FSM, apply_world_shift. The teleport script called that function when Zel teleported and the function changed the enemy’s patrol points, relative to Zel’s post-teleport coordinates. I fired up the scene for the Place Just Beneath, teleported, and watched as the enemy remained in its current patrol route, its coordinates having been shifted during the teleport. It worked now!

What did I learn?

I realized that I had to stop, consider how a piece of code worked, and determine if it was better to rewrite it to be more efficient. In other words, I had to know when to refactor my code. The teleport box for the infinitely-scrolling map was good, but it needed to be better so that I could more easily reuse it. In redesigning the architecture and refactoring the code, I also made it easier to fix the enemy behavior when Zel teleported across the map. I spent about two hours redesigning the entire teleport system that gives the illusion of an infinite, looping world, but that will likely save many more hours in the future.

I also learned that some of the issues I thought were bugs are really due to the small size of the world map. I made a looping world of 2720 x 1760 pixels, much smaller than the actual dimensions for the Place Just Beneath. I noticed that, when the enemy stopped chasing after we had teleported, it went to the correct patrol position, but I was confused by the behavior. In reality, the world was so small that I was expecting the enemy to go back to its original patrol route, the route that was actually incorrect. So, I need to build a larger world map to eliminate these issues of scale.

What’s next?

Is the larger map the next item on my to-do list? I think it is. Whether I redo the sprites at this stage is a matter on which I’m still undecided. I would also like to introduce two new enemy types: a flying enemy and a heavy enemy that can’t be pulled. That would give the combat a bit more variety before I eventually get to combo/special attacks.

I’ll also, finally, make music a priority again. I don’t like to promise things, but I will promise that I will try.

Regardless of what I plan for next week, you should subscribe so you can read about it tomorrow. As always, thanks for joining me on this journey!