Road to Game Dev: The Final Boss. (Part 3: Component Framework)
With the boss completely put together, it’s time to start bringing everything to life! Up until this point, I’ve decided how many components each phase will have, where the boss should be positioned for each phase, and gotten a general idea of what kind of attacks the boss should have.
Briefing the Components
Very early into the process, I decided that the best way to manage the boss’s various components would be to give them a few simple functions which could then be controlled by the boss itself. This means that attacks can “speak” to each other much easier, and none of the components have to communicate with each other — only the boss has to communicate with them. That makes the process much less prone to breaking. This also makes the turret code, which will be created many times over for each turret, much more lightweight and saves on both space and processing power.
As always, it’s important to start by figuring out what the components need to actually do. I want turrets to be able to track the player, as well as stop tracking, or point to a specific location. I also want them to be able to fire projectiles, and in a few cases, toggle whether or not they are actually counted as part of the boss. Lastly, I need them, to communicate up to the boss when they take damage or are destroyed. For now, I’ve created an empty script on the main boss that I can call back to, storing it simply as “boss” so we have something to reference to.
Tracking
We’ve created plenty of functions before that can communicate between scripts; that’s a simple matter of creating public functions that return a value. The tricky parts are going to be tracking the player and communicating with the boss when a component is destroyed. The easiest way to start and stop tracking is to control is via Update(), only calling the tracking method when a boolean is set to true. This allows us to tell a turret to stop tracking just be setting that back to false. Here’s a look at what the actual tracking method looks like:
The golden line here is the line containing the “smoothdamp” function. It looks weird to have turrets track a player perfectly, and it’s not exactly fair for balance — we want the player to be able to “outrun” the turret’s ability to track them. Smoothdamp is a function that will gradually transition from one value to another, similar to Lerp. The difference, however, is that each time it is called, it updates an existing value that it uses as a reference point; this is why “tempVelocity” is passed in by reference. The “Stickiness” is actually the approximate time it would take to transition between the two values — increasing the value makes the tracking softer. What we get is a result that looks a little like this:
This movement feels much more natural than simply snapping to the player, and behaves a lot better than Lerp when rotating around a full 360 degrees. You can use a stripped-down version of the tracking function to also rotate to specific points, as well! Instead of the player’s position, you just need a specific angle to target.
Communicating to the Boss
The other tricky part here is communicating back to the boss when a turret is “Destroyed”. Up until now, we’ve always simply used the “Destroy” function whenever an enemy is defeated. This time, however, we don’t actually want to remove the components from the boss; we want them to still be accessible so we can check their status. For this, we need to set a boolen that we can call to tell whether or not they are destroyed, as well as a toggle that stops lasers from colliding with them once they’re dead. Here’s what the “Death Trigger” looks like:
With this, we’re ready to start building the main boss framework! Many of these functions only exist on the component so far, so it’s time to create them.
