Dev Log #02 Combat Pt 1
At the beginning of this project back in 2022, I had a very different idea for this project. It was supposed to be a memory-matching game with some rouge-like elements. Shortly after the start of the project, I temporarily worked at a game studio for 2 months. The studio was making a beat-em-up game, which got me thinking: "Maybe I should make a card game with mechanics inspired by action games." I didn't quite figure out how to mesh that idea with my memory-matching game, and thus, I completely scratched the memory-matching concept and redesigned the whole combat system.
Question 1: How the hell can I implement "frame data" from fighting games in a turn-based game?
Well, I can't. But, there is an alternative. To discuss the alternative, first, we need to understand what "frame data" does. In a fighting game, an attack consists of startup frames, active frames, and recovery frames.
Img by Dash Fight, https://dashfight.com/news/understanding-frame-data-in-super-smash-bros-ultimate-161
What we need to focus on here are the startup frames and recovery frames. Startup frames determine how long it takes for your attack to become active. Recovery frames show how long it takes for the character to return from an attack pose to an idle pose. The character cannot do anything until it returns to the idle pose. Hitting an enemy causes the enemy to start the on-hit animation, and it would take x amount of frames for the enemy to return to its idle state.
We need a system that tells the player who will act first and also a way to confirm whether the next attack will trigger earlier before the enemy's action. We have seen "this system" in turn-based RPGs, like Final Fantasy. Players can apply a debuff to slow down the enemy, which is like to confirm your next action will start before your enemy recovers. In other games, players' attacks can even delay the enemy's turn.
Img by Giant Bomb, https://www.giantbomb.com/conditional-turn-based-battle/3015-2432/
My solution is slightly different. I call it the Initiative Priority System. The side with higher initiative goes first.
Initiative = card speed + speed mod
The card's speed value is like active frames; it shows how fast your action is. In my earliest prototype, a card had an enemy-delay mod and a self-delay mod, which simulated the enemy's on-hit recovery and the player's attack recovery. However, there was so much information on a card already, and having these two would only complicate the game further. Therefore, I combined these two values into a single value that I called speed mod.
Playing a card adds speed mod. Speed mod influences your initiative on the following turn. Note that the value does not stack (some cards bypass this rule with special passive effects). If you take a hit, then your speed mod decreases to 0.
The pointer above shows my initiative. The one below shows the enemy's initiative. In the above case, I have a +2 speed mod from my last attack. The last attack was a successful hit, which reduced the enemy's speed mod to 0. In a way, one can say that I have a +2 frame advantage. Even though the default speed of my enemy's action is faster than mine by 1, because of the speed mod advantage, this turn I can act first.
An important aspect of combat is to manage your speed mod so you can act first and interrupt your enemy's action. If the enemy gets interrupted, it loses that action and moves on to the next. If done correctly, you can constantly interrupt your foe and completely deny its turns!
However, there is a problem... Players can see the enemy's intent. If so, wouldn't it be too easy for players to constantly interrupt the enemy's action and never worry about getting hit? Well, that's where the shield mechanics come in~ Since this section is already getting too long, I will talk about shield mechanics in the next post. Stay tuned!