The new features of Chains Of War: Cargo, amphibious and airdrop operations

May 11, 2017 · Posted in Command · Comment

The public beta phase of the v1.12 update (the companion to the upcoming “Chains Of War” DLC pack) has been concluded, and the “Gold” version is now going through the production paces. We have already covered most of the new major features in the DLC, such as communications disruption, aircraft damage and the new weapon types. Today we are looking at arguably the most anticipated new feature of v1.12: Cargo, amphib and airdrop operations.

NOTE: This feature requires Chains Of War to be installed.

“Professionals study logistics”

Faithful representation of landing & airdrop operations was a high user request even back on the early alpha development days of Command. The v1.0 release shipped with a respectable system that combined the new docking-operations ability and the rich new capabilities offered by the powerful event editor (and later Lua), the classic example being along the lines of “once amphib/transport/airdrop vehicle X reaches area/point Y, teleport/spawn unit-Z on the vehicle location to simulate the drop off”.

This worked, but was of course limited (for example the player was restricted in which areas he could disembark forces); poaw illustrated the limits of this system hilariously in his not-a-review of CMANO v1.0. We were aware of these restrictions and have been gradually working on “something better”.

Probably a lot better.

Transportable forces, and the people who love carry them

In Command’s terminology, all units that that can be transported by other able units are counted as “cargo”. This can cover anything from foot infantry up to super-heavy vehicles or transportable facilities. In order to realistically restrict what any unit can carry, we had to expand the available information both for the units marked as carry-able and the units that can act as transports:

For transportable units, the volume, weight and crew properties are populated in the databases. The general type of the unit is also delineated as one of five basic types (personnel teams [Squads, MANPADS, ATGM], small cargo [Car, AAA Guns, light guided weapon], medium cargo [APC, Towed Arty, heavy guided weapon], large cargo [Tank, missile TEL, Trailer], and very large cargo [IRBM / ICBM TEL]).
For units that can act as transports, their available weight, volume and crew limits are also present in the databases. Each unit also has a “maximum cargo type” indicator for the kind of load it can carry. For example, while you can cram quite a few people into a C-130 if you get creative, you cannot really load a medium tank on it (It’s been tried. Once.)

When the time comes to actually start loading, manually or automatically, these properties are cross-checked and either presented to the player as restrictions or obeyed by the crew AI in its decisions as to what to load where.

Transfer of units can occur both between one independent unit and another (e.g. personnel from one ship to another), or from a parent host to its hosted unit (e.g. from a pier to a docked ship, or from LPD to hosted LCAC), or from a host unit to any arbitrary point on the map.

The loading of able units in suitable hosts, as well as the actual transport from X to Z, can happen in either mission AI-driven mode or with direct player intervention.

By hand and heart

Like every feature in Command, there is always the option to perform every action manually. Cargo is no different.

Pictured below is the interface for exchanging cargo between docked units and their hosts (think: hovercraft in the well-deck of a LHD, or a C-130 at an airbase).

This example illustrates a typical airdrop, with all the steps performed manually by the player:

And this video demonstrates transloading a heavy assault force from a naval base to a Wasp-class LHD that is currently docked at the pier, and preparing for an amphibious landing:

We’re on a cargo mission from God

So only the micromanagers get to have all the fun? No way! A new class of mission (“cargo mission”) has been added for those who prefer a more “hands off” approach (and of course for the benefit of non-friendly AI sides).

Cargo missions are broken down by the units (hovercraft, helicopters, aircraft) assigned to unload, and then by the cargo items themselves. Multiple cargo missions can be assigned to fine-tune the locations where the units are unloaded.

The mission progresses in a cycle, the units assigned to the mission load up units from their assigned base – either a ship at sea (LHD, LHA, CV etc) or an airbase – then take off, set course to the mission area reach the mission, then unload, and RTB. This continues until every piece of cargo has been unloaded.

Using our previous example with the amphibious assault force now in position, we can either manually again transfer the mobile units from the large amphib to its hosted LCACs and helicopters and fly/sail them to the beach…

