Bone based damage system (feature vote and debate)

This idea would be a major change, so it's best I ask before I start coding. Nexuiz and Xonotic have been stuck with the ancient ways of calculating player damage, based entirely on the bounding box and not on how the body works. I've been thinking of changing that, and adding limb-based damage to Xonotic. This means that damage would no longer be calculated by a simple "bounding box was hit" check, but by using bones on the animation skeleton to deal the appropriate damage for each body part. To explain better, here's a comparison with the current system.

Current way: If a bullet hits the player's bounding box it deals a fixed amount of X damage. If a splash damage projectile hits the player, it deals X damage modified by distance between the player and where the explosion took place (the closer you are the more damage you take).

New way: Hitting the bounding box would not deal any damage by itself (just apply force). Whenever a projectile hits the player, the code runs a loop through all skeleton bones of the player model, detecting how close each one is to the impact point. Bones cvared as "damage bones" (explained below) are fetched, and the damage of each bone applied to the player. This is the same system that my Damage Effects use (particles sticking to player limbs after they are shot).

The cvar system would work as follows: You register each bone by its name in a numbered list of cvars. A bone's cvar would contain the damage modifier, specifying how much of the dealt damage is translated by that bone. 0.5 would mean half, 2 would mean twice. Bones which aren't registered deal no damage (so parts like the fingers are counted out). Example:

g_bonedamage 1 "use bone damage system over the old system"
g_bonedamage_1_name arm.L "name of the armature bone"
g_bonedamage_1_offset 0.5 "how much of the damage this bone translates"
g_bonedamage_2_name arm.R "name of the armature bone"
g_bonedamage_2_offset 0.5 "how much of the damage this bone translates"
g_bonedamage_3_name torso "name of the armature bone"
g_bonedamage_3_offset 1 "how much of the damage this bone translates"
g_bonedamage_4_name head "name of the armature bone"
g_bonedamage_4_offset 2 "how much of the damage this bone translates"
...

