Boss Design

Testing the player's knowledge...and my own.

 
 

Infinite Level game discussed: The Future Project


Surprise! This dev blog comes with a new gameplay video, giving players a look at the boss of Jeweled Tundra, the Apex Devourer. This coincides well with this dev blog's topic, and will be referenced a lot throughout the dev blog. Make sure to check it out first before reading along. All that said, this blog isn't strictly about the Apex Devourer. It will actually focus on the general approach to creating a boss fight in The Future Project, using Apex Devourer as our primary example. But first, one has to ask a very important question. What exactly is a boss battle for, anyway? In older games, this was pretty obvious. They were often a roadblock, meant to be a test of skill up to that point. They're fun, but I think back in the day the purpose was largely the peak to a game's difficulty curve for that world or level. And I should say, for a lot of games, there's nothing wrong with that. Oftentimes that exact philosophy towards boss battles can be the climax a level needs to satisfy players.

But what about as a teaching tool? That, I believe, is the category where a lot of bosses tend to be in these days, even if it's subtle. They're still tests of skill, but more for the purpose of assuring players have an understanding of the game's mechanics up to that point. Think of it this way...in the original Mega Man games, most of the bosses exist to be that final hurdle to get over before clearing a level and gaining that new ability. I wouldn't say they're trying to teach or reinforce anything, they're mostly a final challenge at a level's end. And for Mega Man, that works. Contrast that with, say, the Gym Leaders in Pokemon, where how much you struggle is dependent on the party of Pokemon in your possession and your knowledge of type matchups. Again, the lines can definitely be blurry, and what exactly makes for a great boss is highly dependent on the game itself. In The Future Project, you probably wouldn't want the first boss to expect you to have elemental abilities while you still don't have them. Instead, it would make more sense to structure the challenge around the abilities you'll likely have by that point.

 
 

That's always the goal when designing the bosses in The Future Project. They need to be just challenging enough to give players that rush when they finally beat them, but they also need to operate within the confines of the player's arsenal at the time. So, let's start with the game's first boss, called Forest's Greed. You'll have seen it before in previous screenshots and the game's trailer, though you don't get to see the whole fight there. By the time players reach it, it is expected that they will only have the basic gun, strafe, and the missile launcher. So what parts do we emphasize? Well, we can make the player use the strafe ability to avoid attacks, and give it the right amount of health so that the battle feels epic and challenging while showing players the difference between basic and missile projectiles. Additionally, we have a couple attacks that require the player to understand the basic movement, particularly the jump. The trick is, during the battle, you're not gonna normally think about these things. When the spinning tentacle attack appears, you'll probably instinctively jump to avoid getting swiped. Subconsciously though, you're building up a knowledge of jump height, which can then be later applied to help with platforming or timing your jumps to avoid more difficult attacks later in the game.

What about the Apex Devourer? Well, this is where things start to get a bit interesting. Since the player is allowed to tackle either the Jeweled Tundra or Hand of the Water maps first after acquiring missiles, we don't actually know if the boss will be second or third in line. If the player goes straight to the Apex Devourer, then the most we can expect is the player having increased health and missiles. But if they grab the fire ability and come back, that can quickly change how the battle goes. So, what do we do? We design around what we know the player will have, which is a basic gun, some missiles, and strafe. All of the Apex Devourer's attacks can be avoided with strafe, so we have that covered. At that point, we just account for the possibility of the player having the fire ability by this point. And since the point of the fire ability is to burn enemies, which does damage over time, we just make sure the boss has the health to account for that, while still letting the player feel the effects of melting an ice dragon. Likewise, the boss of Hand of the Water is designed so that the air dash ability, acquired after defeating Apex Devourer, can aid in the boss battle in some way.

 
 

All of this is just getting into the design and the possibilities one has to consider when designing a boss for The Future Project. We haven't even gotten to the implementation yet. In many ways, bosses are put together very similarly to enemies. You of course need a model and animations to work with, and then you put it all together using Unreal Engine's animation blueprints and code. Bosses in The Future Project will have a lot more animations than a single enemy though, thanks to all the extra attacks they have. The Apex Devourer seen in the video above has to, among other things, shoot, um...ice fire...out of its mouth, stab the player with its tail, and even fly around the arena. Incidentally, while there are a few bosses that move around frequently, very few of them straight up fly. So as far as animation goes, these boss battles definitely get a little more time in Blender than other objects. Once they're ready to go, I link the animations together and setup the conditions for transitioning one to the other, then move on to the coding portion of boss creation.

Every boss is different, so while you can pick some parts from one boss and copy them over to another, you're going to ultimately be writing a lot of unique code for a given boss. Apex Devourer is arguably the best example of this thanks to its aforementioned flying. What it does during its flight, and how it goes about flying at all, is completely unique to this boss. This is a large part of why making a new boss takes as much effort as it does. No two bosses are quite the same, you see. Most of them require a complete set of code unique to them, with perhaps the only consistency between bosses being the code that defines their attack sequence. Thankfully, I've structured the code in such a way that it's generally pretty easy to find what I need to edit. For instance, projectiles are almost always spawned after calling an animation event, so if while testing the boss I find there's an issue with a projectile, that's likely where I'll be starting. Quite a bit of boss functionality is tied to animations, actually. The main blueprint handles the attack sequence, stats, and other special items, but its honestly the animations that bring it all together. When animating a boss, it's important to me to have a very discernible wind up time so players have time to react and know what attack is coming.

 
 

As the game progresses, so too can the boss complexity. The first boss, Forest's Greed, only has a few attacks. A projectile, spinning tentacles, and a giant tentacle that slams down. That's honestly all there is to it. Apex Devourer, meanwhile, can stab the player with its tail, shoot “ice fire”, spawn multiple different projectiles, and lunge forward. In general, each boss tends to grow in complexity with the player, which helps create a natural difficulty curve for the game. My idea is that by the end, the final boss will have all kinds of wild attacks and abilities to throw at you, making for an intense and fascinating battle. It'll be the hardest to put together, no doubt, but it may honestly be the most fun to fight because of its complexity. That's another interesting thing about making a boss for The Future Project – they're as much a test of my own skill as a game developer as they are a test for the player. Each new boss is such a different task from the last, requiring me to really think about what will make it fun and how it will come together. And as established, they get more complex as I account for new player abilities, so that makes things all the more challenging. The trouble for me is that I won't truly know if I've succeeded until the game is in player's hands. I enjoy fighting these bosses and think they pose a very worthy challenge, but that enjoyment can't be just for me. Bosses need to be fun for everyone.

Well, this has been a fun dev blog. I think this is the first time I've released new gameplay footage alongside a dev blog. Maybe the announcement blog for the Steam page counts? It's the best of both worlds, really. New footage to watch and (hopefully) interesting insight into the creation process. As it turns out, I actually only have a couple more boss battles to create before I'll be done with those. There's one that, without saying too much, is really a two part boss which feels a bit like making two boss battles in one. And of course, there's the final boss which I'm really looking forward to creating. This isn't a progress report blog, but I'll at least share that the game's content is really coming together. Pretty soon the bulk of what I'll be doing is making map modifications and bug fixing. How soon is “pretty soon”? Good question. Depends on how challenging this boss is to put together, I suppose!

Until next time!

-Lance T.

Previous
Previous

Connecting the Stories of Impressions and The Future Project

Next
Next

July Progress Report