Hi guys! I'm working on a 3D grid-based tactical turn-based game similar to old X-Coms and I've stumbled upon a problem that I'm not sure I know how to solve from a conceptual perspective.

Let's say I have a couple of units from two factions.
Each unit can fire a gun to the enemy units. Bullet fires from the muzzle of the gun and damages the first object it hits. Due to the accuracy of the unit, a bullet can hit not only the targeted unit but virtually any object and other unit (even friendly firing player's other units).

To make an AI controlling some of the units know what cells they can shoot what enemies from, I want to implement a Line of Fire mechanic. Line of Fire is also needed to show the player, where and what units he can shoot with his units.

The simplest approach to knowing if the unit can be targeted from the specified position by the specified unit is to use ray cast from the muzzle of the gun to the body parts of the target unit.

In the old X-Com games, this would perfectly work because all the sprites were static (and overall in the 2D pixelated mess you could never really say, what part of the body you've hit anyway)

But in my case, the problem is that both units are being animated, and their body parts and muzzles are constantly moving due to their animations. and if I'm getting the current position of body parts/muzzle, it will lead to inconsistent results, e.g. one time unit will have LoF to the enemy, and another time, in the same conditions, he will not have LoF due to the unit's idle animation, which moved muzzle to the side.

I thought about possible solutions for this problem:
1. use a fixed virtual point for the gun muzzle, make all ray casts with it, and then (I think that it could be very difficult) try to adjust the real animation so that it will be in line with the virtual muzzle point.
2. precalculate where the muzzle will be when the fire animation will play. Seems almost impossible for me, as I don't know how to handle animation blending and other stuff in this situation.

Both approaches seem valid to me, but yet I have a feeling that other similar games would solve this problem differently.

How would you solve this problem?

Having an idle animation is weird in a sense, none of us “dance” around when doing nothing.

If you don't want to go there: if I would be in a battle, and want to hit someone, I wouldn't am for a body part that moves around so I can miss it. I would aim for something that's always there no matter how the opponent dances around.

In other words, reduce the opponent to the area where there is always a body part.

You could replace the detailed tracing against individual body parts with a simple capsule / box for each unit. That's faster, more consistent, and probably good enough for RTS. (It was even good enough for FPS like Quake.) The capsule would not be affected from animation at all.

Alberth said:

Having an idle animation is weird in a sense, none of us “dance” around when doing nothing.

If you don't want to go there: if I would be in a battle, and want to hit someone, I wouldn't am for a body part that moves around so I can miss it. I would aim for something that's always there no matter how the opponent dances around.

In other words, reduce the opponent to the area where there is always a body part.

While I understand your point, I think that do not have any idle animation is kinda weird too. I don't think they must be intense, but something I would like my units to breathe at least.

Maybe I'll be fine with such “breathing” idle introducing little inconsistencies and they will not be really that visible.

But what about the muzzle? To calculate the line of fire, I need to know what position muzzle would be in when I will fire the enemy. I think it would be super cool if I could sync aiming animation with this “virtual position”.

JoeJ said:

You could replace the detailed tracing against individual body parts with a simple capsule / box for each unit. That's faster, more consistent, and probably good enough for RTS. (It was even good enough for FPS like Quake.) The capsule would not be affected from animation at all.

Hm, and if I will want to make a “damage body part” feature (which I really want to make), how could I do this with capsule approach? I think of zoning the capsule and making specific zones mean specific body parts

As with many gameplay implementations, you cheat. For XCom 2 at least (cause that's the one I worked on, and even worked on the projectiles) there are a few things that go on.

First though it's important to remember that XCom is not a simulation, so it's not important for bullet impacts to 100% match the results. A game like Phoenix Point is doing a simulation of the bullets which leads to many of the differences in those titles. So for an XCom-like, you only need to convey the impression of what's going on even if that's a bit of smoke a mirrors.

In the case of hits (misses are another matter entirely), there a few different things going on. The idle animations that you're concerned about are an issue, but the first cheat is that we'd only care about 1 bullet actually hitting the target. And that bullet would go towards the targets torso/center-of-mass without any spread. Other bullets (from the minigun or shotgun) could spread, but we also didn't care about them hitting the target. This was fairly reliable because the idles wouldn't be moving the torso very much. The animations of getting hit or dying might, but by that point you're only dealing with the bullets you don't care about hitting. Any impacts to the environment from those bullets were treated as gameplay irrelevant. They might drop decals or something, but they won't take chunks out from walls.

BlackDice said:
But what about the muzzle?

Since the shooting is all visual fluff, we just played the shooting animation and when it was time for the next bullet, we got the current muzzle location and started it from there. Generally the gun animations would only move the muzzle forward and back along the line of the gun barrel or very slightly around the same point. It was never enough for it to really matter to the overall visualization.

BlackDice said:
and if I will want to make a “damage body part” feature

You can either go the full simulation route that Phoenix Point does, which makes things like a bit easier since you deal strictly in collisions but give up many controls over the results. Or you can continue to cheat a bit. You should be able to figure out, roughly, where the bullet would end if it hit the part that you want it to hit. When it reaches that point (maybe a tad further) if it hasn't actually hit, you just pretend that it did. You remove the bullet and play any impact effects where you would have if it hit (or an approximation). It will probably look close enough to fool people. Remember that most of this only has to look right from specific cameras, at specific times, for a certain duration. It's likely that the difference between where it really stopped and where it should have hit. You may be able to move the camera where you want, slow down time and whatever else to help debug but your players won't. It may not even be noticeable scrubbing a video capture if it happens fast enough. Bullets are small and move fast.

Hope some of this helps!

MagForceSeven said:
As with many gameplay implementations, you cheat. For XCom 2 at least (cause that's the one I worked on, and even worked on the projectiles) there are a few things that go on.

Wow, I've never expected my answer to be answered by an actual XCom dev. Thank you so much for all the great play time you gifted us 🙂

Well, let's return to the subject of the topic)

MagForceSeven said:
You can either go the full simulation route that Phoenix Point does, which makes things like a bit easier since you deal strictly in collisions but give up many controls over the results.

Yeah, the so-called “ballistic” approach is the road I want to go, as I would like to also have a destructible environment, friendly fire in case of missed shots, etc. In Phoenix Point, they somehow still show us, if the enemy is generally hittable from this position or not (the alien's icon over the action bar can be gray or red, dependent on the fact that you can shoot him from this position with this weapon or not). So it seems that this calculation is most certainly some approximation too, after all)

MagForceSeven said:
When it reaches that point (maybe a tad further) if it hasn't actually hit, you just pretend that it did. You remove the bullet and play any impact effects where you would have if it hit (or an approximation). It will probably look close enough to fool people.

I think that this is a valid point, and most of the players really will not see these inconsistencies. I need to play a little with this approach.

Thank you, it was indeed helpful!

BlackDice said:
I would like to also have a destructible environment, friendly fire in case of missed shots

So I said missed shots were another matter. You'll notice that in XCom2, missed shots will cause environmental destruction (at least I would swear they do, it's been a while). No friendly fire, as that's going to feel bad for the players when you're not targeting an AoE sort of ability (but don't let me talk you out of anything you really really want for your game).

It can sort of be treated similar to hits, in as much as you go to some effort to preplan what happens so that the shots are just a “playback” and not directly causing gameplay changes. It's why some of the misses can seem so crazy, because the planning choose an unfortunately bad location as the miss target.