We have started a basic prototype to test our desgined combat system. The game is a 3D isometric RPG developed with Godot 4, and my first proposal was to add a collision box to weapons to detect when enemies were hit. It sorts of works, but I delegated the work on the second programmer and he proposed to discard collisions as primary way and simply use a backend to determine what targets were in range and inflict damage to them. That was my idea, years ago, but right now I think the collision way is better, specially after finding some Godot limitations related to determining animation state when using an AnimationTree. Is there any other approach for this, or should I enforce the collision based solution?

Collisions feel more “natural”, and would be my choice for an action game. For an isometric RPG, I'm not sure. It means that the usefulness of a weapon depends on the animation for that weapon. It means that you risk being unable to hit a given opponent at all if the weapon is too short or the opponent is too short. It means that you can't really playtest or balance the game until you have all of the animations in place.

I think that both approaches have their advantages and disadvantages, and that, more to the point, which is better for your combat mechanics depends on those mechanics, as well as how you intend to use the tools in question.

You say that you're making a 3D isometric RPG. I gather, then, that you're likely to have a relatively-distant player-perspective, and I'm guessing, at least, that you're unlikely to intend that collisions determine anything as fine-grained as which body-parts are hit.

So, in that case, I would imagine that aside from the specifics of your collision engine and whatever tools your programmer intends to use for their implementation, there's likely to be little between the two approaches.

Speaking in generalities, I would expect your programmer's approach to be simpler and more reliable, and your approach to be more-easily flexible.

If you used some crapware engine to power your rpg, then at least try to rely as less on it as possible.

a light breeze said:
It means that the usefulness of a weapon depends on the animation for that weapon.

I'd handle this the other way around: Aim the weapon by some AI, player input, or whatever you want for your game to work as intended.
Then try to match the aimed weapon with animation, but still use the original orientation, not the approximation animation gives.
This causes some visual error which may be noticeable or not, but that's less of a problem than broken mechanics. Visual error could be reduced with IK.

rogerdv said:
Is there any other approach for this, or should I enforce the collision based solution?

Try both. : )

rogerdv said:
add a collision box to weapons to detect when enemies were hit.

Why not the other way round? Express the rules as abstract tables and formulas giving the chance of different results for various combinations of attacker, defender, weapon etc. and then, after deciding the attack result, adjust the animation of the weapon swing to show the various types of hit, miss, critical hit, fumble and the like.