Πέμπτη 30 Απριλίου 2020

Ninja Tag Team: Slash n' Dash - Designing Boss Battles



Hi everyone! (Wow, I actually did it! back-to-back posting! Yay!)



First things first, let's get the formalities out of the way: In a few weeks, Ninja Tag Team: Slash n’ Dash will celebrate its one-year anniversary. To honor the occasion, I’ve decided to do a series of articles on the game’s development process, a sort of a long overdue ‘making-of’, which will culminate with a postmortem I intend to upload on the day of the game’s anniversary. Hopefully these will be useful to fellow game developers, as I’m going to cover all kinds of things, including some WIP pieces and tutorials. Once again, don’t hesitate to leave your thoughts in the comments section below.

This post aims to shed some light on one of the most important aspects of NTT: Boss Battles!

Despite playing a central role in the game’s narrative, and definitely being a highlight of the game, Bosses were one of the latest additions made to the actual game (as I have mentioned previously, the plan was to originally re-release Chip Rush with updated graphics and a broader, more attractive theme). Eventually the idea of Boss Battles was introduced after realizing that the game would benefit from more variety in order to differentiate between the 6 levels, apart from the visuals and music. Originally, there was one concrete idea for a Boss Battle: the Samurai. The entire concept of having to master the airborne switch-and-attack to beat this Boss by bringing down a heavy object (a cast iron lantern, in this case) on his head, was an out-of-nowhere idea that just came up when I decided to start thinking about Boss Battles, and ended up translating exactly like I had intended in the final product. However, I needed five more “great ideas”, let alone a means to squeeze out every ounce of gameplay potential I could from the game's simplistic control scheme - after all, Boss Battles should stand out from the rest of the game!

This post will deal with how these ideas eventually came to be, and the steps I took to approach Boss Battle design in NTT. Hopefully, this will help you, as much as other developers' posts have helped me get to this point (I'll be referencing those posts in the text below).

The narrative part


It is highly recommended to have a concrete plan for each Boss, one that perfectly aligns with the game’s narrative. Especially for narrative-driven games, there needs to be a reason for why the Boss occupies a specific Level, why it is there and what motivates the player to fight it. NTT is more simplistic in this regard: there is an overarching plot centered around the ages-long rivalry between the Kyokusei and Tokui-ten Ninja Clans, but no in-game narrative elements are present, as the game is pretty much an endless runner at heart.

However, some degree of thought needed to go into each character to make the Boss Battles compelling, despite the game's simplistic plot. At this stage of conceptualization, it is always a good idea to do lots and lots of research, especially if you are basing your game on actual events and settings. For me, having the game set in Feudal Japan provided a rich cultural lore, and many amazing opportunities to find out more about the Japanese' rich medieval culture, as well as the various classes of warriors operating during these times. I admit I had never heard of onna-bugeisha, or komusō monks before, but soon, this knowledge would be put to use toward staging the centerpieces of the game.

The Komusō was a particularly interesting example in this regard: Not only does the outfit look cool, and makes for a memorable character to fight, but the actual story behind the komusō monks ended up dictating the actual gameplay of the event. Komusō were practitioners of Suizen, a Zen practice dedicated to attaining enlightenment by blowing notes on their bamboo flutes (known as ichi on jo butsu). This eventually made its way into the actual game, where the musical notes are actual projectiles, and contact of such a projectile with the player gives the Komusō Boss character a significant advantage in battle. Furthermore, the komusō disguise allowed many operatives to travel the land unhindered, which meant many komusō were either ninja assassins in disguise, or spies. This also fits well with the NTT narrative, as it is intentionally never mentioned in-game whether this character truly is a monk or a disguised ninja spy.

Designing challenges around well-established mechanics


I once read this amazing post by former Insomniac and Activision game designer Mike Stout. According to the article, a key factor to designing successful Boss Battles is to treat them as a means for the player to demonstrate how far he/she has come regarding mastery of the skills needed to play the game. Hence, “a boss battle is both a test of the player's abilities and a chance for the player to feel like he has mastered the skills you've taught him so far.”

In order to design a successful Boss Battle, I find it useful to break down the game mechanics to their simplest form. Eventually, you need to be able to identify:

1) what the player is able to do in your game
2) how the player masters the controls of your game
3) all the different ways the player can use your mechanics to overcome obstacles or traverse the environment
4) means by which the player might gain an unfair advantage by abusing the mechanics

