Back in Quantico: The 9th Command-PE User Conference & Training event

October 11, 2022 · Posted in Command PE · Comment 

It was great to be back!

Matrix Games, LLC hosted the 9th Annual Command: Professional Edition User Conference & Training event at X-Corp facility next to Marine Corps Base Quantico, from 19-23 September 2022. The event was organized with the full support of Luis E. Velazquez, Chief Technology Officer (CTO) at United States Marine Corps, and in close coordination with the USMC, and run throughout the week, focused on helping the defense community get the most out of the increasingly powerful and diverse Command-PE software suite.

As with previous events, this too boasted a diverse array of participants with more than 30 agencies & organizations from the US DoD and NATO allies as well as the defence and related private sector. It included presentations and training sessions by Matrix Games in additions to guest presentations by numerous users highlighting their use cases of employing CPE for their specific needs. Participants had front-row seats to the comprehensive analytical, wargaming & training capabilities of Command-PE, interacted directly with core members of the development team and exchanged experience and tips with other operators of the software.

For a change of scenery, the next CPE event will be held in 2023 in Italy. See you all there!






Tags: no tags

Nerf Wars: On downgrading Russian systems & units in Command

October 3, 2022 · Posted in Command, Command PE · Comment 

So, ever since it became clear that Russian combat performance in Ukraine has been “less than stellar”, there has been a persistent request in many corners of the web towards the Command dev team. The request can be summed up as:

“So, when are you guys going to nerf Russian equipment in Command’s database, to match what we are seeing in Ukraine? It seems it is performing well below official specs.”

(Oxford Dictionary: “to nerf”: (of a video game developer) reduce the power of (a character, weapon, etc.) in a new instalment or update of a video game.)

A naval-oriented variant of this comment is: “I tried simulating the attack on the cruiser Moskva, and I just couldn’t sink it as happened it real life. So CMO is probably talking up Russian hardware.”

Now, there is a short and direct answer to both these claims, but we have been advised not to print it here. So let’s go into the more elaborate and slightly more polite version instead.

Command, by default (ie. stock DB values) represents Russian systems (and all other nation’s systems) as they are meant to be used, by trained crews employing them according to their design doctrine. Shortly after the Ukraine conflict got going for real, a US general remarked that “Russian hardware works pretty well… when used by Ukrainians”.

(As a quick example of this, Carlo Kopp had written an unusually insightful analysis on what happens when Russian SAMs get used correctly, and also what happens when they are not. Favorite quote: “The Syrians used mobile missiles in a fixed configuration; they put the radars in the valley instead of the hills because they didn’t want to dig latrines — seriously.”)

At the same time, Command also recognizes that combat is not a sterile hardware contest, and provides a lot of “soft factor” options (crew proficiency settings, reaction times, doctrine settings, EMCON, ROE etc.) to offer the ability to represent sub-optimal usage of said hardware. You can have two different units use exactly the same hardware with vastly different effectiveness and survivability (our favorite reference example is Iraqi 1991 SA-6 battery vs. Serbian 1999 SA-6 battery).

An example list of the factors you can edit:

  • Proficiency levels, both side-wide and per-unit
  • Reaction times (OODA loop values)
  • Doctrine settings
  • Rules of Engagement
  • EMCON settings
  • WRA settings (ie. firing doctrine)
  • Per-component equipment failure

That very last aspect is particularly important in light of what has been recently learned WRT the system readiness on the Moskva. According to the leaked readiness report (standard caveat for CYA-shaped leaks), both the central SA-N-6 fire control radar and the short-range SA-N-4 systems were effectively disabled due to equipment malfunction and were waiting for replacements. In addition both the main guns as well as the main air-search radar were also inoperative. In other words, the Moskva was sent to an active warzone almost naked against air/missile attack.

Can this be faithfully reproduced in Command? Absolutely.

Can other factors, such as apparently poor crew proficiency which led to both poor reaction times and also abysmal damage control, also be modelled? Also yes, very easily so.