….or we can create a cargo mission to handle the landing, and sit back and watch:

Looking forward

One future direction the cargo functionality could move in is allowing weapons to be moved from airbase to airbase by cargo aircraft. An example of this might be an embattled Norwegian airbase in the opening hours of WWIII eating through AMRAAMs like they were candy. Large stocks of AMRAAMs exist in bases in the UK, so let’s pack up 40x AMRAAM on the next C-130 flight heading towards the frontlines. There are quite a few similar use cases and we are open to community feedback as to which cases deserve development priority and why.

Next: The scenarios of “Chains of War”

Tags: no tags

The new features of Chains Of War: Lasers, railguns and tactical EMPs

May 4, 2017 · Posted in Command · Comment

The “Release Candidate” (ie. public beta) phase of the v1.12 update (the companion to the upcoming “Chains Of War” DLC pack) is wrapping up on the MatrixGames forum. The feedback on the new additions like sonar masking, the new 2x time compression step and much improved 4K/UHD support has been very positive. We have already covered two of the new major features in the DLC, communications disruption and aircraft damage. Today we are looking at some of the new weapon systems introduced in v1.12.

Ray of light: High-Energy Lasers

Combat lasers have been on the drawing board and test lab ever since the days of SDI, but advances in materials and engineering are finally enabling their long-awaited breakout in the field. Command has featured two major representative systems from its initial release (the YAL-1 COIL laser and the AN/SEQ-3 LaWS), but for the needs of Chains Of War and the v1.12 update we have undertaken a thorough revamp of the mechanics.

Command now models four distinct types of laser systems, each with its own peculiarities:

As an example of the practical differences, COIL and DF are so-called “chemical” lasers and use magazines of chemical materials to shoot, which need to be replenished just like gun rounds. CO2 and SSL lasers on the other hand replenish their ready-to-fire “magazine” by drawing power directly from their parent platform’s powerplant (no UNREP necessary!). Of course this also means that if the powerplant is not working for any reason, the magazine will be depleted.

This would appear to put chemical systems at a severe disadvantage; however, chemicals generally dissipate their thermal waste more easily (heat management is a major issue in solid-state lasers). This allows them to enjoy both a superior rate of fire and usually achieve greater power output per shot – thus greater absolute range and damage-at-range than CO2 & SSL lasers. (Solids typically counter this by ganging up lots of small-power emitters and converging their beams at the target point. Fibers make this easier, but aiming is obviously more complicated.)

Taste the rainbow.

Each laser type uses different operating wavelengths and this affects both their atmospheric losses and their actual absorption factor by the target surface.

HELs bring unique strengths and challenges to the combat environment. For instance, aircraft under attack by HELs do not get any evasion ability at all, since there is no practical delay between shot and impact; the pilots can only pray that the aim itself is defective. Laser mounts are susceptible to the same accuracy modifiers as unguided weapons like guns and rockets (for example, in a rocky sea a small ship will be a significantly less stable firing platform than a large one), but to a lesser extent thanks to their instant transmission.

HELs offer an instant attack on a target at significant range, but their actual on-target delivered power reduces dramatically with distance, even in “ideal” atmospheric conditions (this is part of why the AL-1 ABL was meant to cruise over the clouds). Under bad weather conditions their range shrinks even more, even down to almost nothing. They also need a clear line of sight to work.

Despite their tremendous future potential, HELs currently are generally not powerful enough to bring down anything larger than a small drone with one shot. Against aircraft, they somewhat resemble WW2 flak guns: They can shoot down an aircraft, but it usually takes a while to do so. This, incidentally, necessitated the introduction of the improved aircraft damage model. For this reason, scenario authors are encouraged to activate the aircraft damage feature when building a scenario that features AAW-capable HELs; otherwise, these systems may be too overpowered, swatting aircraft out of the sky like flies with single bursts.

Speed kills: Railguns and HVPs

Railguns are a frequently misunderstood subject with a lot of urban legends and myths floating around. This most excellent primer on Reddit is a good starting point for a quick refresher at the fundamentals.