It helps to design a brief tutorial of your game mechanics, in a similar manner as is described in this great Metroidvania design post by industry veteran Kynan Pearson. Going through your intended game mechanics, it helps to compile a list of all the player's ABILITIES (possibly using visual aides), which can help you further down the road. My own list for NTT looked something like this:

The next step is to realize which of your mechanics are versatile, and can lead to more than one uses. These constitute the player's SKILLS. This will allow you to create new gameplay OPPORTUNITIES and include LIMITATIONS, so that they can be implemented in a way that will lead to challenging situations for the player to face. For instance, a key SKILL that players need to master in order to make their progression easier includes a particular combination of the JUMP, SWITCH and ATTACK ABILITIES, performed in sequence and during a very short interval: this constitutes an AIRBORNE ATTACK.

As mentioned before, in the case of the Samurai, the AIRBORNE ATTACK is prominently featured. The player should be able to demonstrate mastery of this skill in order to defeat the boss. In order to force the player to use this skill, the following LIMITATIONS and OPPORTUNITIES are put in place:

1) The players are not able to normally ATTACK the Boss. If the players attempt a direct attack on the Boss, they will be killed. This renders the Boss virtually indestructible [LIMITATION].

2) The players need to understand that they cannot beat the Boss while grounded. Hence we need to visually let them know that the Ground Plane is dominated by the Boss. This is done via the back-and-forth movement of the Boss, forcing the player to practice JUMP at regular intervals and stay airborne [LIMITATION].

3) As there are no Enemies to fight, the game needs to provide a means for the player to figure out they need to hurt the Boss while airborne. Interactive elements are added to the scene for this purpose. This interactive element should be unique to this level, so that the player figures out it has something to do with the particularities of this Boss Battle [OPPORTUNITY].

NOTE: in this particular case, lanterns are present throughout the level, appearing randomly even before the Boss Battle is commenced. This is in contrast to e.g. the cannons in the Wakō Boss Battle, or the carts in the Brigand Boss Battle. The reason for this is two-fold: On the one hand, it’s not going to be directly obvious to the player, that they can use the lanterns to defeat the boss. The carts in the Brigand level, or the Cannons in the Wakō level are quite ‘out there’ and players can make the connection more easily. Also, these objects serve no other purpose than to finish off the Boss, so including them earlier as a means of exploration may hinder the player’s progress (wasting energy on something pointless is never fun). On the other hand, the lanterns in this Level are not as obvious. Hence, exploration is encouraged: Lanterns falling on top of Enemies actually kill them! Furthermore, they eventually create a new gameplay challenge all on their own, being the center of the ‘Foreshadowing achievement’ (read further below).

The Boss Battle Loop hence becomes clear: Players need to JUMP, in order to avoid the Boss or be killed, instantly. They can time their JUMP so that the character comes into contact with the lantern, at which point they should rapidly SWITCH and ATTACK, to take the lantern down. If timed right, the Boss will be passing directly under the falling lantern, and suffer a hit.

4) To make the battle more challenging, lanterns are spawned sporadically and randomly, otherwise the player might finish off the Boss in an anticlimactic fashion [LIMITATION].

Now you should have enough information to actually design the Boss Battle Loop, in a similar fashion to the Figure below:

Testing


Now that you have your mechanics implemented, you need to actually build the Boss Battle as a self-contained experience. This means you’ll want to implement easy ways to switch between Normal and Boss Battle modes at will. Not only did this immensely help during testing, but it enabled me to actually setup BOSS Mode, where the player is allowed to practice on the Boss once they unlock the battle. Each Boss Battle in NTT follows a specific set of rules:

1) Once a Boss Battle is commenced, the game no longer spawns regular Enemies. The focus of the player should be on figuring out how to beat the Boss. Also, it would make the game extremely difficult (I briefly considered adding an ‘Impossible’ difficulty setting, but eventually decided it wasn’t worth the extra time it would take to make Enemies obey the rules of the Boss Battle, and not interfere with the Loop flow).

