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.

Fig. 1: Actual, contemporary komusō monk (Image in the Public Domain, retrieved from Wikipedia) and re-imagining as one of the Tokui-ten Generals for the player to fight in NTT.

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:

Fig. 2: NTT Players' ABILITIES.

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.

Fig. 3: NTT Players' SKILLS, OPPORTUNITIES and LIMITATIONS.

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].

Fig. 4: Lantern interactable sprite, as used in-game. Two animations were made for this prop: Idle (shown here) and chain snapping.

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:

Fig. 5: Boss battle loop for the Samurai Boss battle in NTT.

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).

Fig. 6: Samurai Boss Battle sequence in-game. Notice how Enemies and Gaps are absent throughout the duration of the Boss Battle.

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).

Fig. 7: The elusive Foreshadowing Achievement icon. To earn, players need to knock down 15 or more Lanterns BEFORE meeting the Samurai Boss.

[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.

Ninja Tag Team: Slash n’ Dash - Intro to 3D rendered, illustrated character sprites

Hey everyone,



I hope everyone reading this does so safely at home, practicing social distancing and keeping themselves and their family healthy during this crazy COVID-19 outbreak.

Once again, a delayed post – Becoming, and experiencing life as a father, along with the lots and lots of work going on towards a new and exciting project (hopefully I’ll be able to share more details on that soon) means blogging inevitably falls by the wayside – I’ll try to improve on that!

In a few weeks, Ninja Tag Team: Slash n’ Dash will be 1 year old. 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 1-year anniversary. Hopefully these will be useful to fellow game developers, as I’m going to cover all kinds of things in retrospect, including some WIP pieces and tutorials. Don’t be shy to leave your thoughts in the comments section below.

With that said, let’s tackle our first subject, and the single thing that took the most time during NTT's development: Character sprites!

Background

Investing in a unique graphical style for your video game is one of the smartest things you can do, as the art style is a significant contributor to the overall experience and is the thing players will most likely remember about your game even long after they've moved on to other game worlds. Now I'm not saying the game's core gameplay and mechanics are not at the center of the overall experience (after all, great graphics cannot save an otherwise horrible game), however supporting those elements with attractive graphics increases the game's potential to maintain player interest and excitement for a longer period of time, let alone gives you a significant asset to market your game based on looks alone.

I've long regarded NTT's character sprites as a distinguishing feature of the game’s art style. The style was adopted while working on my 2016 entry for the Greek Secretariat for Information and Communication’s Game Art Contest (click to see). Back then, I took a great deal of inspiration from the Nendoroid series of plastic posable figures. Prior to having a clear picture of how everything would eventually turn out, I knew I wanted to make my next game's characters emulate that adorable, chibi look. When I set out to update the visuals of my first game Chip Rush, I eventually decided to ditch my initial plan of going for 16-bit SNES style graphics, and instead try out an illustrated look to go along with fluid, detailed animations. That being said, I am not much of a 2D artist to achieve a hand-drawn look. In fact, I have more confidence in my 3D skills, and I already had developed a rigged base mesh for a chibi-style 3D character for my GAC entry, so I decided to pursue the Donkey Kong Country way of rendering my 2D sprites using 3D tools. I’ll straight up put it out there: this is probably not the most efficient way to work in 2D, given all the wonderful animation tools out there - keep in mind, a game originally intended as an update to be re-released within a time frame of only a couple of months ended up taking two years - with the graphics taking out the majority of that time.

But enough with the rambling. I promise these next sections will remain focused on the basics of the process. I’ll be using the Enemy sprite for this tutorial (actually, the disguise power-up, in this case), as he’s wearing a mask, so it seems fitting.

Setting up your scene

For this tutorial, I’ll be using Blender (2.79), the open source 3D modelling tool. Now, I'm not claiming to be some Blender guru, but I do know my way around modeling, rendering and animating a stylized 3D character. I believe it is a good idea for any developer working solo to invest some hours in learning the software, as there's a huge repository of content and tutorials to help you achieve different styles and effects. It is through this community that I happened to stumble upon this amazing tutorial on Soft AO Cel Shading. What's great about this tutorial is that it pretty much gives you a way to emulate a hand-drawn style on your 3D renders, complete with nice occlusion effects – not to mention, you can download the actual files and experiment with the author’s setup until you are satisfied with the results.

A thing to note here: I decided not to model the face and facial expressions onto my model. The character’s eyes and mouth were instead layered on as a texture image sequence, where a different image texture was applied for each frame. Hence, I was able to pull off the various facial expressions using a series of anime-style hand-drawn eyes and mouths. There are several tutorials on the web to help you draw different expressions, so I won’t go into much detail on this. This technique helped me save much time, as doing the 3D face rig would be a daunting task on its own.

After you have modeled and animated your character, or asset, make sure to set up your background plane for the occlusion effects, and position your camera in the way that best suits your needs. Mine looks like this:

Fig. 1: Blender scene setup prior to rendering.

I decided to render all my sprites at a resolution of 2048x2048, so as to preserve as much of the detail as possible (as the Line squiggle node used in AO Cel shading tends to create thick lines and may cover up some thin objects and details you have worked on and want to show off – in my case, the sword, belt and sandals). For the actual rendering, I kept much of the settings presented in sharkigator’s tutorial intact. After rendering the 19 frames of the run animation (be patient, as it's gonna take some time depending on the sprite size and number of passes, which have to be repeated for each frame of animation – I had boss animations that lasted well over 60 frames, so you can imagine the time it took to render), the end result looks like this:

Fig. 2: '_cel' sprite animation.

Make sure to save all your frames in a folder (e.g. ‘Enemy_run_cel’) so they won’t be overwritten by the renders you'll be doing later!

By this point you’re pretty much emulating sharkigator’s tutorial, and ending up with some awesome-looking animation renders that look like hand-drawn sketches. However, it is highly likely that you’ll want some color on these sprites. At this point, sharkigator suggests doing a paint over, but once again, I am not much of an artist to achieve a good result by hand. As such, everything that follows in the next paragraphs is my own contribution.

Rendering

For the actual colors, I used standard Blender Render engine materials, which allow me to color the various assets with basic, colored materials. The main idea is to get the color and some soft shadows, as much of the effect we are going for will be achieved using Gimp and the '_cel' sprites. As mentioned earlier, you can use textures to add more detail to your characters (I used them for my character faces, as well as some pieces of apparel, like the Onna-bugeisha kimono) Feel free to experiment with your settings. I personally find using a low specular (Intensity: 0.01, Hardness: 10) material to achieve a matte look works best for the look I was going for.

To get the color render, you’ll want to go into your Node Editor window and switch off the ‘Use Nodes’ checkbox in ‘Compositing Nodes’. Next, you'll need to remove the AO Material from the 'Layer' tab in your 'Properties' view. You won't need to setup any lighting (unless you want to create specific effects, that is), as I've found that checking ‘Environment Lighting’ in ‘World Settings’ in the 'Properties' view works just fine. Proceed to render the entire animation again, which will give you this result:

Fig. 3: '_color' sprite animation.

Save these frames in a different folder (e.g. ‘Enemy_run_color’) for future use.

After you’re finished rendering you’ll want to duplicate the AO Material in the 'Materials' tab in 'Properties', then check ‘Transparency’, make sure 'Z Transparency' is enabled and turn ‘Alpha’ to zero. Next, expand ‘Shadow’ and check ‘Shadows only’ – this will enable you to render the sprite shadows on a transparent ground material (You'll need this, as we are going to add the shadows as an optional Layer later on). So your next set of frames to be saved in a different folder (‘Enemy_run_shadow’) will look like this:

Fig. 4: '_shadow' sprite animation (As GIF compresses the output, I've placed a single PNG frame on the right so you can get an idea of what the animation will *actually* look like).

Finally, it is useful to get a binary sprite mask. There are many ways to do a black-and-white render of your scene in Blender. I personally make sure to place the background plane on a different layer so I get a black-and-alpha mask so as not to have to do any extra work later. However you decide to go about this, you'll want your next set of animation sprites (again, to be saved in a new folder, e.g. ‘Enemy_run_mask’) to look like this:

Fig. 5: '_mask' sprite animation.

"Painting" your cel-shaded sprite

Now that you have all necessary sprite renders, it is time to do the inpainting of your original cel-shaded sprite. As previously mentioned, I used Gimp for this next part, though similar programs such as Photoshop will work just as well. Now bear in mind, this is once again a time-consuming process, especially if you are working with long sequences of animation, so streamlining your processes as much as possible by learning hotkeys and shortcuts to commands will save you lots of time. The following steps will describe working with a single sprite, but in reality, you’ll be wanting to load up the entire animation and work your way through each and every frame in succession.

Open Gimp and load your ‘_cel’ file. Drag and drop the corresponding ‘_color’ sprite on top of that, and change the Blend mode to ‘Grain merge’. After doing this for every frame of animation, you should have something that looks like this:

Fig. 6: '_gm' sprite animation.

I strongly advise saving these files again in a different folder (‘Enemy_run_gm’), especially if you’re working with many frames of animation, as these will be used as a basecoat for the next series of steps.

Now we have some color on our sprite! It doesn’t look bad either – but with some additional steps you can get even better results, and colors that really pop. Load up your '_gm' sprite in a different Gimp project. Drag the ‘_color’ sprite on top of it, and switch its blend mode to ‘Soft light’. Now drag the original '_cel' layer on top of the current layer stack, and switch the blending mode to ‘Darken only’. Finally, duplicate your '_color' layer and drag the new layer on top of the stack. Switch blending mode to ‘Screen’. This will give you the final NTT-look result, but feel free to experiment further if you need to. As a reference, the Figure below illustrates the various stages so you can see how each operation affects the end result:

Fig. 7: Successive steps to achieve final NTT sprite color.

Once again, you’ll want to save these frames in a different folder, ‘Enemy_run_final’. After processing each frame, your sprite will look like this:

Fig. 8: '_final' sprite animation.

Masking and shadows

Once you are happy with your final sprite, it's time to extract it from the background and add transparent shadows, so it can cast a shadow on the ground (if your character is grounded, that is). Open a fresh Gimp project and import your '_mask' frame. Drag n’ drop the corresponding '_final' frame on top of that, followed by the '_shadow' frame. Make sure the '_mask' frame is selected and use the ‘Select By Color Tool’. Click anywhere in the transparent area. Next click on the '_final' frame and press ‘delete’ on your keyboard to get rid of the background plane. Next you’ll want to do a ‘Select->Inverse’ to make sure your sprite mask area is selected. Go to the '_shadow' layer and hit ‘delete’ once again. This will leave you with the shadow part of the sprite only (you don’t need the colored character that comes with it anymore). Next, make sure the '_mask' layer is selected. Go to ‘Select->Grow’, type in 12 and hit ‘Enter’. Select the paintbrush and paint over the '_mask' layer with a black color. This will create the sprite outline.

Toggling visibility of the '_shadow' Layer will allow you to have both a shadowed, and non-shadowed sprite that you can save in different folders! NTT uses shadowed sprites for every character touching the ground, while airborne characters revert to a non-shadowed counterpart. You can see the final results in the image below:

Fig. 8 Final sprites (once again, a single frame is shown to emphasize the actual shadow effect).

Take note that your high-res, 2048x2048 sprites will likely suffer some quality drop due to scaling – mine were scaled at 186x186 each to be usable in mobile, so ensure you use the best quality option while scaling down so you preserve as much detail as possible. Use any tool you like to create your sprite sheet - I use this wonderful Gimp plugin.

After creating your spritesheets, and depending on your requirements, you might want to make the shadows on your shadowed sprite more visible. To do so, I copied and anchored the layer 8 times. Next break down the sprite sheet into its RGBA components (‘Colors->Components->Decompose’ and use ‘RGBA’ Color model). Click on the Alpha channel and enter ‘Color->Curves’. By dragging down the curve you can tweak the amount of shadow you want your character to cast. Re-compose the image through ‘Colors->Components->Compose’, again using ‘RGBA’ Color model and save the new spritesheet.

And that’s it! I hope this tutorial sheds some light on some of the techniques used to achieve the overall look of Ninja Tag Team: Slash n' Dash. It is definitely a lot of work and a time-consuming process, but I believe the end result is definitely worth the time I put into every single character. 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!

As I said, I plan to release more (hopefully interesting) articles on this blog. Future posts will probably not be as long, or as broad as this one; instead I’ll be going into greater depth on some really interesting things about the game world. Hopefully you'll be able to find something you can use in your own projects!

If you’re interested to see how every character sprite turned out, why not download Ninja Tag Team for free, and take a look?


Until next time!
K.C.