So, another pre-kickstarter devlog update.
I've been asked a couple of times here and in Reddit how am I tackling the combat in the game. Sometimes the comments came because people thought it looked good and sometimes because people thought it looks "floaty", or not deep enough. So there it goes.
As always, feedback from this forum would be greatly appreciated!
PS: I will combine the two first images in one so they are not so big).
EXPLAINING THE HEART OF HEART&SLASH COMBATHello there, Juan Raigada, Lead Developer, here.
This is going to be a more technical post than usual.
Since we released the first info on Heart&Slash, there has been many questions, mostly by fellow developers, curious as to how we are tackling the combat system in the game. Some of those comments were motivated by people who genuinely think it looks snappy and fluid, but a few of you were worried the combat might feel "floaty".
With this update I want to both give some insight into Heart&Slash design process and to quell those fears.
When I started developing Heart&Slash, one of the main concerns was to indeed avoid the floatiness a lot of Unity games use. Most times, this floatiness comes from using Unity's built in physic system, and a good solution is to write your own physics system.
However, for Heart&Slash this is overkill. We are a full 3D game with many objects on-screen, so we need to take full advantage of Unity's integrated physics. Ultimately we dealt with movement floatiness by hardcoding speed ramps for movement and jumping, thus creating a solid experience that is frame rate independent and allows us frame-by-frame control.
This, for example, is the curve that controls jump speed:
It's subtle, but you can see that instead letting a physics system take care of speed, we set the speed directly depending on how far into the jump the character is.
With movement taken care of, I decided to tackle combat. More specifically hit detection, cancelling, and frame protection for both damage and interruptibility. Since Heart&Slash will have a lot of content, it was crucial that this system was flexible (we, for example, need the ability to cancel attacks form one weapon into attacks from another weapon) yet allowed for precise control.
Thus, each attack in the game is it's own state, with an animation and a movement code (that allows for weapon-specific attack lock-on and several other neat features). Moreover, I was very careful to fully separate animation from logic.
This is how we define each state:
You will notice we have a list of attacks. That's because we treat every attack as a discrete collision check. We do this collision check for one frame (sometimes more) and there can be multiple checks per attack (right now some weapons do up to 6 checks. The more complex the attack pattern the more checks).
This is the typical set up. Notice the collision boxes corresponding to the Meat CLeaver attacks surrounding the player (those collision boxes are inactive unless we are in the frame check, but they showin the inspector). In this particular case we are extending those boxes farther from the character (they follow the animation slightly too closely now):
So basically, for those of you who wondered how we did the interactions player-enemies in the game, we have something in-between a discrete system and a full 3D game. We think it plays really well, although we are aware there's a LOT of polishing and balance to do.
Most specifically, although weapons are snappy, sometimes the animations are not (this is due to me having to do all code, art and animations in the game up to last month. We got a coder, but no artist yet). This is what sometimes makes videos feel a little bit "floaty". That and some weapons not being yet tweaked at all.
This dual approach also means that in case we get extra funding, we can port it to lower spec machines and platforms just by taking away some of the physics/movement functionality and replacing it with simpler code.
I hope this post is of use for people who have expressed an interest on the combat in this game.