Design Dive: Boss Health Bars

Hail, Wanderers!

Boss fights are a core component of many games. They are fantastic and memorable challenges for the player, and an opportunity for designers to present specific skill mastery tests to the player. They tend to be the most challenging moments in the game, or are often intended as such, but that level of challenge brings with it some potential issues. Specifically, it can be rather frustrating for a player to get stuck on a boss, challenging it time and time again without finding success. While that challenge is often a core component of the boss, and in some games that feeling of frustration and struggle is very much part of the core experience, there are ways to help prevent that feeling of challenge from turning to one of angry frustration. While there are many ways to help design rewarding boss fights, today I'm going to take a look at one rather simple component.

This is Design Dive, and today we're looking at boss health bars.

A visible health bar not only provides useful information to the player during combat, allowing them to pace and plan the remainder of the fight around how much health the boss has remaining, but I argue it also can change the experience of the boss fight itself.

Let's look at a simple scenario. The player is facing a boss that takes twenty hits to bring down. Without a health bar, or other means of showing the player how much damage they're doing to the boss, the player's experience with the boss doesn't change up until that final hit when the boss goes down. If the player is struggling with the fight and doesn't know that the boss takes twenty hits, those hits can feel like an eternity, especially if the boss only has a few hits left and the player dies. With no frame of reference, and a sufficiently stubborn boss, it can feel like the player is just smacking away at a brick wall with absolutely no progress being made, and no idea of how much better they'd have to do to claim victory.

And that last point is particularly important. Without some means of conveying progress within the boss fight, the player doesn't have a good way to measure how much headway they're making with each attempt. It can lead to that "How many hits does this thing take?!" moment that, while potentially rewarding if the player is able to keep ahead in the fight, can be immensely frustrating if the player's best efforts don't even seem to be leaving a dent. It can lead to the player questioning their efforts, which if the player is on the right path, can hinder their progress even more.

Now let's add a health bar into the mix. With a visual means of seeing progress made each hit, that formerly inscrutable boss has a definitive end point. Even if the player isn't making much progress each attempt, say, only getting four or so hits in, they can at least see the damage they're dealing and get a sense of how much better they'd have to do. Furthermore, having that HP bar can turn the frustration of a close loss into an exhilarating, if still frustrating, experience. I know speaking from my personal experience with games like Dark Souls, a loss with the boss one hit away from defeat can be compelling in its own right and tends to make the final victory all the sweeter. Overall, having a health bar can provide the player with perspective on their progress in the fight, which in turn helps to alleviate frustration over a perceived lack of progress.

Furthermore, being able to see how close the boss is to defeat can actually change the experience of the fight for the player. Being low on health while not knowing how many more hits the boss has in them can be tense, but I think knowing the boss is also an inch from defeat sharpens the experience. From my experience, and from the experiences I've talked about and shared with others, having everything so visibly come down to the wire really turns up the pressure and can push the player into a more excited mental state while in turn having to maintain the level of skill that got them that far in the first place. For games with challenge as a main focus, the added pressure of a close fight can make the experience all the better.

Beyond just helping the player with information, the way the bosses HP bar is displayed can be a reward in its own right. Having a visual effect to help show how much damage the player does with a strike, such as changing part of the bar's color and having it slowly drain off, can be an additional positive point for the player, helping to reward a well placed or damaging hit. On the flip side, having the player smack at a boss only for the health bar to barely wobble can push the player into a more strained experience. Combining the two along with other design elements such as specific vulnerable points on the boss can make for a nicely rewarding experience. Watching the scratch damage turn into massive chunks of the bosses HP melting away after a good hit can add something extra to that moment of gameplay.

With all that being said, health bars are something of a short cut. It is harder, but certainly more rewarding, to find a way to incorporate that visual progress into the visual design of the boss itself. While it's not necessarily as clear as a simple HP bar, showing damage progress on the boss itself turns a 'gamey' UI element into an immersive part of the experience which, when done properly, can make the fight far more memorable. Taking a chunk off a boss's HP bar is cool. Taking a literal chunk out of a boss with an attack is even cooler.

Gohma, one of the bosses from The Legend of Zelda Wind Waker, makes for a fantastic example of displaying the boss's remaining HP via visual changes to the boss itself. During the first phase of the fight, the player's only means of damaging the boss is by dropping a large stone slab atop it. Each time, the boss pushes the slab back into place, but not before more cracks appear on the boss's otherwise impenetrable carapace. Not only is it a nicely immersive way of showing the player the progress they're making, it makes for nice build up to the boss entering the second phase of the fight, shattering the shell after a final ceiling drop.

