FIVE POINTS OF DESIGNING A BOSS
Design a boss’s abilities in a way to create a fun amd engaging battle
What makes a game fun are its challenges.
An RPG has a lot of different types of challenges. Conserving items and MP, locating a treasure chest in a dungeon, and dodging 200 lightning bolts in a row are all challenges, but the most memorable challenges in most games are the bosses. They’re what the other challenges seem to lead up to.
A boss can generally be broken down into individual abilities that it has. These abilities are essentially individual sub-challenges which the player deals with during the boss fight. The player has to overcome each ability the boss uses in order to overcome the boss. Things that are common among all enemies throughout the game, like the way that normal attacks and debuffs work, are worth looking at, of course, at some point during the game design process… but when looking at a boss you should narrow your view to what’s unique or semi-unique to that boss and focus on it. Maybe it summons minions, maybe it heals itself, maybe it inflicts passive damage to your whole party every round, maybe it’s immune to fire magic, maybe it gets two turns every round. Each of these is an ability that the player must overcome. These are the kinds of things we’ll be focusing on.
Let’s look at how to make a fun and engaging boss. I’ll start with a very straightforward checklist that can be applied to practically any type of challenge, but in this case we’ll be applying it to the abilities and behaviors of bosses.
Note, the following list is not my list. It is courtesy of the boss design team at Blizzard Entertainment. Hopefully that lends it some weight. They’ve made a few thousand more bosses than most of us, after all.
1. Is it clear what’s happening?
2. Does the player care?
3. Does the player have a response?
4. Is this response satisfying?
5. Does this make sense in this situation and fit the theme?
That’s such an obvious list! Which makes me wonder how it is that so many bosses fail on multiple checkpoints. Sometimes even all five.
The list isn’t in order of importance. The order of importance depends on how climactic you want the ability to feel, the type of game you’re making, the parts of gameplay you want to emphasize, the core player mechanics, the difficulty level you want, and how early in the game the boss is, among other factors. You can’t ignore any of them, though.
Is it clear what’s happening?
The player needs to be able to understand what’s going on. This isn’t negotiable.
What is negotiable is making sure the player always understands how to respond. That’s not the same thing. In an RPG, puzzle game, strategy game or adventure game, the player can figure that out for himself or herself most of the time. Doing so is most of the game, in fact. But there’s a difference between making the player figure out how to respond to the situation and not informing the player of the situation. If there’s no known situation, there’s nothing to figure out. You’ve made a puzzle with no pieces.
A simple example is elemental immunity. If you don’t display damage numbers, and you don’t convey failure of attacks in any other way, the player has no idea whether the skills he’s using are having any effect. He has no idea if the boss is still alive after 150 fireballs because it has that much HP or because the fireballs are ineffective. If every other enemy in the game dies after 2-4 fireballs, then you have SOME conveyance, but probably not clear enough. Alternately, if you do show damage numbers, but the boss takes only 5% damage from fire and is immune to everything else, the player will think that he’s doing something wrong by casting fire because the damage numbers are so much lower than normal. But in fact, fire is his best option (his only option!), and he’s only confused because you’ve conveyed information in a confusing way.
Here’s a more complex RPG boss example. You have a boss that counterattacks with the same element the player uses, and then becomes immune to that element. If this happens invisibly – don’t laugh, I’ve seen it done – the player will be utterly baffled that a spell that worked before isn’t working now, and that the boss’s attacks sometimes do less damage.
And now you complain at me. “But recognizing the boss’s pattern is a huge element of gameplay!” You’re correct. But there has to be a way to recognize it. There are a lot of different levels of conveyance between invisible mechanics vs. outright telling the player exactly what’s happening and why. For example, when the boss counterattacks with the same element you used, what does it look like? Does the counterattack happen immediately, to cue the player to the fact that it’s a direct response, or does the boss gain a quarter of its ATB bar and then cast the counterattack, diminishing the link between the two events in the player’s mind? Does the counterattack have an animation that matches the element used, or is it the same animation for all elements? Does a text box at the top of the screen say “Flaming Response”, or at least “Flame”, or does it say something indecipherable like “Dead Galaxy Song”? Is there a fitting animation and spell name when the boss changes barriers? Does the player have any way to tell that a boss is immune to an element without using it? Can the player at least clearly tell that the boss is immune once they do use that element?
Veteran players can be expected to recognize patterns more easily than novices, since they’ve encountered them many times before. So if your game’s audience is only expert gamers, or if the boss appears near the end of the game and you’ve used the same gimmick several times before, you can be more stingy with your conveyance.
A boss ability that fails at clarity would be a physical skill that targets your lowest HP party member, otherwise indistinguishable from other physical skills. A version of this ability with slightly higher clarity would be one that is triggered immediately upon any character dropping to critical HP – the player can’t see the targetting connection, but can see the timing connection and possibly connect the dots. An even clearer version would name the skill “Finishing Blow”. An even clearer version would give several non-boss enemies before the boss the same skill, so the player can see it happen a few extra times before being forced to understand it or die in the boss fight.
Does the player care?
This seems like it should be the easiest one to fix, but you’d be surprised how often designers still fail at it. The truth is that it’s a little more complex than you might think.
The simplest type of skill the player doesn’t care about is a damage skill that doesn’t deal enough damage. But how much is “enough”? The simple answer, assuming the player has a response other than healing, is “more than you can heal before it gets its next turn.” But sometimes that feels too punishing to the player, and you want to make them care a different way.
Let’s look at the first boss of Final Fantasy 7. It’s a giant robot scorpion that alternates between two stances. When its tail is lowered, it does nothing, so you’re supposed to attack. When its tail is raised, it counterattacks when you attack it, so you’re supposed to wait.
Sounds okay in theory, right? But you have healing magic. If the boss counterattacks you four times, you only have to cast your healing spell twice to bring your whole party back to full HP. You might run out of MP to heal with, but unless you wasted all your MP on the normal battles before the fight started, that’s probably not a concern. And aside from its counterattacks, the boss never hurts you much – it would have to spend several minutes attacking you to deal as much damage as its laser does. As a result, you can win the battle faster, and without any risk, by ignoring this ability and attacking even when its tail is up. There is nothing in place to make you care about it.
Contrast this to the first bosses of Final Fantasy 4, 5 and 6. They work almost identically, except when they’re in counterattack mode, they also become invincible. The player now cares about the ability, because there’s no benefit to ignoring it. They don’t save any time, they don’t deal any damage, and they don’t become any safer. They get nothing at all out of attacking at the wrong time. So now they’re forced to care. Problem solved. (Except that this ability also fails point #4, about the player’s response being satisfying, but we’ll examine that later. It also fails point #1, about clarity, but only because the translation from Japanese is terrible…)
Sometimes, especially later in the game when player decisions are becoming more complex, you do want there to be a risk vs. reward equation, making there be some benefit to possibly ignoring the boss’s ability in some situations. Figure out what those situations are, and then figure out a way to give a benefit in those situations but not others. For example, imagine that there’s a time limit during the fight with the FF7 scorpion boss. (In reality, there is a time limit in that dungeon, but it doesn’t start until the boss fight ends, so this is easy to imagine.) Maybe your goal as a designer is for attacking the boss while its tail is raised to only seem like a good idea when the player is running out of time, but a bad idea otherwise. This would be trickier to execute – you’d need to figure out how much damage the counterattack actually needs to do to make the player think “oh crap, that was a bad idea.” If it took away 3/4 of the party’s maximum health, would that be enough? You could still recover from it effortlessly in two rounds, since your healing spell at that point in the game can almost fully heal you from 1 HP. And Cloud wasn’t doing anything else for those two rounds; he was just standing there waiting for the boss’s tail to lower. So there’s still no reason to care. No amount of damage is enough in this case unless it kills you, and killing you for one misstep is too severe a penalty for the first boss in the game. It might be necessary to reduce the effectiveness of healing as well, or to make the laser skill inflict silence for a few rounds. There are usually a lot of different ways to get the result you want, each with different side-effects.
Does the player have a response?
Design your bosses’ abilities with your players’ abilities in mind, and vice-versa.
There is a technical term within the game development community for dying to something that you can’t do anything about – the term is “bullshit”.
If a boss has a skill that does 90% of your party’s max HP, and it gets a critical hit, that is bullshit. If a boss has an area instant death skill, that is bullshit. If a boss puts your entire party to sleep and then burns you to death while you rest peacefully, that is bullshit.
I’m going to keep emphasising this, because some of you don’t get it. I know you don’t: I’ve played your games, and I’ve listened to your justifications for the bullshit that fills them. “It hardly ever happens” isn’t a justification! It really, really isn’t. This is almost as fundamental as it gets in game design, I think: when faced with a challenge, the player should be able to do something to beat it. Not win through random chance or clairvoyance, but through the abilities and other gameplay mechanics that you give the player access to. You can certainly have some elements of randomness in the gameplay, but if the player plays the game utterly perfectly, making absolutely no errors, he or she should succeed.
Let’s take that a step further. Apply it not just to the boss as a challenge, but to the boss’s ability as a sub-challenge. If the player performs perfectly, making absolutely no errors, he or she should be able to “win” against the ability. In an action or platformer game, or even in Mario RPG, what this means is pretty straightforward, but in a traditional RPG, it gets murky. Extremely few enemy skills can be completely dodged.
So you have to re-define “success” for a boss ability. What’s success? Surviving until the next ability? Taking less damage than you can recover? It depends on the game, the boss, and the ability, in truth. In a game where you can fully heal one character each round, you can be said to have succeeded if you survive the hit. In a game where your MP is extremely limited, you can be said to have succeeded if you minimized your MP costs. If a boss uses a skill to inflict a status ailment that makes you take triple damage from the next attack, you can be said to have succeeded if you cleanse the ailment before the next time you get attacked.
In that last example, taunting the boss to attack someone other than the ailed character can make the ailment easier to handle. In fact, taunting the boss to attack someone less vulnerable instead of someone more vulnerable is a common way of dealing with threats in any RPG that has tanking. This is why tanking has become popular in RPGs: it gives the player a response to most of the things enemies do, so they can feel like they succeeded. Tanking can easily be done wrong – it’s extremely hard to make tanking an optional way of playing, for example – but when done right it lets the player respond to enemy abilities by partially nullifying them, which creates engaging gameplay with success and failure conditions, but doesn’t get in the way of the standard RPG idea of unavoidable damage that must be healed (because you’re still taking some damage).
If a skill has no way to respond to it, it’s a bad skill. For example, randomly stunning the player for one round, with no way to avoid it. Even if you have a spell or item to remove the effect, it only lasts one round; removing it has almost the same effect as leaving it alone.
If a skill has no way to respond to it except one that still feels like failure, then you as the designer failed at the fourth point:
Is this response satisfying?
Sometimes you can give the player a way that technically works, but still doesn’t feel like success, even though it is. Reviving a dead character only to have them die again 30 times in a row isn’t satisfying, for example. It feels like you are failing.
This is because a character dying is a way that video games communicate failure to the player. A game over screen is another. Dealing 25% as much damage as usual is another. Taking counterattack damage is another. Having all your buffs dispelled is another. Having gold or exp or some other kind of points deducted, points that you usually get from battles as a reward and only spend when not in battle, is another.
When you make one of these things happen, you’re telling the player “that ended up worse than it was supposed to.” In truth, the reason it ended up worse than usual isn’t the player’s fault – it was the best-case scenario. You were reducing their damage by 95% and making the boss randomly kill the party leader for some other reason unrelated to the player’s performace: possibly as some kind of convoluted balance mechanic, or because it was thematically fitting, or just to change things up. But what you’ve communicated to the player is “that was wrong.” Because the player has played your game enough, and played other games enough, that he mentally links a character’s death with his own failure.
And here’s the bothersome part: even if the player consciously knows that this situation is different, and that he did in fact succeed, the failure neurons in his brain are still triggered. It still feels bad.
An alternate type of unsatisfying success is simply invisible success. When the player succeeds, he or she expects to see an explosion, a cheering crowd, a scoreboard. The boss flashes brightly and dissolves into mist. Huge numbers pop up and bounce across the screen, telling you how many thousands of points of damage you did. You sidestep the enemy’s fireball and it flies off the edge of the screen harmlessly. Or the fireball hits you, but an energy barrier pops up in the way, deflecting it with a *ping* sound. Your critical-health ally jumps back to action as angels bathe him in light. When these things don’t happen, it’s not as bad as feeling like you lost, but you don’t feel like you won either. There’s no satisfaction.
The best satisfaction comes from a combination of game mechanics and visual and audio effects. You simultaneously see, hear, and know that you did it right.
Does this make sense in this situation and fit the theme?
This one is the most difficult for me to talk about. If you’re a “story person,” maybe this is the only one you have cared about up until now. Maybe you think gameplay doesn’t matter as long as the story is enthalling.
That makes you a bad designer. All five of these points affect, and depend on, the story. The story is told through the gameplay as much as through the dialogue and cut scenes, if not moreso. The player is the one experiencing the story, and your job is to make that experience memorable.
But it’s easy to go the opposite route and have just a big a problem. There’s a reason that even when we make “story-less” dungeon crawlers and action games, there’s still a setting and a theme to some degree. There’s still a specific ambiance. It creates feelings in the player’s mind that coincide with the gameplay. The gameplay is given meaning.
The feeling that concides with bosses is that of a climactic struggle. It’s what the rest of your recent battles – and possibly other events – have been building up to. And so you want it to feel like that: both in the story and in the gameplay.
The wrong battle mechanics can break that, though. Let’s say the boss you’re fighting is one of the five demon generals. Because it’s emerged from the fires of hell, you think it would be good to give it all sorts of fire skills. So you give it a fire spell, a stronger fire spell, an area fire spell, and make it immune to fire.
Uh, okay, that seems simple enough — boring as hell, but it’s thematic and sensible, right? But… in the rest of the game, demons aren’t all fire-elemental. In fact, most of them are shadow-elemental and use physical attacks and curses. This guy doesn’t even fit in alongside them.
There’s a disconnect, where the player is being told that this boss is one of the most powerful demons in existance, but he doesn’t feel like a demon at all. He feels like something totally different. As a result, the battles against the other demons don’t feel like they build up to this battle.
Let’s try again. Most demons have weak shadow magic, so we’ll give this guy strong shadow magic of several types. Other demons have curses, so we’ll give him a really powerful curse. And then he can temporarily buff his own physical damage from time to time, giving the player parts of the fight that are harder.
Okay, now he feels like a badass demon. But does he feel like a general? Who’s he in command over? Maybe you killed all his minions on the way in – that’s fine if so. But maybe the area has random battles, which means there are always more demons around. In that case, to make his gameplay match his story, he should be able to call for reinforcements – all the other demons should listen to him. Maybe even command them to take hits for him. Maybe he can be extra demonic and sacrifice his soldiers to feed his own powers. Maybe his curse spell leaves him vulnerable for several rounds, but he relies on his minions to protect him. Maybe one of his shadow spells strikes friend and foe alike, because he is cruel to those beneath him.
Great, we’ve got abilities that match the boss very nicely now. He feels like a badass demon general – up until three dungeons later, when the minions of the third general are stronger than this general was. From a story point of view: what the heck? But from a gameplay point of view: unavoidable, right?
It’s not unavoidable. If he’s really supposed to be that powerful, then you can come up with a gameplay mechanic that weakens him. Perhaps the player obtained a piece of equipment that nullifies his powers. Perhaps you have a spell, or a party member, or an NPC that binds and weakens the demon general. Perhaps you fought a battle earlier to destroy his sword, which was sentient on its own. Perhaps you fight alongside some legendary hero, or perhaps you engaged in a stealth mission to catch the demon general in the bathroom with no armor on. Notice that these methods of victory are being relayed through game mechanics, not just cut scenes. The gameplay and the story are woven together.
If you leave the player with those types of disconnects unresolved, both the story and the gameplay suffer. The encounter goes from being memorable and climactic to being a pointless mess that doesn’t evoke the feelings it should.（source：rpgmaker）