Kalia and the Charged Attack (and Why Input Design is Important!)

Hello all! Today I felt like sharing a little insight into a recent implementation in KatFS and how it can be a simple example of interaction/input design in your games. "But what's the need for this input design?" - you might ask - "just make the button do the thing when you press it!". Well, that's certainly what you should do when you're getting started and your game is still just an experiment or prototype, but as it evolves into a finished product, if you want to ensure it will play well you will have to apply at least some form of interaction and input design to it.

Okay, so what is this about then? Well, giving a lecture in interaction design is far beyond the scope of a Kalia devlog (I had to take an entire Master's Program to figure it out!), but the best way to start is to just swallow your pride, test your game (or get others to test it) and take note of anything that feels clunky or any friction in how the game is played. Dropped inputs (even if just apparent), inputs that don't feel responsive, inputs that feel too responsive, inputs that lack the impact they should have, any situation where the game doesn't behave like you'd expect it to. It helps to have a background as a player of games to develop a sense for this stuff. And what then? Then you figure out how to smooth these rough edges out! Sometimes all that's needed is a tweak on some variables or a few extra condition checks, but other times you might end up realizing that your entire paradigm around a specific input or set of inputs is not appropriate, and having to modify it for the sake of improving the gameplay experience.

With that all out of the way, onto my practical example! So, in KatFS the protagonist (Kalia) is able to shoot firebolts as a basic ranged attack. This has been done by aiming with the mouse and pressing the left mouse button to fire. One button press equals one firebolt, and there's no automatic fire (well, there was for a while until this new mechanic came into place). Recently, a new alternative to the standard firebolt has been implemented - hold down the fire button, and Kalia will charge a heavy firebolt, which goes off in a small explosion upon hitting a target. You can see the finalized mechanic in the GIF below:

Looks alright doesn't it? Seems a simple enough implementation, but there were many decisions and changes made to ensure that the end result felt good to use while also not undermining the standard firebolt. So let's get through the process:

Initially, Kalia would shoot a firebolt the moment the fire button was pressed. Not the exact moment actually, a very brief delay would be applied as a placeholder for a missing firing animation, but for all intents and purposes, firebolts were tied to the moment the button was pressed down. So how do I get her to charge a shot when you hold down the button instead? The first thing we'd need is to know not only when the button was pressed, but also when it was released, which should be simple enough. Just start a timer when the button is pressed and check it when it gets released, right? Except the standard firebolt is still getting fired when the button is pressed down, meaning Kalia will fire a "warning shot" every time the player wants to charge a shot! This doesn't respect the player's intention at all and is a good example of bad input design.

Okay, how do we fix it then? We need to make the distinction between a tap for firebolt and hold for charged firebolt. Unfortunately we still lack the tech to see the future, so it is only possible to know after the button has been released. However, this actually works in our favor, since we could now unify the standard and charged firebolt input: start the charge timer when the button is pressed, and when it gets released, check if it has been held for long enough to completely charge a heavy shot or not. Problem fixed, right?

Well, the input paradigm we have now seems to work perfectly, but do you see anything awkward with the GIF above? Notice how even though Kalia is rapid firing standard firebolts initially, the charging indicators (aiming gizmo, particles, and sound effects if you could hear them) appear to "blink" even though the player's intention is not to charge their shots. This is a case where the mechanics are fine, but the feedback isn't. Everything is working exactly as intended, but it still feels off. How do we improve on it then? Check the final result again:

It's hard to see it through the GIF, but the result is very simple really: only activate the charging indicators once the charging progress has passed a certain threshold! Currently, it takes 2 seconds to charge a heavy firebolt, and the indicators will only appear at 25% charging progress, meaning that they won't appear for the initial half-second of the charge. This is long enough to not get triggered when the player is just tapping the button, but short enough to still feel responsive (and should become even more so when firing animations get added!).

To wrap it up however, let's check an adjacent scenario:

What Kalia is doing here is a dodge roll immediately followed up by a charged shot. The dodge roll has two phases: the main one where Kalia is actively rolling and moving and is immune to certain attacks, and a brief one at the end where she recovers from the roll and is vulnerable. During this recovery phase, Kalia cannot perform any actions such as moving or attacking, which is done via an initial check for all input actions. There was a problem however - while testing the charged attack, I noticed that I would often think I should be charging an attack when I wasn't. The problem was that this recovery phase after dodging and other actions would block the charge from starting even if the button remained held down after it was over. While there are situations where Kalia shouldn't be able to initiate a charge, this one didn't feel right, so I reworked the rule for that particular input. The player can now initiate a charge during a recovery, however they won't shoot any firebolts if the button is released while Kalia is still recovering.

That about wraps it up for this devlog! I hope you learned something, maybe you have a similar issue with inputs in your own project and this ramble of mine provided some inspiration on how to solve it. Or maybe it just makes you appreciate good input design more. Now back to developing Kalia's adventure, and thanks for your interest and attention!