So why then do some CMO users out there find it so hard to reproduce results like the Moskva sinking? (Or the Saki airbase strike, or S-300/400 batteries not being omnipotent, or UAVs apparently roaming at will, or…)

TOUGH LOVE WARNING: Because some people’s idea of “testing something in the scenario editor” is to quickly plop down a few units here and there, in their stock-DB setups, give them free fire reign against each other, and call it a day. No customization for soft factors, component status or any of the other real-world aspects that directly impact the end result.

Thankfully, some players are disciplined enough to do it right. Here is an example, soon after the actual sinking itself when info was still scarce. (This of course is far from “the last word” on the subject. SMEs are still debating e.g. how the Sheffield went down after a single Exocet hit while the Stark survived two of them. Hell, even WW2 events are still up for analysis. It’s a safe bet that the Moskva sinking will be endlessly discussed by our grandchildren.)

It is tempting indeed, to embed the soft-factor issues directly into the DB entries themselves, so that when you spawn a Russian unit on the virtual battlefield, it’s in a sorry condition out-of-the-box, ready to be clobbered. The price you pay for this expedient approach becomes obvious only later, when you realize that not only you lost the ability to clearly separate man (and context/circumstances) from machine, but you also railroaded yourself intellectually into believing that this Russian unit will always behave like this.

Does this matter? Let us consider, for instance, an Israeli staff sergeant nerfing Egyptian tanks in a wargame just prior to Yom Kippur in 1973 “because they were such pushovers just a few years back”. Did this specific example happen? Maybe, maybe not; but we know for a fact that the Israeli military establishment grossly underestimated Egyptian & Syrian forces because of their lightning successes in 1967 (they essentially nerfed them in their mental “databases”), and that plenty of Israeli soldiers paid for that intellectual myopia with their lives. Is this a mistake we want (or can afford) to repeat?

Such a radical shift in combat effectiveness with identical/similar hardware does not happen just between conflicts, but also within the span of a conflict itself. Returning to Ukraine for an example, in the early days of the “rush for Kiev” we observed a lot of Russian SHORADS batteries getting bombed by aircraft while completely inoperative. As it turns out, apparently the rapid speed at which these elements were forced to move (to screen the assault forces) prevented them from properly screening/leap-frogging each other and thus actually operating as they are designed and supposed to do. When later these very same systems were properly echeloned with the forces they covered during the Russian withdrawal to Donbass (and also undeniably as the hard lessons of the first weeks were distilled to the surviving operators), their effectiveness and survivability were restored to expected levels. (And then the Ukrainians introduced HARMs in the theater… but that’s another story)

How can you represent such drastic differences in effectiveness in the very same unit, if the soft-factors are embedded in the database entry? Short answer: You can’t.
(Longer answer: You can cheat/hack your way into it by having multiple entries in the DB, each representing different competence levels and equipment maintenance. It’s a very hacky solution, a maintenance nightmare, and again you are mixing up man, machine and context. We sometimes were forced to do something like this back in the computer-Harpoon days, simply because Harpoon had absolutely no soft factors. Nowadays we can and must do better.)

So, to recap: We would be doing a grave disservice to both our commercial players and especially pro customers by directly embedding soft factors into the DB just so that Joe Player can get a realistically-degraded Moskva out of the box. Platforms and systems in the DB are spawned in pristine condition and (by default) are assumed to be crewed competently: This is not a design oversight, but a conscious and carefully-considered decision. Players can then modify the platforms themselves, turning them into anything from decrepit spank-targets all the way to invincible fortresses, and shape the context of the virtual environment in their favor or against them, in order to either recreate historical situations or explore hypotheticals of past, present or future. But in every case, it’s something that they will have to roll up their sleeves and do themselves. To quote Norm Koger from two decades ago: “Word processors ask a lot of those who would use them to create stories”.

Thanks, and carry on.

Tags: no tags