The cvars would be read in a loop, so you can add as many as you want using this architecture. What the example above would mean is: The arms translate 0.5 of the damage, the torso translates 1 (unmodified) and the head translates 2 times the damage. For splash damage, the closer each bone is to the impact point the more damage it translates. For hitscan weapons (since they don't have a radius) they probably translate the damage of the single closest bone at its full intensity.

This would add some very fun and realistic damage to Xonotic, and get us out of the simple "hit the player's bounding box and deal fixed damage" functionality. For added fun, the player's animation at the moment of impact would also influence the position of damage points (since they are the bones). However, it would have several downsides, such as:

- All player models must have the same bone names to work properly. eg: If a model would name the right arm arm_R instead of arm.R, that model would be broken for gameplay. I believe this is ok with current Xonotic models, and likely custom models as well if they use the same skeleton.

- The player model you select will cause you to be damaged differently. This again shouldn't make a noticeable difference with the default models, but custom models would need to be checked closely. eg: If your custom model has his head oriented down by default (like a monk or something), a rocket exploding on the top of the bounding box will deal less damage than on an ordinary player.

This does not affect custom models as long as they use the default skeleton (that Ignis and all others do). The rest should be fine... just a matter of getting used to and balancing. But because of how unsafe this would be, I doubt the feature will get defaulted (even if I'd like that). Still, I'm asking what exactly you prefer I do (see the pool). Should this be default, should it be a mutator, or should I not even bother to code it? I like the idea, and really believe Xonotic needs area-based damage at least to make headshots more harmful for all weapons. The bone system would be the most realistic and advanced way to go, but at the same time could mess with the gameplay if a model uses a custom skeleton that isn't checked.

I think this is a great idea.

I think making it a mutator is the best idea. This would just give players and server admins the choice to do what they want. (If it just workes fine it could be made default in sp.)

Just one thing, how is this going to work with forced models? If I choose a small model, but my enemy forces (in his game) the model to a bigger model. What would happen then?

But anyway I'm really interested in this

Just one thing, how is this going to work with forced models? If I choose a small model, but my enemy forces (in his game) the model to a bigger model. What would happen then?

Yeah, I forgot that with CSQC models you can now override them locally. In this case I can't think of a solution. Most logical and ok way would be to calculate damage based on the server-side skeleton (since that's how everyone else sees you and if you don't the client could use this to become invincible). But that would still be incorrect... though at the same time most acceptable.

I never liked the idea for body part specific damage in a fast paced shooter. The game is so fast paced that it really serves no purpose, it only introduces randomness to fire fights. I wouldn't say Xonotic is behind the times with it's lack of this feature.

This could be a fun mutator but for the default gameplay it's like putting the whole balance upside-down (and its already complex). Consider this. Hit scan will get affected a lot, but - say - splash from a rocket exploded in front of you will likely be affected far less. So that's in fact changing balance numbers in a somewhat convoluted way. I think best way forward is to think what you want to obtain in a gameplay and then find ways to do so. Whereas fun ideas are best put into mutators

So if I'm understanding this correctly, you're basically creating bounding boxes for each bone (i.e., not using the player mesh). Would this be prone to holes (and overlaps)? I guess I'm unclear on how it's actually receiving the damage, as animation bones have no physical area.

I'm in favor of this, even by default if you find a way to make it so that damage calculations work the same for any model.... Don't think the model you select should really have any effects on gameplay!

So if I'm understanding this correctly, you're basically creating bounding boxes for each bone (i.e., not using the player mesh). Would this be prone to holes (and overlaps)? I guess I'm unclear on how it's actually receiving the damage, as animation bones have no physical area.

No, the bones don't have bounding boxes. Basically, I know the origin where the damage took place. Next I loop through all skeletal bones of the player model, and read each bone's origin. Using a vlen, I then get the distance between each bone and the point of impact. Then use this to calculate if the bone was in range of the blast, and deal the appropriate damage if any it so be dealt.

So there's no bbox scanning... I only loop and scan the origins, then tell distance based on that. Note that projectiles themselves still explode when they hit the bounding box as usual... just that damage isn't calculated for that any more.

I'm in favor of this, even by default if you find a way to make it so that damage calculations work the same for any model.... Don't think the model you select should really have any effects on gameplay!

Sadly I don't see one. If I use skeletal bones to calculate damage, I'm using the player's animation skeleton, which depends on model. But on the good side, almost no model should be using a custom skeleton. So with the default models in Xonotic at least, there should be no difference.

How do you determine that something "hit the player"? You say in your first post that only then do you scan each bone.

And what do you do about crouching which brings bones closer to eachother and therefore makes the player more vulnerable to splash damage?

How do you determine that something "hit the player"? You say in your first post that only then do you scan each bone.

And what do you do about crouching which brings bones closer to eachother and therefore makes the player more vulnerable to splash damage?

The bounding box collision is still used to detect a player was hit, so we know what bones to check. The code would be written (or mutator hooked) from void Damage() which always runs for each entity that takes damage. This would work exactly like my damage effects which IIRC are in qcsrc\client\damage.qc if anyone wants to see the code.

And the crouching thing would be intentional. Because each body part is in another position, you would take damage over the current animation. I believe this makes things even more awesome.

For example, if someone is shooting you straight into the back while you're standing still: You might take more damage because your arms are positioned more closely to your side. But if you shoot someone from the same spot and orientation while they're firing, arms take less damage because you brought them more in front. If you were shooting the player in the face instead, the effect would be the opposite (arms would be closer to the blast spot with that animation).

Only thing I don't agree with is the idea that Xonotic is too fast-paced for such a feature. A good damage system doesn't go to waste because movement and firing are fast. No matter how fast, one will probably notice when a shot aimed toward the head takes more damage and one fired at the legs takes less.

On another note, I might also add bone culling. So the closest bone takes more damage, then the further the rest are the lower they are rated (as an addition to existing range checking). This will make it so that being shot in the right arm from the right side will cause your torso to take less damage, because your arm absorbed the shot and covered your torso.

The box thing has always annoyed me as GoldenEye 007 (which did not use hit boxes) was the first FPS I really got into, however I don't really like the idea of specific limb based damage in an arena shooter either. I think if the damage system stayed pretty much the same as it is now (only awarding extra damage for headshots), but had the requirement that you ACTUALLY HIT THE PLAYER MODEL we'd have one really kick ass set up. Only issue I see is that models aren't identical, but if the skeletons in them is what your actually hitting then it wouldn't really be an issue. Hit scan and precision weapons would become more challenging to use as well, but I don't think that would become a balance issue if the shots were given some sort of expanded damage area around them.

For example, if someone is shooting you straight into the back while you're standing still: You might take more damage because your arms are positioned more closely to your side. But if you shoot someone from the same spot and orientation while they're firing, arms take less damage because you brought them more in front. If you were shooting the player in the face instead, the effect would be the opposite (arms would be closer to the blast spot with that animation).

This would ruin the game, but I think you already figured out a solution to that:

On another note, I might also add bone culling. So the closest bone takes more damage, then the further the rest are the lower they are rated (as an addition to existing range checking). This will make it so that being shot in the right arm from the right side will cause your torso to take less damage, because your arm absorbed the shot and covered your torso.

Just set it up so that the closest bone takes ALL of the damage in the event of a nex shot or similar weapon that crosses through you. As for splash damage, just make it to where the closest bone takes most of the damage while others take less. You will still need to figure out how to make hitting multiple targets in a straight line with the nex possible while only one bone per target absorbs damage.

No, the bones don't have bounding boxes. Basically, I know the origin where the damage took place. Next I loop through all skeletal bones of the player model, and read each bone's origin. Using a vlen, I then get the distance between each bone and the point of impact. Then use this to calculate if the bone was in range of the blast, and deal the appropriate damage if any it so be dealt.

And you also sponsor new cpus for the server hosters?

The box thing has always annoyed me as GoldenEye 007 (which did not use hit boxes) was the first FPS I really got into, however I don't really like the idea of specific limb based damage in an arena shooter either. I think if the damage system stayed pretty much the same as it is now (only awarding extra damage for headshots), but had the requirement that you ACTUALLY HIT THE PLAYER MODEL we'd have one really kick ass set up. Only issue I see is that models aren't identical, but if the skeletons in them is what your actually hitting then it wouldn't really be an issue. Hit scan and precision weapons would become more challenging to use as well, but I don't think that would become a balance issue if the shots were given some sort of expanded damage area around them.

I agree with this. Although it's usually not noticeable, shots explode when you hit the bounding box, not the model. So you can't eg: Have a grenade thrown between the player's legs. My separate idea for fixing this was attempting to set all player models to SOLID_BSP someday. But without major changes to the engines, this might be a crazy thing to do. I still wonder if anyone tried it, and how much it decreased the performance.

Just set it up so that the closest bone takes ALL of the damage in the event of a nex shot or similar weapon that crosses through you. As for splash damage, just make it to where the closest bone takes most of the damage while others take less. You will still need to figure out how to make hitting multiple targets in a straight line with the nex possible while only one bone per target absorbs damage.

That's exactly what I planned. Hitscan shots will only damage the closest bone fully (they have no radius either way). Splash damage is the one that damages multiple bones, and what I was talking about with the bone culling. So if all goes well, that's exactly what will happen.

And you also sponsor new cpus for the server hosters?

The loop isn't that bad. Like I said, damage effects already use it (as well as my sandbox) with no noticeable decrease in performance. A way to avoid looping the bones you don't need would be good however.

I am against it, even as mutator, for the following reasons:

• Animations are currently not played on the server. Making the server actually play them incurs quite a CPU load cost.
  
• I highly doubt something like this can be done as a mutator without large changes to damage code that will slow it down in general.
  
• Even if we did solve these issues: the server doesn't even KNOW how the model looks on the client! Client might, for example, replace the model by another one (forcemodel), and will later also run its own animation code independent from server code.
  
• This feature would prevent us from ever moving animation decisions from the server to the client, which we REALLY want to do (e.g. for ragdolls, and also blending for aimimg/crouching+shooting/etc.). And the fact that it blocks these important changes makes it absolutely not an option.
  

Right... it's official then. I was unsure if animations are also available for the server to know all the time. And given the forcemodels issue, it makes this even less possible. I wouldn't want it getting in the way of other features especially ragdolls.

I might go with my other idea then, which is to cvar damage points against the player's origin. So for instance, to define damage for the right arm, you'd use '2 0 4' (a bit to the right and a bit more upward) instead a skeletal bone. This would be completely model-independent and models would not influence gameplay. You also wouldn't be looping through a large number of bones but read some fixed origins instead. If I go down this path, I likely won't code it as a mutator, but an (optional) feature in the damage code. Does this sound like an ok alternative?

Only thing I don't agree with is the idea that Xonotic is too fast-paced for such a feature. A good damage system doesn't go to waste because movement and firing are fast. No matter how fast, one will probably notice when a shot aimed toward the head takes more damage and one fired at the legs takes less.

I think you're overestimating the accuracy of twitch aim. I doesn't come down to aiming at specific body parts, so a 1v1 would come down to luck more than aim. And as someone else stated, splash damage weapons would be far more effective than hit scan because they could hit the sweet spot without even intentionally aiming at it. In a twitch shooter that would be a game changer. I think the weapon balance is damn good now, and something like this would mean back to the drawing boards with the balance, if the same balance could even be achieved again.

This would make absolutely no sense in Xonotic, it is way, WAY too fast paced for something like this. It would only add complexity and randomness, especially since most weapons have splash damage. There is a difference between "depth" and "complexity", think about it and imagine how confusing this feature would be for new players as well as experienced ones. New players would have no clue what is going on, it would be impossible to understand without explaining to them what it does technically. Experienced players would be "aware" of the feature without being able to take advantage of it because it doesn't fit Xonotic gameplay at all, in the end people would still just fire at a the general direction of a target (ie: the player model). So what is the point? I understand it's probably a fun project for a coder, but I can't imagine this being fun with Xonotic gameplay.

I can only imagine this feature to be interesting for huge vehicles with destroyable parts or something like that, but definitely not for tiny players running around at 60-70 km/h.

This would make absolutely no sense in Xonotic, it is way, WAY too fast paced for something like this. It would only add complexity and randomness, especially since most weapons have splash damage. There is a difference between "depth" and "complexity", think about it and imagine how confusing this feature would be for new players as well as experienced ones. New players would have no clue what is going on, it would be impossible to understand without explaining to them what it does technically. Experienced players would be "aware" of the feature without being able to take advantage of it because it doesn't fit Xonotic gameplay at all, in the end people would still just fire at a the general direction of a target (ie: the player model). So what is the point? I understand it's probably a fun project for a coder, but I can't imagine this being fun with Xonotic gameplay.

I can only imagine this feature to be interesting for huge vehicles with destroyable parts or something like that, but definitely not for tiny players running around at 60-70 km/h.

Fast paced doesn't mean features that add more detail go to waste. Even if Xonotic had faster movement, an effect like this could still be noticeable very often. In multiplayer matches, I sometimes shoot people in the head with the UZI (a reflex I have from shooters with head damage support) and often manage to hit the place I want. UT is fast-paced too (with the exception you don't bunny-hop around the map at super-speeds) and I still feel when shooting the right spot deals more damage. That's why I aim for the head there, then remember there's no need to in Xonotic and get confused

New players and experienced players alike would likely not find a difference that gets in their way. You still shoot to cause damage as usual. It can be easily summed up to "limbs take less damage and head more", which in most modern shooters is something everyone expects and assumes exists (aiming for the head is common sense). It's not that much of a complex feature either... coding it is but the functionality is quite simple, and common in a lot of shooters. Xonotic is probably one of the rare cases still stuck with no damage zones and the old hit box detection.

BTW, something I realized on the matter of Xonotic being fast-paced: This depends a lot on the map and gametype you're running. If you're playing CTF or ONS on a huge open map, then yes, you're running around at some super speeds (even so this feature would make sense). But if you play DM on small closed maps like I usually do, you barely catch much speed no matter how you jump. Maybe DM players tend to see movement as slower for this reason, while CTF players used to laser-jumping in large spaces are more likely to think it's all about super-speeds. But on a map like Basement in Nexuiz, you don't become too fast, and it's easy to aim at specific body parts during some moments.

Micrea, why don't you make a demo for us that we can download and play and then we can decide what it's like and how suitable it is for general use. I think the concept is interesting, but we shouldn't judge it until we can see it in action. Also, if you could recommend some maps that it would work well on, like Basement, that would be good. This could end up as a mutator that would work well on certain maps.

div0 has spoken

Micrea, why don't you make a demo for us that we can download and play and then we can decide what it's like and how suitable it is for general use. I think the concept is interesting, but we shouldn't judge it until we can see it in action. Also, if you could recommend some maps that it would work well on, like Basement, that would be good. This could end up as a mutator that would work well on certain maps.

A "demo" would be as complicated to code as the real deal.

Micrea, why don't you make a demo for us that we can download and play and then we can decide what it's like and how suitable it is for general use. I think the concept is interesting, but we shouldn't judge it until we can see it in action. Also, if you could recommend some maps that it would work well on, like Basement, that would be good. This could end up as a mutator that would work well on certain maps.

A "demo" would be as complicated to code as the real deal.

I'm planning to code the whole feature when I get to it... again taking the risk of losing my code if it's not accepted or wait an year for the merge request A demo isn't really possible in these circumstances IMO... either code the feature or not. Samual said it's ok as a mutator, although I believe that using this implementation (and not the bone one) it could be part of the damage code. I'm waiting for more input on this.

BTW, something I realized on the matter of Xonotic being fast-paced: This depends a lot on the map and gametype you're running. If you're playing CTF or ONS on a huge open map, then yes, you're running around at some super speeds (even so this feature would make sense). But if you play DM on small closed maps like I usually do, you barely catch much speed no matter how you jump. Maybe DM players tend to see movement as slower for this reason, while CTF players used to laser-jumping in large spaces are more likely to think it's all about super-speeds. But on a map like Basement in Nexuiz, you don't become too fast, and it's easy to aim at specific body parts during some moments.

Dude, watch Nifrek in a 1v1, he's the fastest player I've seen. He's flying around the maps at full speed half the time like a ctf player, and I'm talking about the smallest maps in the game. But even if Nifrek's speeds were unattainable to most players, any experienced 1v1 player will move very fast because they know how and because they know the maps. This game is extremely fast paced, even in small maps.

Dude, watch Nifrek in a 1v1, he's the fastest player I've seen. He's flying around the maps at full speed half the time like a ctf player, and I'm talking about the smallest maps in the game. But even if Nifrek's speeds were unattainable to most players, any experienced 1v1 player will move very fast because they know how and because they know the maps. This game is extremely fast paced, even in small maps.

It depends on how open those maps are, and the walls they have as well as obstacles. Evilspace is small too, but you might get fast there because it's open. Basement on the other hand... difficult.

But that might be possible if you're a very experienced player. This does not apply to everyone, and I haven't even tried getting fast on those maps (except sometimes when no one's around and all I do is roam). On Red Planet for instance, I get a bit fast when bunny-hop roaming, but not too much. Then whenever I run into someone and there's a battle, I have to stop or slow down, otherwise (at best) I leave the area before I get to frag. So maybe this is only the case for a few players that learned how, but certainly not the majority.