On that note, many of the bosses in Wind Waker display progress in another manner, even without damage showing up in a HP bar or on the boss itself. The general formula for most bosses in that game has the player use an item to expose the boss's weak point, knocking the boss out of its normal combat routine and letting the player get some hits in. Once the player strikes the boss several times in that 'downed' state, the boss recoils and returns to their pattern. The often dramatic animation the boss goes through as they exit the downed state after taking enough damage really helps to sell the idea that the player's attacks are having an effect, even without any other visual means of measuring progress.

In fact, I'm under the slight suspicion that it's the act of knocking the boss out of their 'downed' state, and not the actual damage done while they're in that vulnerable state, that determines the pace of the boss fight. I am, admittedly, basing that off what I remember from a game I played years ago, but I'm toying with the idea of going back to Wind Waker to test that out. It would certainly be an interesting design choice, so if I do end up testing my theory, and if it has some truth to it, expect to see another post discussing what I learn.

Until then, thanks for reading, and I hope what I've covered here has proved helpful, or at the least interesting.
-Charles

Dueling Game v6

Hail Wanderers!

It lives!

As always, enjoy.

-Charles


Patch Notes:

Major balance changes to all classes.

Reworked the way the game resolves turns.

UI changes to prepare for multiple classes.

Play vs AI is DISABLED in this version

Clicking on action buttons is DISABLED in this version


Next Version:

Add the additional classes to the digital version of the game.

Rework start screen UI

Still Doing Things

Hail, Wanderers!

Just a short post (which is something of a running joke at this point maybe) to say that I'm still around and doing design-y things.

Been dealing with personal stuff, which isn't relevant to this post, but suffice it to say that I'm doing well, for what it's worth, and will be attempting to get some hours into the long stagnant projects.

Or new ones, which is just as likely honestly.

I have some new work done/in progress for the dueling game, but I have a new game that's in the works. Same sort of concept in that it'll be a small gameish thing that's really meant to explore a smaller scale combat system. Hopefully something more finished will come out of both of those.

Anyway, sorry for being away, but with a bit of luck I'll be more active in the future.

Regards,
Guardian Soul

Itch.io!

Hail Wanderers!

I feel like I say "just a quick update" far too often, and most of the time they're not that short anyway, but I truly do just have a quick update this morning.

I have an itch.io account now (found here), which may be a more convenient place to download and keep track of the new releases than going through dropbox. I'm still going to use the blog as the main source of updates, or at least that's the plan, so this is a new way to access the content, rather than a full change in how it's getting delivered.

And that, surprisingly, is it!

Have a good morning everyone,
Charles (Guardian Soul)

Dueling Game Tech Demo

Hail Wanderers!

The dungeon crawler is not dead, have no fear, but as I've been grappling with its combat system for a while now, I decided to take a break from it and do some smaller trials of combat systems. One of them may end up getting used for the dungeon crawler, or at the least the experience should help me refine the dungeon crawler's combat system.

In any case, the link to the first one can be found below. Both the Mac and PC versions are in the .zip folder, but I have no means of testing the Mac version so please be patient with any problems that arise with it.

https://www.dropbox.com/s/0k4bugvjquqh8z7/Tech%20Demo%2012-04-15%20v2.zip?dl=0

Feedback can go in the comments below, or to my email at CCS210@Aol.com

Enjoy!
Charles S (Guardian Soul)

Updated to v2 to fix a bug causing Rest to set Stamina to 100 instead of 20.

Update 9/23/2015

Hail Wanderers!

Shorter post today, with a longer set of posts to follow soon. I'm planning on getting the next inside the dungeon post up when I get the chance, but I'm also going to make a post explaining some of the revisions to the combat system (yes, it has changed again).

It's not a major change this time, sort of, I'm just trying a new structure for how the turns execute. I'll expand on this in said follow up post, but the short version is that I felt that the original one didn't cause enough interaction between the player and the enemies. Specifically, if there were multiple enemies on the field there was no reason for the player to attack enemies that were defending. Furthermore, it was hard to display all the information about what the enemies were going to be doing if they had more than one action stored in the turn, or in what order those actions were going to execute and why that mattered, if at all.

Anyway, this is a little visual I threw together that (hopefully) explains how the new system will work. I may come back and change the visual later so it's clearer (once I get a second pair of eyes on it and what not) but hopefully it'll do the job of explaining what the new turn system will be, if not all of the why.

Click to enlarge

Until next time!

Charles (Guardian Soul)

Inside the Dungeon: Engaging Combat

Hail Wanderers!