2) Once a Boss Battle is commenced, the game should no longer spawn Gap floor tiles for the player to JUMP over. In addition, any Gaps already spawned and ahead of the player are automatically turned into Ground tiles (beyond the border of the screen and out of the player's sight). This not only makes these Battles feasible (having to JUMP gaps AND fight the Boss would make for a huge challenge), but also serves a practical purpose, as many Bosses do not work well with Gaps (e.g. you wouldn’t want the Samurai to hover over the Gaps, neither Jump over them, as giving the Boss that ability to occupy airspace, would break the Boss Battle Loop). If the Boss Battle Loop requires the player to JUMP over a Gap (e.g. Wakō and Brigand), the game should have clear rules when to spawn that Gap for the player to JUMP over (e.g. after scoring a hit on the Boss, so as to reset the loop).

Now that you can test, it is important to be able to answer the following questions:

· Were you (being a game master and all) able to successfully overcome the challenge?
· Would an average player (evidently, not a game master, like yourself) overcome the challenge?
· Did the challenge feel right? Did anything stand out as out of order, too unfair, extremely difficult or too easy?
· Is the player properly limited by the LIMITATIONS in place?
· Was the player able to get away with not using the SKILL, and if so, did it feel right/rewarding to do so?
· Did the SKILL feel good when you used it to score a hit?
· Would players get confused about how to use the SKILL? How would you make the use of the SKILL more obvious for them?

As you answer the questions above, you can start thinking about how to improve anything that needs improvement. For instance, it is OK if Bosses do not feel 'evenly matched', e.g. if players are beating one Boss more quickly than another, as long as the experience feels rewarding (besides, some SKILLS are easier to pull off than others, and proper design will elevate the player's mastery of that SKILL). If the Boss Battle doesn’t feel right, rewarding or fun, try to fix the example or tune the mechanics to ‘fix’ the experience, until it works. If nothing feels right, is awkward, or downright awful, then either fix it, or consider going back to the drawing board, and possibly even scratch the idea entirely (It took at least three discarded ideas to finally get the Ninja Boss Battle in NTT to work with the mechanics in place, and actually feel right).

[OPTIONAL] Going the extra mile


When you are happy with the result, there is one additional option to consider:

· Can I design an achievement around this loop?

Many games reward players with achievements, and Bosses are usually at the center of the achievement-hunting experience. Of course, earning an achievement for beating the Boss is mandatory, should you wish to go that way. But being more imaginative, and creating an additional challenge for the player to overcome, one that builds around the concept of mastering the mechanics needed, or actually beating the Boss while accomplishing something spectacular, will make the whole experience all the more rewarding.

NTT follows this approach by directly addressing the questions asked earlier, for instance, what the player can get away with, and to what extent can they turn a disadvantage into an advantage. This is most prominently shown during the Komusō Boss battle. The premise of this Boss Battle loop is simple: The players avoid the Komusō notes that slow them down, and strike before the Boss has the chance to do so. However, I quickly found out through testing that I could avoid being hit, and simultaneously score a hit despite being slowed down. This I could do only if I pulled of a very specific JUMP, SWITCH and ATTACK combination, executed in a very particular (and extremely short) time interval. While this may seem like it breaks the Loop, the specificity and reflexes needed to pull this off are so precise, that it actually feels more rewarding to score a hit like this, rather than following the normal route! As such, I actually tweaked this to encourage players to try it out, actually designing an achievement ("Bullet Time") to be rewarded to the players, who could successfully take out the Komusō by striking him ONLY using this particular method.

I believe it is a good idea to capitalize on such gameplay opportunities, creating new ways for players to discover new routes to play the game, and feel rewarded for doing so. Dedicated players are probably going to find ways to break the game rules to their advantage at some point. Rewarding them for doing so is probably one of the greatest discoveries the player can make about the game, and possibly one of the most rewarding aspects of them playing your game. This can also add replayability value to the game, as well as allow the players to pursue different goals when selecting a level to play.

Conclusion


In this article, I went over how I eventually implemented all the Boss Battles in the game. I emphasized on the opportunities to capitalize on narrative elements to design the Boss Battle Loop. Afterwards, I explained how I approached each battle design, and linked it to the game’s mechanics so as to create new gameplay opportunities and challenges, that were rigorously tested to eventually ship with the final product.

Hopefully, by reading this you’ll get an idea on how to do Boss Battles in your own game. I am definitely not claiming this to be the ideal, or only way to approach this, but it has proven to be a very helpful strategy to implement exciting content for Ninja Tag Team, in a surprisingly short amount of time. I hope they may deliver similar results for your projects.

If you guys have any questions, I encourage you to leave them in the comments! You can also follow Ninja Tag Team and/or Gortyn Code on Facebook and leave your comments there!

Curious to see how each Boss Battle turned out? Why not download Ninja Tag Team for free and find out?


Cheers!
K.C.

Δεν υπάρχουν σχόλια:

Δημοσίευση σχολίου