It’s difficult to provide a generalized statement but I can say I observe there exists common things in the kinds of games that I typically want to make. I find they typically involve understanding character (and object) animations in terms of animation clip transitions and the vocabulary common to fighting games. More about my hypothesis later.
For the uninitiated.
1. I-Frames (Invincible Frames): Periods during an action where a character cannot be hit (e.g., during a reversal move or wake-up).
2. Vulnerable: When a character can be hit normally.
3. Hitbox: The area where an attack can hit.
4. Hurtbox: The area where a character can be hit.
5. Active Frames: The frames when an attack can connect.
6. Startup: The frames before an attack becomes active.
7. Recovery: The frames after an attack ends before another action can begin.
8. Plus/Minus: Whether you have frame advantage (+ on block means you can act first; – on block means your opponent can act first).
Games can be thought of as game finite state machines (fsm) interactions between each other.
For conceptualizing interactions between game objects we can once again turn to fighting game lingo. This will help us think about combat systems.
Attacks and Defense
1. Neutral: The phase where neither player has an advantage; positioning and poking are key.
2. Whiff: When an attack misses entirely.
3. Punish: Attacking an opponent during their recovery frames after a whiff or blocked move.
4. Meaty: An attack timed to hit an opponent on the first vulnerable frame of their wake-up.
5. Anti-Air (AA): A move or action designed to counter jumping attacks.
6. Overhead: An attack that must be blocked standing.
7. Low: An attack that must be blocked crouching.
8. Throw Tech: Escaping a throw.
This models most interactions during any generalize combat system. Considering how real people talk about competitive fighting games can provide a good, socialized framework to build a generalized combat system from.
With this system of talk you can then communicate with animators that the character animations will need to consider which parts of the animation are meant to be invulnerable frame as just one example.
I believe a way to connect this with game engines on the market is to consider that the common they typically have game application runtime code and interactions with saved static assets for the game. Unreal has C++, Unity C#, and GoDot Godot script. There are ways of shipping resources in the form of assets with the game app. The trick is to find out what the most effective way of handling these interactions to keep the runtime code lean.
Being able to talk to animators and have essentially a checklist of requests will help keep an orderly project. Your mileage may vary, of course.
A good question to explore is what makes for appropriate static game assets to be used by game runtime code. I hypothesize the key is to enable creatives to express non overwhelming game systems that are more readily expressed as files on a file system. None overwhelming because no one wants to Shepard too many files.
I hope you take away a meditation on how competitive fighting game vocabulary can be used to model a generalized combat system. I think if you build your game interactions as game animations that are transitioning between states that map to how a person would talk about fighting games as an esport.