Today, as promised, I'm going to start going into a little more detail about my plans for the dungeon crawler. This series of posts will include some of my design philosphies, my intent for the game's final experience, and a bit of the logic behind the decisions I'm making. This will be a multi-part series, and I'll eventually collect them and put them under one page or something similar for more easy access, but for now expect more posts like this one in the standard blog feed.

To start, I'm going to be tackling the first goal of the game: changing and engaging combat scenarios. My plan here breaks down into three points: providing the player with more information each turn, changing the combat space each turn, and eliminating single-choice combat scenarios. I'll hit each point in turn, but first a short explanation of how the combat in game works.

The combat system shares many components with other turn based RPG systems of its kind (think games like Golden Sun, Etrian Odyssey, the Persona series, and similar titles for the basics). The player and enemies have health pools that are depleted by using offensive skills against them and also have defensive skills to mitigate or recover from that health loss. However, instead of combatants in the game having a basic attack command, all actions in combat are performed through skills. Each skill used consumes and generates resources from a global pool that all combatants share. I'm calling this shared resource mana for now, just for the sake of standard conventions, and it comes in earth, water, fire, and air mana. Again, just for the sake of simplicity in these early phases. I'll get deeper into what that shared pool means for combat below.

In addition to requiring resources from that global pool, each skill consumes a certain number of action points. Action points regenerate by a fixed amount each turn and can be carried over, up to a max value, if they are not all consumed in the turn. So long as the player, or enemy, has enough action points and resources in the global pool, they can queue as many skills as they like each turn. This allows the player (who only controls a single character) to better engage the multiple enemies (who have comparatively low action point pools).

Lastly, damage and defensive values from skills are broken down into physical and magical types. A defensive skill that blocks magic damage won't reduce the damage from a physical skill, and vice versa.

I'll write up a more readable version of the rules at a later point, but that should be enough for the purposes of this (already somewhat lengthy) post. On to the main topic!

Providing the Player Information
I want to make each skill choice in combat meaningful for the player, and to help with that I plan to provide the player with more detailed information not just about what each skill does, but its actual effect against the target it is being used on in that turn. I'm not sure how soon certain components of that information will be available to the player (enemy weaknesses, if those are eventually part of the combat system, etc) but at a base line the game will display how much damage each skill is predicted to deal to the target.

This will take into account any defensive skills the target is using that turn, and the intent is that the player will look at what type of damage the enemies are defending themselves against and plan accordingly to exploit the gaps in their defenses.

Similarly, the game will display what skill(s) the enemies will be using each turn, and display how much, and what type, of damage the skills are projected to deal to the player. Again, I'm still iterating on how much information about each skill will be displayed, but for now I'm leaning towards displaying a complete set of information for each skill (that being how much damage and of what type it will deal, what the skill is targeting, and how much of each global resource it is consuming and generating). The reason for displaying the skill type is simple enough, as it allows the player to properly match attack skills and defensive skills by their type, but the reason for displaying each skill's effect on the global resource pool is a little more elaborate. Because those resources are needed to use skills, both by the player and the enemies, it is important for the player to have a solid idea of what resources they will have available to them next turn. I'll explain in the next section the intent behind this and how it works.

The intent of displaying so much information to the player is that the player will be making counter plans to the enemies' actions in the turn they are taking those actions instead of reacting next turn. I'm currently balancing the game so that, if the player doesn't match damage types and pay attention to what skills the enemies are using, they will find combat to be very difficult, if not impossible. Yet if the player makes an effective counter plan to the skills the enemies have selected, they should take very little damage in combat. It's also intended to take some of the guesswork out of the equation ("that enemy's health bar looks small enough that this light attack should kill it, right?") and help the player cope with a more dynamic combat environment.

Which feeds pretty nicely into the second point...

Changing the Combat Space
In addition to simply selecting skills that are effective against what the enemies are going to do that turn, what skills the player and enemies can use is determined by what resources are available in the global resource pool that turn.

The purpose of the global resource pool is to prevent combat from always following the same skill rotations or set counter strategies. With it in place, what skills are available for both sides to use changes each turn as the state of the pool changes. Without that, it becomes a simple matter of matching defense types to enemy attacks and selecting the opposite type for player attacks.

Furthermore, because the pool is shared by both sides, this opens the door to more strategies for the player and also presents some additional concerns that they need to keep in mind for longer combat encounters. If the player knows what resources particularly dangerous enemy skills consume, they can use skills that deplete that resource type from the global pool, effectively preventing the enemies from using those skills. But at the same time, if the player over uses a certain resource type without taking care to replenish it with other skills, they may find themselves without enough resources to use key skills later in the encounter.

