Developing a final boss battle — Here we go!
For my final programming challenge, I wanted to do something I’ve been wanting to do for a long time and develop a large-scale boss battle. Maybe I’m biting off a little more than I can chew, but I think I’ve got the knowledge now to make a simple arcade boss battle in the style of R-type and others where the ship takes over the entire screen.
I’m currently working on a concept for the boss so it’s a bit rough right now.
Using Krita and the mirror tool, I was able to come up with this so far. No photo bashing yet, that will more than likely come later. Since I already have something I can put into the engine, I thought I’d place the sprite into unity, but not before halving it to save space.
This is actually double the size it should be. The idea was I’d build a ship on a grid of 512x512 squares, originally 3x3, but then I opted for 3x6.
Inside of the game, I placed two copies of the boss graphic inside of an empty and flipped the other over. Within the same empty, I placed another empty called BossMover which would be a transform I would use for reference to moving along a path of waypoints.
I then made another empty called boss path and placed a few waypoints in it. Ultimately, I just created an array of waypoints inside the boss code itself and dragged them into the array via the inspector.
Here’s the current Boss Code
Step by step:
_bossMover is the empty inside of the Boss gameObject which we’ll use to compare for the Vector2MoveTo when we move from waypoint to waypoint.
_waypoints is an array that holds all the empty transforms that will be used as waypoints for the boss to follow.
we’ll need a way of knowing what waypoint we’re on so _currentWaypoint gets initiated with 0.
We’ll also make a speed variable available to the inspector so we can change the boss speed. I needed the boss to move much faster when I was placing waypoints, so I can attest to making certain variables public useful!
_waypointChosen was created because there was an issue where the boss wouldn’t move to the next waypoint because ALL of them were being chosen once it reached a waypoint. Having the program wait a few seconds before checking again and being safely out of the zone of transform equalness would resolve that dilemma.
I generally like to modularize my code as early as possible to keep things readable. So in the Move function, we immediately use the Vector2.MoveTo function to move from our current position to the current waypoints. Then we do a check to see if it made it, if it has, we start a coroutine called…WaitAndGoToNextWaypoint().
When we start the coroutine, we immediately wait 3 seconds (this will more than likely change later according to how many enemies there are at each section, but 3’s a good number for now just to see if things are working.
Then we call a function called NextWayPoint(). Why not just put the code after WaitForSeconds? You can do it, of course! I just like to know what’s happening and this makes it easier for me to later on see what’s going on in the code when I’ve long past ridden this train of thought.
So the next waypoint function checks to see if a waypoint’s been chosen. I put this in as a safeguard so Unity doesn’t go crazy and try to choose a whole bunch because we’re currently sitting on our first successful waypoint for at least 60 frames and those are 60 times we can potentially choose a new waypoint.
So we add one to the waypoint, and if we go over the current number waypoints we have in our list, we just reset it to zero. Then we say Ok, we’ve chosen a waypoint, and we set off a timer to reset that variable back to false after a few seconds once the boss has moved off that transform and the current transform no longer equals the waypoint transform.
Everything looks good! here’s how it looks so far. Looks like it’s going to be an impressive bossfight, hopefully!
