Handling the Idea of Scrapping a Boss


Over this last week there were many issues as we closed out the game jam. One of the toughest decisions I struggled with was working with Devon to complete the zone 4 boss "The Weaver Worm". There were a lot of miscommunications and misunderstandings that led to a boss that was mostly in vision with the game, but did not function correctly. We had initially designed it using a behavior tree system. This system while functional (and awesome) ended up causing more issues than expected. Hitboxes were not lining up, rotations were off, and other weird anomalies too. After hours of work we had to decide if we could fix it, or if we had to scrap it. This boss was something we thought was really interesting, so we really wanted it to be in the game for others to see.

With two days left on the jam, I had ripped the boss to nothing and started from the ground up. I used the knowledge of the issues we were facing before to design the new version of the boss around them. From the point that we scrapped the boss, I had sat down for six hours to get something functional out for the boss. To remedy some of the original issues, I changed the center mass of the enemy to reduce the time of pass throughs of the boss by simply flipping him around his center mass as soon as he was off screen. Next, when I was designing the laser attack, I did not bother with trying to make one laser that was rotated and expanded at runtime. I instead had two constant lasers that were either active or inactive. This helped with the hitbox issue. Lastly, I overhauled the system that dictated when and how the different turrets would rotate. This prevented odd behaviors and again reduced the reliance on Unity's frame to frame collision detection which we have come to find shoddy at times. This in turn allowed us to have a playable version of the boss fight in the game jam.