I'm not completely certain that this is the eventual form the system will take, but I think it's a solid starting point that captures at least the basics of the intended experience. I'm toying around with having skills that consume certain resource types also be of that type, and deal more or less damage against certain enemies based on those type match ups, but I'm leaning more towards having the state of the global resources be what has an impact on the skill's effectiveness instead. The player doesn't have any control over what enemies they are facing, so having skills of type A deal more damage to enemies of type B would place the player back in a more reactive position. On the other hand, if skills of type A deal more damage when resource type A reaches a certain level in the global pool, the player would be able to actively plan to reach or avoid that threshold, depending on what their skill setup is and what skills the enemies are using.

Eliminating Single-Choice Combat
This one is a little more nebulous, so first I'll explain what I mean by 'single-choice combat'. The term is in reference to combat scenarios where one choice can be easily taken to achieve victory, no matter what the opposing side tries to do. In many turn based RPGs, this is the 'attack' command, which can carry an on-level, or especially a slightly over-leveled party through most fights without too much of an issue. That or having the choice of which skill to use simply break down to which the enemy is most vulnerable to. It's not that those are bad systems, though I would argue that hitting 'attack' for every enemy in an often lengthy dungeon can get a little tedious, but that they don't engage the player beyond the initial formulation of the strategy. Outside of random events (a critical hit, or a miss, or the like) most of the time those strategies will work well enough for the player. Even if the strategy is a little more detailed, outside of boss battles or similar encounters where enemies are much more powerful the same basic strategy tends to apply to each encounter.

Part of the reason for this, I think, is that in these style of games the generic encounters are balanced so the player isn't constantly having to heal and recover after every fight. If basic mobs are proving to be a challenge for the player, it's usually a sign that the player isn't strong enough for the area yet. Some games get around this in part by fully healing the player between each fight and having every fight be a more challenging one (with the bosses being even more punishing) but enemies still follow a reasonably predictable pattern after a while, and once the player is strong enough fighting them becomes time consuming rather than challenging. I've seen some games get around that by having low level enemies either not fight the player or be one hit kills if they are engaged in the proper way (the Mana Khemia games, for example, allow the player to kill sufficiently weak enemies without even triggering a combat screen) but the dungeon crawler doesn't share a similar game space to those games.

Mana Khemia, for example, has a level exploration system where the player encounters monsters as blobs of various shapes and sizes. Weak monsters are cleared with a simple slash that doesn't even trigger combat, as stated above, while that same slash provides the player an advantage when they start combat with stronger monsters. It's a good system, in my opinion, as it keeps the player from having to slog through battles that they'll easily win, but in addition to encountering monsters the player is also exploring the area in real time and collecting resources. The dungeon crawler's dungeons will exist in the form of text and choices that the player can make, not in that real time space, so similar solutions don't apply as easily.

I intend to partially mitigate the issue by having the more dynamic combat system, as explained above, and thus requiring the player to make a new plan based on what the enemies are doing each turn in addition to the general strategy for taking them down, but that still leaves the issue of how to deal with enemies that aren't strong enough to provide the player a suitable challenge.

I could have the enemies scale to the player's level as the game goes on, but for now, my solution is to have the encounters themselves change as the player gets too strong for them. I'll get deeper into this when I'm talking about how the game world can be shaped by, and reacts to, the player, but for now I'm thinking that once the player reaches a point where they are over powered for an encounter, new options will come up that allow them to engage with the encounter in new ways.

For example, let's say there is a basic bandit ambush that the player has to deal with. On-level, the player simply fights the bandits and gets loot if they win. But once the player is strong enough that the bandits won't pose a threat, the bandits recognize this and instead of attacking, offer to lead the player back to their hideout. The player now has the option to take them up on the offer, which leads to an ambush against stronger bandits at the hideout that is a level appropriate challenge (and provides level appropriate loot!), the player can simply keep on their way if they don't feel like dealing with the encounter, or the player can start the old combat encounter if they so desire. It's a more complex system, and it may only be implemented for certain encounters, but I think it will make the game more interesting and prevent the player from having to do the same old easy combat yet another time for rewards that aren't worth the trouble.


Alright! That's all for that topic. Thank you for sticking around to read all of it, thank you for coming to at least see what's up if you didn't, and I hope these plans are getting some of you excited for the game when it comes out. Most of what I talked about today is actually implemented in the game already, so look forward to it when the next version rolls around (I'm not making any release date announcements, I've learned my lesson there).

Until next time!
-Charles (Guardian Soul)