Has anyone experimented with a "blood loss" damage model?

[grailknighthero]

That somewhat what I mean, on the attack trigger on the item, does it return the agent for one of the params?  The on init item returns the agent for one of the params, check out the heraldry items.  What I am wondering is if the on attack trigger does the same.  I might mess around with the on attack trigger later, when I get time.

[Ron Losey]

The "on hit" function would HAVE to check who or what was getting hit.  Otherwise, it would not be able to flag the right target for the effect.  I don't know how much control you would have over this, however.  That would have to be tested.

[hayate666]

What if bleeding is formulated as a chance that is influenced by the amount of damage a unit receives? Part of body should be left out of the equation, because M&B already counts head shots as pretty much lethal and armour parts like helmets, gauntlets and boots reduce the damage for specific parts. Let's say that any hit doing more than 3-5(?) damage has a chance of starting 1-2 points bleeding damage every 5-10 seconds with a rising chance to close up according to the healing skill. Additional hits should be cumulative. Simulating heavy bleeding shouldn't be necessary, because if you take 30 damage in one blow you're usually going to be dead pretty soon anyway.

[Ron Losey]

I was really thinking that we could work on a 1 point damage from weapon equals about one point per minute bleeding damage (for every point over about 3 or 4, to discount shallow wounds where the bleeding would stop itself momentarily).  Depending on how someone figures out how to code it, we might be able to adjust that slightly with different weapons (say, sharp weapons 1 point for 1, non-sharp weapons somewhat less, maybe .7 or ..  That's a shot-in-the-dark estimate ... it might actually come out 1 point per 2 minutes, or whatever.

Then, adjust the weapon damage to follow ... current RCM numbers were set up to include the possibility of rapid debilitation from massive blood loss, so many of those numbers would have to be lowered.  That would have to be done manually, i.e. by me, and while I'm looking at a stack of medical texts and FBI police shooting reports.

This would result in a model where any moderate to severe injury would result in combat casualty within a few minutes.  That is, you take an arrow in the gut, and the time you can fight like that is not very long.  However, it would not necessarily result in going down immediately either ... especially a particularly tough person could probably still inflict some damage after taking such a wound, at least for a few seconds.

This would have nothing to do with head shots, really ... since a head wound that is not debilitating still bleeds, and that really does not change the probability of a head wound being immediately debilitating (either from direct weapon trauma to the brain or spine, concussion from indirect shock, or the massive pain and psychological shock of face and eye injuries.  Neck hits, which are prone to cause massive bleeding as well as nerve damage and trauma to airway, would respond about right to the data as well.

Since the damage inflicted is already a chance roll within a given parameter, a second probability roll is not really necessary.  More damage equals more bleeding, damage times set constant equals blood loss.

-----------------

But all of this is pure conjecture until somebody constructs an efficient way to collect weapon hit data without having to run health checks on every unit every second.  Otherwise, for programming reasons, this would create such a lag on the system that nothing but the most over-simplified mods could run.  (Repeated health checks might work in an arena, where battles were always less than 10 guys, or if used only on the player like KON_Air was doing, but not on 70 troops.)  So in a word, the exact formula is on hold until the code is in place ... and I can't do the code, that's for sure.  Not anything that will ever run that efficiently.  Somebody (or probably several people, before it's done) is going to have to have a real stroke of genius to think of a way to do that.

[Winter]

But all of this is pure conjecture until somebody constructs an efficient way to collect weapon hit data without having to run health checks on every unit every second.  Otherwise, for programming reasons, this would create such a lag on the system that nothing but the most over-simplified mods could run.  (Repeated health checks might work in an arena, where battles were always less than 10 guys, or if used only on the player like KON_Air was doing, but not on 70 troops.)  So in a word, the exact formula is on hold until the code is in place ... and I can't do the code, that's for sure.  Not anything that will ever run that efficiently.  Somebody (or probably several people, before it's done) is going to have to have a real stroke of genius to think of a way to do that.

The health checks would run every frame, not every second or even every hundredth of a second. And you have no idea if it would cause any slowdown at all. M&B runs about five or six triggers with every frame, and while they're not nearly as heavy-duty as this, there's no way of verifying if it would actually slow the game down at all without actually doing it. You can run a surprising amount of code in M&B before generating any appreciable slowdown.

Regards,
Winter

[Ron Losey]

Really?

You really mean to tell me that you think it could run a check and compare to last check on EVERY person and horse on the field EVERY frame without utterly grinding the system to a halt?

I ask, because the morale code that Fujiwara put on OnR recently runs a similar (but slightly less heavy-handed) check, only it runs once about every 30 seconds or so ... and it nearly stops my computer every time.  (Granted, my computer is low-spec, but I'm also running very minimal graphics options and don't normally have problems.)  Note that the rest of the script runs cleanly - only the check bogs the system.  (And tolerating it every 30 seconds is one thing, while a two-second delay for every second of game time would be something else.)  If that check is any indicator, then running something like that would be an utter killer on any group more than about ten troops on the field at a time.  This leads me to believe that any such check will have to be written in some very particular (but currently unspecified) way, in order to prevent this.

So my suspicion that this will cause lag is not purely supposition ... I have a good example as evidence of an impending problem.  While that is not proof of anything, it is certainly worthy of attention.

Of course, that was my question to begin with ... does anybody know specifically how to write something along these lines AND actually get away with it (i.e. without crashing anything or grinding the system to a halt)?  So that question still stands ... exactly how do we get away with it?  How can this code be slipped in along with all the other code in a way that doesn't create a massive lag or disrupt anything else?

I mean, I agree that, considering all the stuff running in M&B anyway, there theoretically SHOULD be a way to add one more check, code line, or script like this relatively cleanly.  But how, exactly?  (Mental note: NOT the way that morale check works.)

[Fisheye]

If it's a fixed linear thing like 1pt of weapon damage = 1/3 point of bleed per second, then no checks need to take place at all. You just need to keep track of how much bleed damage you applied to the victim and deduct that from the current lack of health to get weapon-inflicted damage.

[grailknighthero]

Ron, what I was talking about, was having this run alongside of formation scripts, which is something I am working on, and so I didn't want to work on this, for fear of it, alongside of my formations scripts, would clog the game down.

If you are only running this, then their probably won't be any performance hit at all.  Of course this depends on the machine and other things, like number of troops and models.

[Ron Losey]

Well, nothing is going to be "only" running one thing.  Any mod that uses this is going to have to do it alongside whatever other scripts are in place - formations, morale, plus any special functions of that mod.  And I'm certainly not proposing this as a stand-alone mod - the idea was for reworking the RCM, which is in turn used by more different mods than I can count.  So whatever we cook up, it's going to have to run alongside a bunch of random other stuff.

Fisheye:  How would you do that?  Can we test it and find out what it will do to performance?

(I mean, if anybody can come up with efficient ways to do absurd stuff, Fisheye can.)

[KON_Air]

If it's a fixed linear thing like 1pt of weapon damage = 1/3 point of bleed per second, then no checks need to take place at all. You just need to keep track of how much bleed damage you applied to the victim and deduct that from the current lack of health to get weapon-inflicted damage.

well,

every step/interval
-get agent current health
-get agent max health
--if wounded
-get max - current health
-div result to 3
-apply damage

vs

every step (doesn't even have to be every step, can match interval)
-get agent health
-get agnet max health
--if wounded (lt, agent health, max health)
--get damage from an index according to agent health
-mark agent with wound severity

regular interval
-get agent wound severity
-apply damage

[Fisheye]

Each time you want to apply bleed damage (e.g. if you want to apply it every 5 seconds, do this every 5 seconds):

- currhealth <-- agent current health
- totalbleed <-- get agent total bleeding damage applied from slot
- totaldamage <-- maxhealth - currhealth
- weapondamage <-- totaldamage - currentbleed
- this_round_bleed_damage <-- weapondamage / 3
- totalbleed <-- totalbleed + this_round_bleed_damage
- store totalbleed damage in agent slot
- inflict damage to agent (this_round_bleed_damage)

[Ron Losey]

If somebody cares to reformat that into Python, we can plug it in and test it (both for system lag and to tweak the numbers).

(You DON'T want me trying to turn that into Python ... it took me hours to rework the loot code for OnR back in .808, and it didn't have to be efficient.  I can probably adjust numbers once it is in place and I know what I'm looking for, but getting it in there in the first place....)

[Winter]

Each time you want to apply bleed damage (e.g. if you want to apply it every 5 seconds, do this every 5 seconds):

- currhealth <-- agent current health
- totalbleed <-- get agent total bleeding damage applied from slot
- totaldamage <-- maxhealth - currhealth
- weapondamage <-- totaldamage - currentbleed
- this_round_bleed_damage <-- weapondamage / 3
- totalbleed <-- totalbleed + this_round_bleed_damage
- store totalbleed damage in agent slot
- inflict damage to agent (this_round_bleed_damage)

Yeah, that'd work, and be easy as anything. Sound thinking.

Regards,
Winter

[Amarillo]

This is not exactly what you where asking for, but back when v0.8x was released I experimented with removing the awful pen-and-paper RPG abstraction called "hitpoints" from M&B.

The idea was to use the same method mentioned by Mr Air above to record the power of any hits taken, reset the hitpoints of the agent to keep it form dying the normal way, and then use an exponential function to calculate a damage value (to make one powerful hit better than several weak ones). This damage value would then be compared to an other value calculated from the agents strength and iron skin stats and various "effects" would be applied to the agent.

A typical effect would be reducing the weapons proficiency to make swings slower and lowering the skill and stat that affects running speed to simulate a wounded agent, and of course simply being knocked out (using agent_deliver_damage, meaning no xp for kills). The damage would be recorded so the next time the agent took a hit the chances of severe effects would go up. Also, the agents would slowly recover some stat-loss during the fight (25% perhaps) to simulate some sort of recovery after the initial shock. This way it is always some chance to kill/knockout in one hit, even with a crappy weapon, especially if the target has little fighting experience (low iron skin) and poor armor.

I never did any experiments with blood loss since I thought it would be frustrating for the player to slowly bleed out without being able to affect it, but in retrospect it was probably a mistake to not even test it before dismissing the idea. I also never did any large scale test, only 4 vs 4 arena fights, but compared to rendering a 3D environment these scripts will most likely not cause any major slowdowns.

This system had many limitations and it I never quite managed to get the right "feel" to it. It was always too much like ordinary hitpoints or it felt too random, but perhaps it would be possible to create something interesting from this if we worked together?

[Ron Losey]

I'm always open to suggestion, especially when it comes to how to code something.  (Because my knowledge of Python code is minimal, to say the least.)

I have no problem with the "hit point" concept - at its source is the simple idea that humans can take a limited degree of damage before being disabled.  And this is a valid point, which various medical texts and just about every study on military and police firearms wounding cases will support.

The problem with most RPG-type hit points is that a person can take way too much damage ("Ha, arrows in my head don't hurt me because I have HIT POINTS!"), and/or the weapons are poorly modeled (How come, in M&B Native, players can swing an axe the size of a stop sign at 90% of the speed they can use a pocketknife?).  That was how the "Realistic Combat Model" was born - correcting these obvious errors.

As for a bleeding model, I think it can be balanced out properly, such that minor wounds only produce minor bleeding (A couple of points over the course of the rest of the fight), while major ones would mean that troops could not keep fighting forever on their last couple of hit points (because blood loss would catch up to them in 30 or 40 seconds).  However, I did notice that the RCM had an issue here - many troops die too fast after being hit.  And that is not realistic... real people keep fighting for their lives even when critically wounded, at least until they go into shock from the injury.  That delay is the difference between hitting someone with a huge sword (which without armor will likely be immediately debilitating, as soon as that thing touches a nerve or tendon) and shooting them with a handgun (which might kill them eventually, but unless it hits brain or spine, odds are they're not going down for a couple of minutes).

Anyway, if you care to write that code (I think I asked earlier if somebody cared to turn that into Python code for me), please do.  We'll test it, and I would love to hear any other thoughts you might have.

Side note, if you are unfamiliar with the "Realistic Combat Model" (RCM) stats, try Onin-no-Ran.  (Most recent version for .90x - won't be ready for 1.0x for a couple of months at best.)  It's proof that hit-points can be made to work, provided you rescale the damage enough.