The new features of Chains Of War: Communications disruption

April 15, 2017 · Posted in Command 

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

The US Navy’s vision for modern operations. What happens if the data pipes break?

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.


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”:image
    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.

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?


Leave a Reply

You must be logged in to post a comment.