Railguns conceptually are similar to conventional gun rounds. What makes them special are the very high muzzle velocities they can achieve (which directly translate to large absolute range and tremendous impact energy-at-range), and the fact that they use electric rather than chemical/propellant power for the projectile acceleration; combined with the typically smaller projectile weight & volume this allows vast improvements in magazine capacities.

A most interesting spinoff of railgun development has been the realization that the high-velocity projectiles (HVPs) that have been developed for railguns can in fact be also adapted/scaled to be fired from current conventional gun systems. This allows spreading the benefits of the new technology on fleet platforms before the proper “full capability” rail mounts reach operational maturity. The latest version of the DB3000 database shipping with the v1.12 update includes the 155mm/52 AGS HVP (used by a new 2018 variant of the DDG-1000 Zumwalt) and the 127mm/62 HVP, fired by a modified Mk45 Mod 4 gun (Mount #3016) suitable for placing on any modern surface combatant. More types will be added as additional systems are introduced into service.

Did we mention that these projectiles are pretty fast, and they can punch through some serious armor?

“Instead of Hiroshima, you get the 17th century”: Tactical EMPs

Already since the release of v1.09 and Northern Inferno, Command has made it possible to generate a massive electromagnetic pulse through a high-altitude nuclear detonation (GoldenEye!), with frequently catastrophic effects on exposed platforms and their component sensors and comm systems. Non-nuclear systems producing a more localized variation of the same effect are now gradually entering service, offering new “non-kinetic” disruption capabilities and expanded tactical options. Command models both major variants of tactical EMP warheads; the v1.12 update includes omni-directional systems a.k.a “EMP grenade” types (Directional systems like the USAF-developed CHAMP are available on the Professional Edition).

Tactical EMP systems can act as an “trump card” by disrupting a carefully-constructed adversary network; their effect is most profound when they are combined with coordinated electronic attack and communications disruption to completely dislodge the enemy’s plan. They can also be used alone literally as “grenades”, temporarily punching an electronic hole through an otherwise inaccessible strong enemy screen.

On the receiving end of a tactical-EMP strike. It hurts.

Tactical EMPs provide even more flexible solutions to existing tactical problems are we are quite curious to see how experienced players will put them to use.

Coming up next: Cargo ops!

Tags: no tags

The new features of Chains Of War: Aircraft Damage

April 27, 2017 · Posted in Command · Comment

The “Release Candidate” (ie. public beta) phase of the v1.12 update (the companion to the upcoming “Chains Of War” DLC pack) continues steadily on the MatrixGames forum. The feedback on the new additions like the new 2x time compression step and much improved 4K/UHD support has been overwhelmingly positive, and the new sonar masking feature has also been well received. Chains of War, however, will introduce a number of major new features with significant effects on scenario design and gameplay. We already had a look at communications disruption. Today we are looking at another significant enhancement, aircraft damage.

Getting back home – in one or more pieces

– The other problem is that the A-10 is vulnerable to hits because its speed is limited […]. We had a lot of A-10s take a lot of ground fire hits. Quite frankly, we pulled the A-10s back from going up around the Republican Guard and kept them on Iraq’s [less formidable] front-line units. That’s fine if you have a force that allows you to do that. In this case, we had F-16s to go after the Republican Guard.

– At what point did you do that?

– I think I had fourteen airplanes sitting on the ramp having battle damage repaired, and I lost two A- 10s in one day [February 15], and I said, “I’ve had enough of this…”

(Interview of Chuck Horner to Air Force Magazine, June 1991)

Comprehensive aircraft damage modeling, while well-modelled on most combat flight simulators, is something of a rare appearance on grand-tactical, operational or strategic-level simulations and wargames, for a number of reasons. Command, following the paradigm of numerous other similar titles before it, started with the simple binary “100% healthy until shot down” model for aircraft. It has always, however, been our intention to do something more comprehensive. With v1.12 we are taking a significant step forward in this regard.

When the “Aircraft Damage” feature is enabled on a scenario (it is “off” by default in order to avoid disrupting existing scenarios), aircraft are evaluated for specific damage when hit by a weapon. Each aircraft now has a damage-point value representing its fundamental structural tolerance (similar to ships, subs and land units & facilities) plus three distinct armor levels – for cockpit, fuselage and engines. When a weapon impacts the aircraft, the damage is applied to the overall structure and in addition the chance of penetration is evaluated against each armor level. Each penetration probability is obviously dependent on the armor level and the nature and severity of the weapon warhead (e.g. penetrating rounds have a better chance than impact-explosive ones), but geometry factors are also taken into account; for example a cockpit hit is far more probable if the weapon impacts in the frontal quarter, engine hits are most common in rear-quarter impacts, while the fuselage is most vulnerable to side hits.

This Fulcrum driver is having a rather bad day

Similar to other platform types, when immediate damage is sustained, secondary fires can also erupt. The aircraft crew will attempt to suppress those every 5 seconds. The fire burns through the aircraft fuselage quite rapidly, causing structural damage, and if it evolves to conflagration can even cause a fuel explosion, destroying the aircraft (few things are as infuriating as blowing up from uncontrollable fire just as you are on final approach to land…). Critical hits from penetration are also possible; if the cockpit is compromised the aircraft is immediately out of control and destroyed, whereas a critical hit to an engine will damage or destroy it (for single-engine aircraft this has rather unpleasant consequences). Aircraft with at least one operational engine can still limp back home but all their kinematic properties are negatively affected. A plane with more than 80% structural damage will disintegrate in mid-air.

Because the existing armor levels were geared mostly towards surface & land targets (the smallest amount of armor being 40mm RHA equivalent), we also had to add several lesser armor levels in order to properly differentiate the differences in armor commonly found on aircraft. The revised armor levels are:

None (Human flesh, unarmored aircraft etc.)
Armor – Handgun (Human body armor or equivalent – can stop a handgun/pistol round)
Armor – Rifle (human body armor or equivalent – can stop a rifle or LMG round (5.56 / 7.62mm etc.))
Armor – HMG (can stop a heavy machine gun or heavy sniper rifle round (12.7 / 14.5mm etc.))
RHA – 20mm (20mm RHA – can stop a 20mm AP round)
RHA – 25mm (25mm RHA – can stop a 25mm AP round)
RHA – 30mm (30mm RHA – can stop a 30mm AP round)
RHA – 35mm (35mm RHA – can stop a 35mm AP round)
Light (41-90mm RHA – as before)
Medium (91-140mm RHA – as before)
Heavy (141-200mm RHA – as before)
Special (201+ mm RHA – as before)

The topmost armor levels will naturally have to be revised in the future as we [ REDACTED ].

Aircraft are also assigned “damage tolerance” levels before they abort/RTB. For fighter and attack aircraft this is set to 30%, for CAS aircraft 50%, and for all other aircraft to 10%. Once this threshold is exceeded, the aircraft breaks off and attempts to RTB. The player can of course issue an RTB order before this level is exceeded. Damaged aircraft will jettison their heavy stores when RTBing due to damage (regardless of the “Jettison stores under attack” doctrine setting).

Down for repairs

Damaged aircraft that manage to return to their base are not “magically” restored; they need an extensive amount of time to be repaired. The so-called “Estimated Time To Commission” (ETIC) value is calculated based on the extend and types of damage and may range from a few additional hours to entire days or even weeks. Obviously, depending on the duration of the scenario, this may mean that an aircraft is effectively out of the fight (On the Professional Edition, the method for calculating the ETIC is far more extensible and can use private customer data). The estimate for the repair time is communicated to the player through the message log, for example: “Aircraft-X (class Y) has damage that requires an estimated time-Z to restore. The repair time will be added to the aircraft’s ready-time.”

Developing and testing the improved damage model for aircraft has been a lot of fun for the dev & beta teams. There are cases where the differences in combat resolution are not significant; for example heavy AAMs or SAMs will take down a small aircraft, no ifs and buts. On the other hand, with light-caliber AAA or missiles with small warheads (Stinger, AIM-9 etc.) and particularly against large or well-armored aircraft the effect is quite dramatic. We were never comfortable with the fact that a single Stinger or machine-gun burst could bring down a B-52 with a lucky hit; this is now rectified.

Another factor (and a significant “last straw” in making us not delay this feature any longer) is the gradual service introduction of high-energy lasers. By their nature, these are currently not powerful enough to take down an aircraft (or in fact even large drones) with a single burst; concentrated or consistent fire is necessary (oddly, this is reminiscent of gunfire-vs-aircraft in WW2). The improved AC damage model is ideal for modeling this peculiarity which will probably last for at least the near future.

May your battle damage repairs never keep you down for long!

Tags: no tags

Red Phoenix, Team Carney and some fixes: Community scenario pack updated

April 20, 2017 · Posted in Command · Comment

Sometimes this happens too.

The last major update of the Community Scenario Pack contained some scenarios that had been erroneously rebuilt to the latest database versions and, as a result, produced a crash when loaded. The problem was located in the rebuild code and fixed, and Miguel Molina has correctly rebuilt the problematic scenarios.

In addition, two new community scenarios have been included to the refreshed pack:

Red Phoenix – Christmas Day, 1986: North Korea has decided to try and complete the re-unification of the peninsula, by force. Kunsan AFB has already been hit by MiG-23s and sustained damage. The main raid is only minutes away. Take your F-16s to the skies and defend your airbase!
Team Carney, 2019: A variety of minor conflicts have erupted around the world. The United States and its allies have responded by creating a number of “joint response forces” that will operate under the leadership of America’s various Unified Combatant Commands. In this scenario, USAFRICOM and allied forces are called upon to protect commercial shipping from a sudden increase in rebel-sponsored piracy and terror attacks off the coast of Western Sahara.

As always, the community scenario pack is available for download from the Command downloads page: http://www.warfaresims.com/?page_id=1876 . The new & updated scenarios will also become available for download later on the Command workshop on Steam.

Tags: no tags

The new features of Chains Of War: Communications disruption

April 15, 2017 · Posted in Command · Comment

The first few “Release Candidate” (ie. public beta) builds of the v1.12 update (the companion to the upcoming “Chains Of War” DLC pack) have began being distributed on the MatrixGames forum and we’re happy to say the feedback so far has been very encouraging. Additions like the new 2x time compression step and much improved 4K/UHD support have long been favorite requests and it is good to see them well received. Chains of War, however, will introduce a number of major new features with significant effects on scenario design and gameplay. Today we are looking at one of them; communications disruption.

Static on the radio

Most wargames and simulations accustom their users to the idea of omnipresent, instant, always-on communications. The battle may be lost – your forces & assets may be in disarray – but you are always in control of them and aware of their whereabouts, activities and condition. You are always in the know and in power. The pawns in the chessboard are always at your disposal.

But what happens when the lights go out? When the only thing on the radio is static? When the datalink is dead?

This is fast becoming an ever-important question, both because the western armed forces are increasing their reliance on distributed, hyper-connected force concepts (the F-35 and the US Navy’s NIFC-CA being fine examples) and because potential peer competitors, fully aware of this trend, are rapidly improving their electronic attack and cyber-warfare capabilities. The ever-evolving chess game of electronic warfare has never been limited to the radar bands, but more recently communications and datalinks are becoming increasingly appealing targets.

Beginning with v1.12, Command makes a bold step forward in exploring this domain. We want to show players both the “how” and the “why” of communication lines breaking, and the practical effects of units being isolated from their parent side’s common picture.

Causes…

A unit can have its communications disrupted in a number of ways:

If all its onboard comm devices and datalinks become non-operational (damaged or destroyed):

This frigate is about to become very lonely

Through the Lua scripting API: As an example: ScenEdit_SetUnit({Name=”USS Vigilant”, OutOfComms=”True”}). This is a very versatile technique as it can be used to model any number of factors, both man-made and natural, that can cause a unit to go “off-grid”:
- A submarine hooking up to HF or satellite communications when it goes to periscope depth, and breaking contact again when it submerges.
- A satellite linking only temporarily with its ground station to dump its intelligence product and receive new tasking instructions, then again going in isolation in space (contrary to popular fiction, even modern intelligence satellites are rarely, if ever, in constant link with their ground control stations).
- A cyber attack directed at the internal comms infrastructure of the targeted platform. (Your comm devices may be physically untouched, but the server at the core of the comms exchange just got taken over. Tough world! Chains Of War has strong examples of this.)
- Physical incapacitation (damage/destruction) of a critical C3I node leading to other units dependent on it going offline (remember that many of the first-night targets in Desert Storm were headquarters, C3 bunkers and comm buildings? You can now recreate why this was a critical action).
Through the scenario editor GUI, by selecting the unit and marking it as “out of comms”:
This is less powerful than using the Lua API but a simpler and faster way for quick setups. So for example you may use this to configure a unit to be “off grid” at the start of a scenario, and follow-up with a Lua script depending on some later action that changes this unit’s connectivity.
By jamming its comm devices, using communications jamming equipment similar to existing OECM systems. [NOTE: Integrated comms-jamming is a feature reserved for the Professional Edition. However, with a bit of creative work you can use the Lua API to approximate this in the commercial version of Command.]

…and Effects

So what are the results of a unit going “off-grid”?

The most obvious effect is that the unit is no longer under your positive control. You no longer know where it is currently located (you only know where it was when it last checked-in, and if any of your other still-connected assets manages to make contact with it, this “last datum” is updated). You don’t know what it is doing, what its fuel, weapons or damage status is. You don’t know if it is peacefully loitering with not a care in the world or if it is fighting for its life. You will know its fate with certainty only when it comes back to its base – or is destroyed first.

“Last we heard from Garry he was somewhere there… and that’s all we know.”

For its part, the cut-off unit loses all the benefits of the common side-wide operational picture; its situational awareness now reaches out just to the limit of its own sensors and no further. It has no idea what is going on “out there”. It can still detect, investigate and prosecute contacts on its own and proceed with its assigned mission if it has one, but all the benefits of mutual support are gone. Cooperatively patrolling a large area to split up areas? Nope. Efficient fire coordination? (“You shoot bandit #1 and I’ll take #2”) Forget about it. Even worse, it now has to be really careful with anything that shows up on the scope. Is that new contact a friendly or an enemy? You’d better hope its RoE and doctrine settings take such a situation into account – or prepare for blue-on-blues!

Meanwhile, Garry is now alone and trying to adjust to the sudden loss of SA from the nearby AWACS. Notice the only contact still “fresh” is the one that the F-15 is actually detecting on its own; the other contacts, hitherto provided by the E-3, are now deteriorating fast.

Units that lose their comms connectivity retain local copies of the contacts that were available to them before they went offline; essentially they inherit a snapshot of their parent side’s theater picture at the moment of their breakaway. However, without the benefit of information exchange with their parent network, this snapshot immediately starts to lose its currency and most of the contacts will soon vanish unless refreshed by the unit’s own sensors. (It’s like walking down a busy street, taking a last look around and closing your eyes. The longer you remain blind, the less relevant & useful your last memory will become.)

Units that manage to get through their “isolation” and re-join their side comms network share their contact information. You can use this to model things like film-return satellites (the Russians still use them!), a submarine sharing its intelligence take after rejoining its battlegroup etc. If the parent side already has these contacts, the updated information (including BDA – very handy!) is merged and used to refine the contact information.

As mentioned, the player has no control over his “disconnected” units. However, playing out a scenario in ScenEdit mode (which is essentially “cheating” but also very useful for analysis) affords an additional ability: To literally jump into the cockpit/CIC of the isolated unit and experience its “loneliness” first-hand (Editor –> Isolated POV view. This menu selection is only available when the “Comms Disruption” feature is enabled for the scenario). This is an excellent way to understand how a comms-isolated unit perceives its environment and reacts to it (which is usually quite different from when it operates as part of an integrated network). Quickly switching between “side-wide common picture” and “isolated POV view” can be a real eye-opener as to the value of a well-connected battleforce and the hazards and challenges of “comms off”. It is simple enough to say “we’ll not transmit so the bad guys cannot sniff us out”. But how well can you really fight in the dark?

Living with vulnerable comms

During the course of our internal testing, we realized players using this new feature will probably have to adjust to a different mindset as well as absorb the new options it affords them. A few random thoughts:

Non-kinetic options are now significantly more expanded. Forget jamming radars; now you can do some real sneaky tricks. It is remarkable how much more brittle and inefficient, say, an IADS becomes when you can selectively take any of its critical nodes offline. Michael Scofield would _love_ to be able to brick the guards’ phones during his break-out/break-in escapades. Put another way: Going ultra-stealth or swarming cruise missiles over every radar & SAM site are no longer your only, or even your best options.
An initial tempting thought was to freely use comms disruption as a standard built-in feature to all existing scenarios. We soon discovered, in hilarious ways, how this can wreck scenarios that were not designed with this factor in mind. As an example, in the standalone scenario “Duelists”, we “flipped the switch” on the Soviet surface group just to see what would happen. Because the group had a standing “forbidden zone” around it that automatically marked violators as hostile, and in combination with very liberal “shoot first” ROEs, the ships in the group almost immediately proceeded to blow each other out of the water with righteous fury, with even a distant Oscar sub joining the action with its beastly antiship missiles. It really was blue-on-blue in its most pure, raw form.
Apart from the obvious step of making this new feature optional so that existing scenarios can function as before, we also added a lot of “reasonable smarts” to the AI crews so that events like the above Soviet shootout were less likely to happen. So for example, when detecting a new contact close to where a friendly off-grid unit was last known/reported, the side-wide AI is now a bit more careful even if the new contact is a violator of a forbidden zone (“easy on the trigger, guys… maybe it’s Garry after all”). Likewise, cut-off units compare their new contacts with the most recent datum of their known comrades and will ignore contacts that seem to be right on top of where their buddies were when they last heard from them. After putting together such refinements and re-trying the Duelists test, the isolated Soviet units were now significantly more restrained on how they prosecuted sudden new contacts after their breakaway.

(On the flip side, if you are the one creating the chaos, this creates excellent “false flag” opportunities for exploiting it. For example, if you can swiftly and unobserved dispatch comms-isolated units that are part of an enemy distributed force, the longer you can remain in their general location the longer it may take for their friends to get suspicious of you. Cloak and dagger fans rejoice!)
Comms vulnerability really drives home the dirty little secret of most network-based CONOPS. People talk about swarms, distributed lethality and all the rest of current jargon – but all of this assumes reliable communications.
This also reinforces the importance of sufficient individual capability: A modern warship, even when comms-isolated, is still a powerful unit. It has a fair chance of accomplishing its mission even without the obvious benefits of cooperation with its consorts. On the other hand, a “swarm” unit (be it a small speedboat, a drone etc.) that relies on the “my strength is in the pack” principle? Take comms off and its power drops precipitously (it is not an accident that comms-jammers are rather more favored for counter-drone defence than hard-kill measures).

Some other scenario-editing ideas for taking advantage of this feature:

Special actions, with units on the opposing side getting their comms knocked out. This is used to simulate a computer network attack, but could also represent saboteurs physically disrupting the comms network.
A “unit enters area” trigger where a friendly unit representing a jammer (ie, an EA-6B Prowler or similar) arrives on station. The script is fired, and representing its jamming capabilities, units on the opposing side have their comms taken out.
A “unit enters area” trigger where run-off the mill friendly units get their comms knocked out, forcing them to continuing prearranged missions or move aimlessly in circles until they run low on fuel and return to base. This, especially in earlier-period scenarios, simulates units outrunning their lines of communication. It can also be used to simulate submarine operations.

Looking forward

Further improvements to the comms-disruption feature are already planned and underway, but most of them are currently restricted to the Professional Edition. In the meantime, it is obvious that this feature represents a huge step forward in modeling the intricacies of modern operations, and scenario authors are likely going to have a creative blast with it just like with other existing features. What are YOU going to do with it?

Tags: no tags

« Previous Page — Next Page »