Hello there!

The Combat Prototype v.0.4.0 turns out to be way bigger than planned, what was meant to be just a feature update, implementing the ability to characters to enter in a Defensive Stance, i.e. Guard, became a refactoring on many systems, including the ones from the Physics Prototype, which shall get an update soon as well.

So, let's talk about how I'm approaching this combat system.

Kirby meets Megaman

From the start, since its conception, Kitchen Tales was designed to be a mix of the platform mechanics from Megaman X series, specifically Megaman X4 and X5, I also want to take the weapon swapping system, since in Kitchen Tales Buccerino will be rewarded with multiple kitchen utensils in his journey on becoming a Chef. But I wanted each weapon to have unique playstyles, just like each cuisine has its own way to approach gastronomy.

To achieve that, I drank in Kirby Super Star combat system, where each different Kirby power has its own traits, micro combos and special actions. So when summing everything up is like a mix of Megaman X 8 Zero's playstyle, where he can swap weapons and each has their own combos, playstyle, feats and traits.

I also wanted something that is not present in most of Megaman X games, but is on Kirby's and I love, which is the ability to enter in a guard stance, to block damage, while also becoming physically impaired, you can't move, jump, not even attack, when guarding.

But then, since each boss, and most enemies, will have weaknesses to certain weapons, I thought that there should be a way to break the enemies' guard by using the weapon that matches their weakness.

Objectifying Attacks

So now we start all the tech discussion to implement the Guard and Weakness features.

The approach is quite...straight forward actually, I approach it from an Object Oriented paradigm. The major idea is that each HitBox would carry a Hit object, as would the Guard class, when there is a hit confirmation, the HurtBox receives that Hit object and communicates it to classes interested in such information, one of them being the Guard class.

When the Guard class receives that data from the HurtBox, it checks if that Hit object matches its weakness Hit, if so, the guard is broken and the HurtBox is exposed to the damage, getting hurt and communicating the damage inflicted to interested classes, such as the Health class.

With that, each weapon, each enemy, each skill, can have a different Hit, as the Guard can as well. Designing an enemy then becomes more intuitive, all I have to do is to attach a Hit that represents its weakness, then attach the same Hit to a hit source. You can check this in the current iteration of the Combat Playground, where there is an enemy that enters in the Guard stance, PlayerHits don't hurt it, its weakness is the PlayerFireballHit which is attached to the FireBall that can be cast using the special action down, (left or right) and Z. This will break the enemy guard stance and inflict damage, also making it exposed for PlayerHits, which are the basic player attacks (Z). 

About the Refactoring

The major reason for refactoring was that I wanted to actually have a base scene for both the player and the non-player objects, previously the DummyEnemy and the Player scene used the same nodes, but they weren't based on the same scene, so every change made in one had to be duplicated in the other.

This led me to noticing that connecting signals using the editor could cause some...undesired or unexpected behaviours, namely losing the connections. So I created a more reliable, even tho very ad hoc, solution which is a class that is responsible to handle these connections automatically, I called them SignalConnectors, because that's what they do.

In the process of reworking these connections I created some generic classes, such as the CombatAction, which Attack and Guard inherits from, and also modified some methods names to favor consistency, for instance Jump was the only class with a cancel() method instead of a stop() as its sibling classes, so I threw this stop() method in the PlatformPhysics parent class, and then, children override it, making sure they all have the same interface.

This and other minor refactoring were made in order to improve the usability of this code base.

Download it, test it, feedback pls!

So, with that new iteration of the Combat Prototype, we are already capable of doing some amazing stuff, so, go ahead, download and test it, and please, leave your feedback here.

For bug reports, you can go to the issue tracker and leave an issue there!

And that's it, thank you for reading, keep developing and until the next time!