Modeling variable readiness/alert levels

[Dimitris]

So, one of the persistent "complains" that we hear about CMANO/CMO is that platform reaction times, especially ships & land units against air/missile attack, are too short, too "perfect".

Usually the discussion begins from "there is no way this ship can reliably shoot down an incoming ASM attack of [XYZ] missiles, this is unrealistic" and after a lot of back-and-forth where we show the math, the systems interaction etc., we finally come down to "well, in RL ships just don't react that fast even against a limited attack, look at real-world examples like HMS Sheffield, USS Stark, USS Vincennes, INS Hanit or USS Mason".

This is a fair point. What do these and similar incidents have in common? Usually the hardware worked as expected; the weak link was human reaction time, either due to low alert state (surprise attack) or due to delayed decision making, either due to poor communication/coordination between people on the same ship or across different ships (Sheffield & Stark suffered gravely because of this) or hesitation because of a crowded environment and restrictive rules of engagement.

The "simple fix" would be to just multiply all existing OODA-loop values by a certain factor. This would indeed make most ships (and land SAMs) much more susceptible to surprise attacks, as "historically" demonstrated. However, over-massaging the data & models to fit historical data points has its own dangers (we commented on this in the past: https://www.warfaresims.com/?p=2793 ). You ask the AWO on any modern AAW ship (in fact even non-AAW hulls have decent air defenses these days, by necessity) and he'll tell you that when the crew is on their toes, and assuming the hardware works, they can indeed stop a massive attack (even a surprise one) reliably. Merely inflating the OODA times would preclude such an ability.

(This, BTW, also touches on a recent discussion on this forum about subs being supposedly "too easy to detect". ASW warfare is another case where the ship's alert state is critical to early detection & prosecution of contacts; and historically, surprise is one of the biggest cards that a sub holds).

So then, how do we show crews being "on their toes" and, more importantly, not being so?

The Global Thunder MBX, a few years back, had an interesting example on ship steaming conditions:
Condition I: General quarters, all weapons and sensors manned, fatigue rate builds fairly quickly.
Condition II: relaxed GQ, personnel rest near battle stations, slower rate of fatigue accumulation.
Condition III: All sensors manned, some personnel near weapons stations, takes about 5 minutes to achieve full GQ status. Fatigue neutral.
Condition IV: Selected sensors manned, weapons typically unmanned, about 15 minutes to full GQ. Allows fatigue dissipation.

How would fatigue actually be quantified? How would the player manage "rotating watch shifts" in a surface (or land) group, so that at least some units are always on alert? Or should this be left completely to the AI? And how should this factor be communicated to the player?

Open to suggestions.

[p1t1o]

So right now we have an OODA loop time assigned to given proficiency levels, which could be taken to represent an "ideal" response time.
Currently all crews of a given piece of equipment with the same proficiency have the same response time.

The argument is, as I see it, that the human factor often makes the OODA loop longer, regardless of how advanced the equipment is.
And as an addendum, it is highly unlikely that the crews of two ships, even given exactly the same training and equipment, would always have identical performance.

Simple idea:

Make final OODA-loop-time for a given proficiency, a probability-based value rather than a fixed value.

For example:
a 50% chance that a rookie crew is caught off guard and has a double-length OODA loop/has Xseconds added to OODA loop, in any given engagement.
a 5% chance that an ace crew is caught off guard and has a double-length OODA loop/has Xseconds added to OODA loop, in any given engagement.

Or:
a 40% chance that a rookie crew has its OODA loop time increased by 100%/Xseconds, in any given engagement.
a 40% chance that an ace crew has its OODA loop time increased by 20%/Yseconds, in any given engagement.

Or any variation along those lines if you wanted the range of possible outcomes to be more complex, or build a probability-response curve for each proficiency level.

Tune probabilities and time penalties as desired.

It doesnt simulate fatigue but it could give a range of responses that fit the bill.

[boogabooga]

If add a fatigue model, please don't forget about aircraft that have been airborne for 15 hours.

[SeaQueen]

The Global Thunder MBX, a few years back, had an interesting example on ship steaming conditions:
Condition I: General quarters, all weapons and sensors manned, fatigue rate builds fairly quickly.
Condition II: relaxed GQ, personnel rest near battle stations, slower rate of fatigue accumulation.
Condition III: All sensors manned, some personnel near weapons stations, takes about 5 minutes to achieve full GQ status. Fatigue neutral.
Condition IV: Selected sensors manned, weapons typically unmanned, about 15 minutes to full GQ. Allows fatigue dissipation.

How would fatigue actually be quantified? How would the player manage "rotating watch shifts" in a surface (or land) group, so that at least some units are always on alert? Or should this be left completely to the AI? And how should this factor be communicated to the player?

Open to suggestions.

The problem with this, is that you're running dangerously close to modelling doctrine (badly), and not physical processes. In a real warship it actually gets far more nuanced than that, with specific readiness conditions tailored to specific scenarios. For example, they might have a "Condition IIIb" which might be optimized for transiting a minefield, and something else for an area with enhanced air breathing threats, still another for ballistic missile defense. Part of life on a warship is paying attention to the mostly irrelevant babblings on the intercom system (1MC) that regulate life. It even tells you when the sun rises, which for people in the CIC or engine room, might go unnoticed. And you're right, being at full general quarters probably isn't sustainable. At some point people need to do things like eat, shower, and sleep. The thing is, because there's so many different nuances in a ship's state of readiness, you probably wouldn't necessarily have to be at full general quarters in order to fight the ship effectively. So they ship's "readiness level" needn't actually correspond to a lowered level of readiness, depending on what the threat is. In that sense, I think it's a red herring.

The goal should not be to reproduce the HMS Sheffield, USS Stark, USS Vincennes, INS Hanit or USS Mason incidents. Each of those warships got struck because of a confluence of a unique set of circumstances, as the subsequent investigations revealed. There's also a ton of nuances to the rules of engagement that drove the Vincennes incident. Are you going to capture those too? If you've ever seen real rules of engagement, you'd realize that Command's duplication of that process is extremely crude. If we don't duplicate those exact circumstances, it isn't a failing of the simulation. The fact that these are famous incidents makes their significance loom large in the popular imagination, but there's also recent counter examples where the ship's defensive weapons performed very much as they do in Command game:

https://news.usni.org/2016/10/11/uss-ma ... les-attack

Undefended warships get hit. Defended warships usually don't. This isn't a brilliant insight. I think much more insightful are the numbers from the Tanker Wars which suggest that generally speaking warships and vessels escorted by them tend to do quite well against cruise missile attacks, and undefended commercial vessels don't.

The truth is that ASCMs just aren't the best way to sink a ship. You're probably better off with a mine or torpedo. If you're going to try, its probably going to take a lot of missiles, a lot of planning, and several tries. Why should the game be changed if people who aren't very good players complain that they can't reproduce the Sheffield incident? If there was anything I'd change to make the game better, it's that the missile defense values are way low. They need to be at least tripled. If warships are in close formation, and they are benefiting from mutual support, the effectiveness is (literally) exponentially better, requiring even more weapons. That just has to do with the math of missile defense, and that's accurate. There's no need to change it.

I think it's a bad idea for Command to be trying to reproduce specific incidents and instead focus on the main underlying dynamics of the fight. Crew readiness (usually) isn't a driver.

[BDukes]

This tough one as many players won't utilize at all. Who wants their ships manned by the B-team except the hardcore grog. I can also see how this would piss in Sea Queens pro pudding as the proficiency stuff is standard and add variable might muck up what current pro expect and existing results.

If proceed I would look starting to add specific OODA loop variable that can applied in interface and lua. This one good start and can add others as smart people come up with them for you.

Bill

[1nutworld]

I have to be honest, it's nice to see the Devs working on something like this, and that thought is being given as to addressing this real life situation and having awareness of it's absence in the simulation.

Bravo Zulu, all!

[Coiler12]

Where I've seen this issue the most, and where the biggest tightrope to walk is, isn't ships but rather antiaircraft guns, where a lot of manually operated AAA units with long OODA clocks have trouble engaging faster aircraft. Of course, this is accurate and the advantage in jets of appearing for a shorter time and requiring more/better cuing is a real one. So it'd be tricky to not make it skewed in either direction.

The partial solution I've used that can be done is just to adjust proficiency levels. To make AAA fire more often, I tend to just set the gun units to ace proficiency. And you could (and I think it has been done) use Lua to simulate alertness by adjusting proficiency (and thus reaction times) up and down. So maybe refine that...

I dunno, a lot of it is over my head, but I still feel I'd give my thoughts/experiences.

[Gunner98]

This is a really tough one. You would effectively be modeling un-readiness, incompetence or perhaps just bad luck.

The side proficiency levels and the OODA-loop setup that exist already do some of this, and I think that generally works well.

Tampering the current system where the baseline assumption is that everything and everyone is working properly is a very dangerous thing. The backlash of 'That would never happen; This is broken; The game is cheating!" cries would far outweigh the current complaints I think.

Maybe the fundamental question of - is this a game? Or a Sim? Or both, is relevant here.

Now my thoughts on the question you asked:

First - would this be a player or a scenario designer selectable option? Would the mechanics be accessible to the player in game?

If this is a scenario design feature perhaps an assumption can be made that all systems will be ready to role at 100% after XXX time. Therefore a switch (side or unit) could be added where the designer can set up a scenario start where one side or unit is surprised and will recover from that surprise after XXX time. For most scenarios of less than 48-72 hours this is probably all that is needed and will give the opportunity for a surprise attack. This would be useful if not overused in my opinion.

If this is a player accessible thing it gets much more complicated. It needs to be cumulative and as boogabooga noted applies to aircraft in flight and probably high-G maneuvering. The player would then need to monitor fatigue levels and adjust the condition status (notwithstanding what SeaQueen describes as the nuance of the whole system), to allow for rest and recuperation. In my opinion this would simply add an additional workload on the player for a questionable gain in realism. I'm sure that another complaint you receive regularly is steep learning curve, high player workload and complicated etc.

Anyway those are my thoughts. I have more if you choose to go this way.

[BDukes]

ORIGINAL: Coiler12

Where I've seen this issue the most, and where the biggest tightrope to walk is, isn't ships but rather antiaircraft guns, where a lot of manually operated AAA units with long OODA clocks have trouble engaging faster aircraft. Of course, this is accurate and the advantage in jets of appearing for a shorter time and requiring more/better cuing is a real one. So it'd be tricky to not make it skewed in either direction.

The partial solution I've used that can be done is just to adjust proficiency levels. To make AAA fire more often, I tend to just set the gun units to ace proficiency. And you could (and I think it has been done) use Lua to simulate alertness by adjusting proficiency (and thus reaction times) up and down. So maybe refine that...

I dunno, a lot of it is over my head, but I still feel I'd give my thoughts/experiences.

Yes. Very good point here.

[1nutworld]

ORIGINAL: Gunner98

This is a really tough one. You would effectively be modeling un-readiness, incompetence or perhaps just bad luck.

The side proficiency levels and the OODA-loop setup that exist already do some of this, and I think that generally works well.

Tampering the current system where the baseline assumption is that everything and everyone is working properly is a very dangerous thing. The backlash of 'That would never happen; This is broken; The game is cheating!" cries would far outweigh the current complaints I think.

Maybe the fundamental question of - is this a game? Or a Sim? Or both, is relevant here.

Now my thoughts on the question you asked:

First - would this be a player or a scenario designer selectable option? Would the mechanics be accessible to the player in game?

If this is a scenario design feature perhaps an assumption can be made that all systems will be ready to role at 100% after XXX time. Therefore a switch (side or unit) could be added where the designer can set up a scenario start where one side or unit is surprised and will recover from that surprise after XXX time. For most scenarios of less than 48-72 hours this is probably all that is needed and will give the opportunity for a surprise attack. This would be useful if not overused in my opinion.

If this is a player accessible thing it gets much more complicated. It needs to be cumulative and as boogabooga noted applies to aircraft in flight and probably high-G maneuvering. The player would then need to monitor fatigue levels and adjust the condition status (notwithstanding what SeaQueen describes as the nuance of the whole system), to allow for rest and recuperation. In my opinion this would simply add an additional workload on the player for a questionable gain in realism. I'm sure that another complaint you receive regularly is steep learning curve, high player workload and complicated etc.

Anyway those are my thoughts. I have more if you choose to go this way.

Making this an option for the player to choose would be something that will eliminate the concerns that Sea Queen addresses, but as I stated my opinion, that it's a good thing to try and implement and add to this great sim.

And yes, I think it is something that the player should be able to access in game, again just my measly 2 cents worth.

[Parel803]

I find it tough to compare the game with real life. With so many real life variables it not easy to say which are usefull for the game and wich are not. And which can be modelled in the the game if they are useful.
I agree on the fact that there are differences between ships crews and there operational status, if one is just coming out of FOST or one is just before its maintanance period. If you have new personal on key function, Personal shortage, etc, etc.
A few of the other things we consider on the ship are, as mentioned earlier, ROE's - PPI's - HostileIntent/Act - Identity criteria's - Flyup/Flytrhough, X-fire. I find the game easier to ID the picture than it does in real life, which is fully oké since it's a game.
I do like the idea of being able to tweak units operational status in nhte sceanrio editor, seeing that reflected in the unit status window.

For just the fatique parameteris always a concern for the command and that's is why we have those different states of the ship being in and that's why we rotate compilers and MGunners hourly, food and lots of coffee. The sharpness isn't the same during you're watch of 5, 6 or 7 hours and it is't the same the first day compared to 25th day in the sam patrolling area.
But I I'm not sure how to simulate that in the game. As said by SeaQueen so many parameters why you, as a human, would react a little later than the woman or man next to you. If it would be a new feature than I personaaly agree on the idea of making it an optional one for the player.

So for it's worth fatigue as 1 parameter for me less needed, if it's happens should be gradually I guess. And even than, if called to battle stations, I know for a fact all are sharp on there post. The ability to tweak in scenario editor more than proficiency sounds appealing to me.
If I can give more info on a specific type of operation, duty cycle, etc. I'll try to help.

Just my simple thought on the matter, with regards GJ
And I do apologize for my writing English

[c3k]

Some thoughts...

Variability in the OODA times would be good for gameplay/realism, beyond just the hard-times used based on experience.

Surprise does occur...but not in-game. Every unit is always right at their assigned OODA, regardless if the threat is atmospheric, surface (land or water), or sub-surface.

Fatigue is real, but so is the hyper-alertness of a fatigued individual when adrenaline dumps into the bloodstream during an attack.

Confusion about who is assigned to hit that target does occur.

What does all the above mean? Well...I'd like to see some variability in OODA times, but I don't think tracking fatigue is the best way to do that. I would rather assume that OODA takes into account surge versus sustained engagements. Large-crew ships could sustain faster OODA response times than small-crew ships (given similar needs to man sensors and weapons).

How do you track surge vs. sustained? Monitoring individual fatigue levels seems a bit too much for the player. (Ships' captains would do that, much as they would set up shifts for the engine room, etc.)

I'm not sharing a solution, just my thoughts on the parameters of the issue and gameplay.

[pbrowne]

Very interesting discussion which I'm sure will inform some modelling of OODA loops in CMO.

I came across this relevant thesis by Lieutenant Commander Katrina Ryan, Royal Australian Navy which may help with any modelling. There are also plenty of relevant references to similar studies and papers included.

Fatigue Mitigation and Crew Endurance Management in the Royal Australian Navy and the U.S. Navy: a Review of Recent Efforts and a Collaborative Path Forward

Considering that this is being discussed, I'm a bit surprised that this hasn't been modeled in the CMO Professional version. Though I assume the data from that version can have algorithms separately applied by the user to model different scenarios on crew performance as part of post mission analysis.

+1 to have OODA modelling available in CMO for scenario development and as a user preference/toggle.

As a former artillery officer, I know how fatigued soldiers can become and the effect that has on performance! Individual and team experience in sustained operations helps with personal management and welfare. As does experience and training of commanders to manage team performance and morale. Morale is also key, as loss of it can lead to lethargy and poor decision making, and of course the opposite applies.

Battle success or failure will affect performance in some way. As can the experience (perceived or real) of the enemy. The early years of WW2 of allied forces against experienced Japanese and German forces, which had waged war since the 1930s, saw defeats (North Africa, SE Asia) where morale and stress/performance was impacted (leading to poor decisions) and only improved with time and experience.

Peter

[thewood1]

Isn't OODA modeling already available through proficiency? I thought you could set it by unit/group/side already in the scenario editor.

It might be good to have a list of what OODA and proficiency effect. The manual lists a few, but I'm not sure thats exhaustive.

My opinion is that anything like proficiency and fatigue should have some variability. A poorly trained and tired crew might still react quickly at times, but is less likely than a well trained and rested crew.

[Battelman2]

At the very least, I would think there should be some penalty to pilots airborne for extended periods of time.

All else equal, a fresh crew should win against a fatigued crew more often than not. I shouldn't be able to keep aircraft up for days at a time without any consequences. That is my biggest take away from this thread.

Regarding naval units: I definitely like the idea of alertness variability, but as others have said it would have to be implemented with care.

[stilesw]

Fatigue Mitigation and Crew Endurance Management in the Royal Australian Navy and the U.S. Navy: a Review of Recent Efforts and a Collaborative Path Forward

Peter,

Thanks for this reference. I've added it to the CMANO/CMO unofficial Dropbox reference library.

Unofficial - i.e. not sponsored by WarefareSims, MatrixGames, Slitherine, their employees, relatives, pets or ancestors.

As always, any forum member can have access to this Dropbox resource. Just PM me with your email address.

-Wayne Stiles

[KnightHawk75]

ORIGINAL: BDukes

This tough one as many players won't utilize at all. Who wants their ships manned by the B-team except the hardcore grog. I can also see how this would piss in Sea Queens pro pudding as the proficiency stuff is standard and add variable might muck up what current pro expect and existing results.

If proceed I would look starting to add specific OODA loop variable that can applied in interface and lua. This one good start and can add others as smart people come up with them for you.

Bill

^^this,
for those that want it perhaps add:
unitwrapper.manualOODAMultiplier - could be set per unit and applied to baseline OODA for the unit.
or
unitwrapper.manualOODAOveride - set time in seconds > 0, directly replacing the baseline figure.
maybe also add something like unitwrapper.manualROFDelay where the user could add seconds to Rate Of Fire that gets added to weapons.

One or both would help with this issue and others of not being able to tweak oodas beyond prof levels.
Either are better imho than any suggestion to introduce a random nonadjustable thing (such as #2).

At the very least, I would think there should be some penalty to pilots airborne for extended periods of time.

I disagree in that I don't want that hard coded into the game or even a scenario level setting as it doesn't apply equally to all situations or what may be being modeled, you can already code this in yourself by checking airtime and degrading proficiency or taking other actions based off it (introducing damage\sensor loss etc\fires\forced rtb\etc).

[thewood1]

Can you currently set a unit to blind through Lua? I have never seen it and it might also be used to set individual units readiness in a rough way.

[boogabooga]

ORIGINAL: KnightHawk75

ORIGINAL: BDukes
At the very least, I would think there should be some penalty to pilots airborne for extended periods of time.

I disagree in that I don't want that hard coded into the game or even a scenario level setting as it doesn't apply equally to all situations or what may be being modeled, you can already code this in yourself by checking airtime and degrading proficiency or taking other actions based off it (introducing damage\sensor loss etc\fires\forced rtb\etc).

Sorry, but I disagree with your disagree. That a 1-2 person crewed aircraft can't stay airborne indefinitely without the pilots becoming too tired at some point to safely land or function at all is about the most universal thing that I can imagine, every bit as much so as fuel or ammunition considerations. It's one of the reasons why UAVs became prevalent.

I would go further than simple OODA limitations and enforce an RTB at some point, especially for small aircraft. Letting your CAP aircraft refuel seven times to loiter for 17 hours at a time is an unrealistic force-multiplier.

Sure, you can Lua everything, but the universal things really do deserve to be in the engine, IMHO. Makes every bit as much sense to me as enforcing fuel or turn-around time.

[pbrowne]

ORIGINAL: stilesw

Fatigue Mitigation and Crew Endurance Management in the Royal Australian Navy and the U.S. Navy: a Review of Recent Efforts and a Collaborative Path Forward

Peter,

Thanks for this reference. I've added it to the CMANO/CMO unofficial Dropbox reference library.

Unofficial - i.e. not sponsored by WarefareSims, MatrixGames, Slitherine, their employees, relatives, pets or ancestors.

As always, any forum member can have access to this Dropbox resource. Just PM me with your email address.

-Wayne Stiles

Glad to assist. [:)]

IMO if CMO is going to incorporate modelling of OODA concepts, or indeed the whole domain of humans in conflict, then there should be an appreciation of all dimensions, not just physical. This includes, in Boyd's concept, Physical, Mental and Moral - yes moral, not morale, e.g. Mao's War of Resistance against Japan, Vietnam and Afghanistan etc.

A paper on morale and combat effectiveness, part of the mental dimension of Boyd's OODA Loop:

https://scholarship.richmond.edu/cgi/viewcontent.cgi?article=1007&context=honors-theses

Some casual reading [X(] on OODA and a holistic literature review on relationships with numerous theories, including Innovation Theory, Second Law of Thermodynamics, Gödel’s Incompleteness Theorem, Heisenberg’s Uncertainty or Inderminacy Principle and Boyd’s Integration Principle...

https://apps.dtic.mil/dtic/tr/fulltext/u2/a425228.pdf