Hail, Wanderers!
I'd like to start this design dive with a story that, at first glance, seems rather unrelated to game design. At the store where I currently work, we have, as one may expect, public restrooms. They're of the one person variety, with a locking door and amenities for one occupant. The door's the important part here, as we have some rather consistent trouble with the lock on one of them.
Now, the lock is perfectly mechanically sound. It's of the variety that has a small button that you press in to lock the door, and works without any issue. Yet at least three or four times a week, if not more, we have a customer come to us and complain that the door lock isn't working. The lock does in fact work, and we've checked several times to ensure that everything is as it should be, but still people are under the belief, sometimes even after we assure them that everything is working properly, that the door isn't locking. Why?
Well, when you press in the button to lock this particular door, the button goes in all the way then comes back out. The button doesn't remain pressed in, there isn't a real change in resistance between pressing the button in when its locked versus when its unlocked, there isn't a click noise when the button locks, you get the idea. The door doesn't provide enough feedback to, if it's not too much of a stretch to say so, give the user the experience of properly locking the door. Again, the lock does work, it just fails to indicate that it's been locked in a convincing way, leading to many people believing that the door is broken.
So why the story about the door? Because games can suffer from the same issues. Even if a game is working properly, if the player isn't presented with feedback that everything is working, they can be quite convinced (and reasonably so!) that the game is broken. Imagine a button, just a generic UI element, that has zero forms of feedback when interacted with. No visual change when selected or pressed, no audio cue, no visual change when the option is available, etc. Unless the effect of pressing the button is immediately apparent, the player may not be convinced that the button has worked at all.
The problem, I think, is most common with systems that don't have that immediate form of feedback. A button to close or open a menu maybe doesn't need to provide as much feedback from the basic interaction, as the presence or absence of the menu it's supposed to control is perhaps feedback enough. On the other hand, a button to save the game, or to send a message to another player, or anything that lacks that immediate visual feedback from the action itself can be vulnerable to this phenomenon.
As another example, I remember my sister used to save Word documents (I forget which version of Word this was, sadly) several times, out of a fear that it didn't "save properly". I admit that I sometimes do this as well, or at least used to, and though I understood that the document was, in fact, being saved every time I hit the save button or used the keyboard command, there wasn't enough feedback to really convince me that my work had in fact been saved.
With all that in mind, what's to be done? Visual feedback is a good first step. If it's not intrusive to do so, adding a quick text blurb or image popup to confirm that the action went through properly can remedy the problem by itself. It doesn't have to be bombastic either, as a small visual cue near the button itself can suffice. Audio cues are also solid, if less reliable as they can be turned off, or the player may be unable to hear them. Audio can, however, help make the act of pressing a button more satisfying, as, say, the sound of coins clinking together can add a bit of flavor to a shop interface. The Fate game series by WildTangent, for example, had a rather satisfying inventory system, partially because of the sound effects that played whenever the player moved an item from one grid space to another (I remember the wet slap the fish made was particularly satisfying).
And on that note, expect a quick update to the Dueling Game in the coming days to add a bit of visual feedback to button presses, especially in regards to players prepping actions in combat.
Oh, and later on I'm going to write up a part 2 on this topic discussing how good visual and audio feedback can help teach players how to play the game.
Until next time!
Charles
Update - 5/7/17
The UI update to the Dueling Game is done.
Showing posts with label Design Dive. Show all posts
Showing posts with label Design Dive. Show all posts
Wednesday, May 3, 2017
Sunday, April 2, 2017
Design Dive: Balancing Dissimilar Skills
Hail, Wanderers!
Game balance is a massive subject, and one of major focus for almost any game. I'm not going to touch on balance from a conceptual standpoint in this design dive, but I'll certainly talk about parts of it in other weeks.
For now though, I want to offer a method I use for balancing skills or other actions that don't have easy means of comparison. Please note that what I'm covering is by no means the only, or even necessarily the best, way of going about balancing gameplay components. It's simply meant to be another tool to use to gain insight into the way different pieces of the game stack up against each other.
In this discussion, we're going to be mocking up a balance of a simple turn based strategy game. The Dueling Game that I've been working on would be a good example, but any sort of turn based RPG would also work. Alternatively, the method of comparison I'm going to present can also work for item stats, or whenever the strength of something with multiple values attached to it must be compared.
When skills have one value attached to them, we'll start with damage here, it's simple enough to compare them just by the numbers. We'll call our two skills Skill A and Skill B. With just a damage stat, the skills look like this:
Skill A - 10 Damage
Skill B - 5 Damage
With just the one stat to compare, it's easy to see that Skill A, with everything else being equal, is twice as powerful as Skill B. However, it's often the case that skills will have more than just the one value associated with them. So let's add in a resource cost for each skill.
Skill A - 10 Damage, 20 Cost
Skill B - 5 Damage, 8 Cost
With the two stats in play, it's harder to figure out exactly how the skills compare to each other. Because they only have the two values in play, however, we can figure out a ratio to compare the values. In this case, 10 Damage is equal to 20 resource Cost, so 1 Damage is equal to 2 resource Cost. With that in mind, we can see that 5 Damage would be equal to 10 resource Cost, which actually means that Skill B, with a cost of 8, is a little bit less expensive in the long run.
Note, however, that it's very important what skill is used to determine the ratio. If we used Skill B to find the ratio between Damage and Cost, we'd instead find that 1 Damage was equal to 1.6 Cost, which would change how the numbers looked for the rest of the skills. As such, picking an imbalanced skill to determine the ratio could lead to imbalances across the rest of the game. It's still a valuable, if simple tool, but just one to be cautious in using.
Now, let's add in a third resource. We'll give each skill a cooldown of a few turns.
Skill A - 10 Damage, 20 Cost, 3 Cooldown
Skill B - 5 Damage, 8 Cost, 5 Cooldown
With three values to balance, we would have a much harder time figuring out the ratios. We could still figure out that, using Skill A as our basis, 1 Damage is equal to 0.3 Cooldown and balance from there, but that doesn't really tell us the overall power of the skill.
For problems like this, such as the Dueling Game, which uses Damage, Stamina, and Balance as its three values for skills, I assign a point value to each component of the skill. In this case, we'll say that Damage is equal to 3 points, Cost is equal to 1, and Cooldown is equal to 2.
How the points are determined is something of a tricky matter, but I try and weight them based on how valuable I think each value is. For the Dueling Game, I weighted Damage the most, as applying damage is the main focus of the game and it's the only thing that can't be recovered, followed by Balance, and then Stamina as the lowest rated value as it's the easiest to regain. Also, I assign negative points to parts of the skill that draw resources from the player. So a skill that has a resource Cost will have the associated points deducted from the total, while one that, say, restores Resource on dealing damage would have the restored value factored in positively. The above point weights give us the following values for each skill:
Skill A - 30 Damage points, -20 Cost points, -6 Cooldown points (4 total)
Skill B - 15 Damage points, -8 Cost points, -10 Cooldown points (-3 total)
From that, we can see that Skill A is actually more powerful overall than Skill B. Furthermore, we can see that most of Skill B's negative points come from its cooldown, marking it as a good place to start examining how to rebalance the skill. That being said, it's not necessarily a bad thing to have some skills be more powerful than others, so it's good to see that the skills aren't too far away from each other in terms of total power.
Again, just like with using ratios, giving each part of a skill a point value can throw off the overall balance depending on how the points are assigned. To use an extreme example, assigning a point value of 10 in the above example would throw off the final value of each skill quite a bit. Also, this certainly isn't the only method that should be used, though it does provide a good starting point for additional balance changes or further looks into the skills.
Lastly, it's possible to assign point values to more complex components of a skill. Let's say a skill has a 25% chance of dealing x2 damage. It's hard to figure out just how much value that really brings to the skill. We can certainly calculate the total points for the bonus and non-boosted damage (using Skill B as the example):
Normal - 15 Damage points, -8 Cost points, -10 Cooldown points (-3 total)
Boosted - 30 Damage points, -8 Cost points, -10 Cooldown points (12 total)
That gives us an idea of how valuable a normal hit is versus a hit with the boost, but it doesn't give us an easy look into how much value the percent chance of bonus damage brings to the skill overall. However, we can add the possibility for bonus damage into the point total using a modified formula. If we say that damage that has a certain percent chance of happening has a point value equal to bonus damage points multiplied by the chance of that bonus damage happening (in this case 30 * .25) we could add that into the damage point total for the skill. Which gives us the following:
Skill B - 22.5 Damage points (15 base + 7.5 boosted), -8 Cost points, -10 Cooldown points (4.5 total)
It's not a perfect solution, but it does give a rough idea of how much value the 25% chance at double damage is bringing to the skill. With a little work, similar methods can be applied to most other types of skill components.
At the risk of endlessly repeating myself, assigning point values to pieces of a skill, item, or other gameplay component that need balance can help to get an idea of that component's total power and how much each piece of it impacts that overall power is a very useful tool. It does have its risks, as care must be taken when weighting each piece of the skill or item in question, and the method isn't necessarily applicable to all game types, but it is a good tool to keep in mind when looking at balance problems. I've used it in the major balance pass I made on the Dueling Game during the jump from version 5 to version 6, and it revealed quite a bit about the initial decisions I had made about the game's balance. Which is material enough for a blog post in and of itself, but that'll be for another week. I hope this was useful, or at the very least interesting, and to any designers reading this working on balance challenges, best of luck!
Until next time!
Charles
Game balance is a massive subject, and one of major focus for almost any game. I'm not going to touch on balance from a conceptual standpoint in this design dive, but I'll certainly talk about parts of it in other weeks.
For now though, I want to offer a method I use for balancing skills or other actions that don't have easy means of comparison. Please note that what I'm covering is by no means the only, or even necessarily the best, way of going about balancing gameplay components. It's simply meant to be another tool to use to gain insight into the way different pieces of the game stack up against each other.
In this discussion, we're going to be mocking up a balance of a simple turn based strategy game. The Dueling Game that I've been working on would be a good example, but any sort of turn based RPG would also work. Alternatively, the method of comparison I'm going to present can also work for item stats, or whenever the strength of something with multiple values attached to it must be compared.
When skills have one value attached to them, we'll start with damage here, it's simple enough to compare them just by the numbers. We'll call our two skills Skill A and Skill B. With just a damage stat, the skills look like this:
Skill A - 10 Damage
Skill B - 5 Damage
With just the one stat to compare, it's easy to see that Skill A, with everything else being equal, is twice as powerful as Skill B. However, it's often the case that skills will have more than just the one value associated with them. So let's add in a resource cost for each skill.
Skill A - 10 Damage, 20 Cost
Skill B - 5 Damage, 8 Cost
With the two stats in play, it's harder to figure out exactly how the skills compare to each other. Because they only have the two values in play, however, we can figure out a ratio to compare the values. In this case, 10 Damage is equal to 20 resource Cost, so 1 Damage is equal to 2 resource Cost. With that in mind, we can see that 5 Damage would be equal to 10 resource Cost, which actually means that Skill B, with a cost of 8, is a little bit less expensive in the long run.
Note, however, that it's very important what skill is used to determine the ratio. If we used Skill B to find the ratio between Damage and Cost, we'd instead find that 1 Damage was equal to 1.6 Cost, which would change how the numbers looked for the rest of the skills. As such, picking an imbalanced skill to determine the ratio could lead to imbalances across the rest of the game. It's still a valuable, if simple tool, but just one to be cautious in using.
Now, let's add in a third resource. We'll give each skill a cooldown of a few turns.
Skill A - 10 Damage, 20 Cost, 3 Cooldown
Skill B - 5 Damage, 8 Cost, 5 Cooldown
With three values to balance, we would have a much harder time figuring out the ratios. We could still figure out that, using Skill A as our basis, 1 Damage is equal to 0.3 Cooldown and balance from there, but that doesn't really tell us the overall power of the skill.
For problems like this, such as the Dueling Game, which uses Damage, Stamina, and Balance as its three values for skills, I assign a point value to each component of the skill. In this case, we'll say that Damage is equal to 3 points, Cost is equal to 1, and Cooldown is equal to 2.
How the points are determined is something of a tricky matter, but I try and weight them based on how valuable I think each value is. For the Dueling Game, I weighted Damage the most, as applying damage is the main focus of the game and it's the only thing that can't be recovered, followed by Balance, and then Stamina as the lowest rated value as it's the easiest to regain. Also, I assign negative points to parts of the skill that draw resources from the player. So a skill that has a resource Cost will have the associated points deducted from the total, while one that, say, restores Resource on dealing damage would have the restored value factored in positively. The above point weights give us the following values for each skill:
Skill A - 30 Damage points, -20 Cost points, -6 Cooldown points (4 total)
Skill B - 15 Damage points, -8 Cost points, -10 Cooldown points (-3 total)
From that, we can see that Skill A is actually more powerful overall than Skill B. Furthermore, we can see that most of Skill B's negative points come from its cooldown, marking it as a good place to start examining how to rebalance the skill. That being said, it's not necessarily a bad thing to have some skills be more powerful than others, so it's good to see that the skills aren't too far away from each other in terms of total power.
Again, just like with using ratios, giving each part of a skill a point value can throw off the overall balance depending on how the points are assigned. To use an extreme example, assigning a point value of 10 in the above example would throw off the final value of each skill quite a bit. Also, this certainly isn't the only method that should be used, though it does provide a good starting point for additional balance changes or further looks into the skills.
Lastly, it's possible to assign point values to more complex components of a skill. Let's say a skill has a 25% chance of dealing x2 damage. It's hard to figure out just how much value that really brings to the skill. We can certainly calculate the total points for the bonus and non-boosted damage (using Skill B as the example):
Normal - 15 Damage points, -8 Cost points, -10 Cooldown points (-3 total)
Boosted - 30 Damage points, -8 Cost points, -10 Cooldown points (12 total)
That gives us an idea of how valuable a normal hit is versus a hit with the boost, but it doesn't give us an easy look into how much value the percent chance of bonus damage brings to the skill overall. However, we can add the possibility for bonus damage into the point total using a modified formula. If we say that damage that has a certain percent chance of happening has a point value equal to bonus damage points multiplied by the chance of that bonus damage happening (in this case 30 * .25) we could add that into the damage point total for the skill. Which gives us the following:
Skill B - 22.5 Damage points (15 base + 7.5 boosted), -8 Cost points, -10 Cooldown points (4.5 total)
It's not a perfect solution, but it does give a rough idea of how much value the 25% chance at double damage is bringing to the skill. With a little work, similar methods can be applied to most other types of skill components.
At the risk of endlessly repeating myself, assigning point values to pieces of a skill, item, or other gameplay component that need balance can help to get an idea of that component's total power and how much each piece of it impacts that overall power is a very useful tool. It does have its risks, as care must be taken when weighting each piece of the skill or item in question, and the method isn't necessarily applicable to all game types, but it is a good tool to keep in mind when looking at balance problems. I've used it in the major balance pass I made on the Dueling Game during the jump from version 5 to version 6, and it revealed quite a bit about the initial decisions I had made about the game's balance. Which is material enough for a blog post in and of itself, but that'll be for another week. I hope this was useful, or at the very least interesting, and to any designers reading this working on balance challenges, best of luck!
Until next time!
Charles
Wednesday, March 22, 2017
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
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
Subscribe to:
Posts (Atom)