Welcome back everyone! 

I'm Isiah, one of the programmers at Studio Betalion who worked on our newly released game Corrupted Castle! If you've been following along, you may notice something different-yep, we've had a name change. The game was originally called Script Scrapper, but after some feedback and discussion, our team realized Corrupted Castle rolls of the tongue better and fits the atmosphere of the game more effectively. Like with all things in game development, names evolve-and we're confident this one fits our vision best.
For this devlog, I'll be diving into the current state of our boss fight-what's been updated, improved, added, or even cut. There's a lot to share, including new visuals, animations, attacks, and some under-the-hood polish that brought everything together.

Boss Fight Sequence Changes

Since our last devlog, we've made some significant changes to the boss fight-both in terms of design and technical implementation.

One of our new additions to the boss is the code-generated shield that not shrouds the boss at the start of the fight. Visually, the shield appears as lines of glowing script, dynamically wrapping around the boss like lines of active code. This design reinforces the core theme of the game: the Dev fights using the same code-based mechanics the player has been learning throughout their journey.

Code Created Shield Visual

Functionally, this shield acts as a barrier that prevents the player from dealing direct damage. It has a set amount of health and must be broken before the boss enters a vulnerable state. Originally, this vulnerable phase ended after the player landed three hits. While that worked on paper, repeated playtest revealed it dragged the pacing a bit.

Caleb, one of our team members, suggested changing it so the vulnerable state last for a set amount of time instead. This turned out to be a great decision-it not only improved the pacing of the fight, but also simplified the code by about 20 lines.

With the shield mechanic finalized, I shifted focus to reinforcing the script-based gameplay we've introduced throughout the game. Players have been collecting and repurposing scripts from enemies to solve puzzles and defeat foes. So in the boss fight, I made it so the boss takes more damage from scripts it's weak to, just like the enemies leading up to this moment. To give players a fighting chance, the boss also periodically spawns two enemies during combat: one that is vulnerable to the boss's current script, and another that resists it.

This creates an important gameplay choice:

• Play it safe by targeting the resistance enemy and nullify incoming damage.
• Go on the offensive by targeting the weakness enemy and stealing its script, the player can increase the damage it deals to the boss

This trade-off forces players to actively manage risk and makes each phase of the fight feel more strategic.

Hands, hands and more Hands!

Back in our early dev states, my teammate Caleb created the original concept art for the boss-complete with massive, floating hands. While I was able to prototype the keyboard and general mechanics, I knew I needed help brining those hands to life.

Enter Tyler. He modeled, rigged, and animated the boss's hands, syncing their movements with the keyboard animations i had already implemented. The results were fantastic-the animation style Tyler used perfectly captured the chaotic energy we wanted from the boss.

Animation Showcase:

Idle Animation

Summon Animation

Move Animation

Swipe Animation

Smash Animation

Getting the hand and keyboard animations synced wasn't easy. Our first solution invlovled using animation events to trigger them in parallel. While functional, this method lacked flexibility and quickly became messy. Ultimately, I rewrote the system to include buffer frames between animations, making timing easier to manage and more reliable overall.

Swipe Vs Smash

One of Tyler's contributions was the swipe attack-a wide horizontal slash intended to knock back players and deal damage. While it looked great, syncing it with hit detection, animation, and player physics proved more trouble than it was worth. After multiple iterations, I made the tough cal to scrap it from the final version. But from the ashes of Swipe came something even better: the Smash Attack.

Someone's Gonna Need a New Keyboard

The smash attack came from a brainstorm session between Tyler and me. The concept was simple but powerful: the boss slams the keyboard with both hands, causing keys to explode outwards in a chaotic burst.

To implement it, I wrote logic to randomly select four non-combat keys on the keyboard. During the attack, each selected key is launched in a random direction using physics forces then destroyed after a few seconds. I originally had each key deal damage when it landed, but this made the fight too punishing, so I removed that mechanic in favor of more visual flair.

The attack is triggered right after the boss regains control following the shield break. This helps reset the battlefield and prevents players from cheesing the boss while it's recovering.

Sneak Peak into the Attack

With another helpful hand from one of my teammates Bryson I was able to add some VFX to this attack to really sell the scale of this action.  and with some sound effects added to replicate the sound of a smashed keyboard and some fallen keys the attack was ready to ship out and see it in action.

Final Thoughts

When I first began planning the boss, something always felt like it was missing. There were too many moments of downtime, and the transitions between phases lacked cohesion. Adding the shield, the Smash attack, and strategic enemy spawns brought it all together. 

Now, the boss not only challenges the player's reflexes and timing, but also tests their understanding of the game's mechanics. It's a fight that feels intense, sometimes frustrating, but ultimately fair-and most importantly, fun to master.

Thanks for reading this far! ^_^

We've got even more updates coming soon, so stay tuned for the next devlog. 👾