This is a small patch that was released to fix the settings deployment bug. A few other things we were working on made it in too.

• Fixed a recently introduced issue that caused particular settings to be overridden on launch.
  
• Units far from the epicentre of a Shockley impact are now stunned sooner, to match the explosion visual. Which units end up stunned is unchanged.
  
• Added a cracked ground impact scar for Quake.
  
• Fixed inverted track stretching for, eg, Paladin.
  
• Moving a block in a factory production queue no longer re-applies the multiplicative key modifiers.
  
• Fixed the commander selector ending up off the edge of the screen on particular scaling settings when shifting from windowed mode.
  
• Simplified window resolution switching code to try to make it more reliable.
  
• Fixed sun and water settings overrides being too persistent between maps.
  
• Fixed the sun on Tempest.
  
• Fix thumbnail and minimap images for maps containing unusual characters.
  
• Fixed a bug caused by map searches finding no maps.
  
• Fixed the player name tags widget possibly being assigned incorrectly.
  
• Tweaked the draw order of name tags, health bars, and overhead icons.

Zero-K units are generally quite simple, with many of them designed around a single weapon or ability. The idea is that the complexity of an army should come from how it combines unit types, rather than having any individual unit be particularly complicated. I call this the principle of atomic unit design, because it characterises units as the building blocks of armies, and simple units are, in a sense, indivisible. Simplicity is a good enough goal on its own, but atomic unit design also has an important role in fighting monospam.

Monospam, i.e. spamming a single unit type, can be a contentious issue in RTS. Many players consider such a strategy "unfair" or "cheap", and games are often designed to discourage it, including Zero-K. This makes Zero-K a bit unusual within the Total Annihilation lineage, since TA had a bit of a reputation for monospam, and many successors dealt with it by culling the "excess" units. Zero-K went the other way, and found ways to balance a large unit roster without the resulting monospam. But before we get to that, we need to pin down what makes monospam powerful in the first place.

Monospam derives a lot of its power from being easy to manage. The logistics are simple. Just set your factory to repeat-build Scorchers, spam Ctrl+Z to keep them all selected, then repeatedly hit your opponent with them. The Scorchers move at the same speed and want to fight the same types of battles. But mix in more unit types, and it becomes much more complicated. Even maintaining the right mix is a challenge, since different units often die at different rates, and reinforcements take time to reach the fight. A mixed army that loses most of one type has to wait for the build ratios to be adjusted, while monospam can rely on a constant stream of appropriate reinforcements.

To skew things further, mixed armies are as bad as their weakest unit across many attributes. For example, mixed armies move at the speed of their slowest unit, and are as vulnerable to attrition as their most fragile. Consider an army of tanky Minotaurs and glass cannon Ogres. Such an army is either going to lose a lot of Ogres, or it is going to avoid taking fights that Minotaurs would weather without hesitation. In many situations, half an army wants to fight while the other half wants to run away. None of this is an issue for an army of a single unit type, with uniform strengths and weaknesses. Essentially, most units synergise best with themselves.

So, why do we want to discourage monospam? In short, because there is no crunch in easy decisions, and Zero-K is largely about deciding what to build and how to use it. This is much more involved when dealing with multiple unit types, both on your side and in the enemy army. And, as mentioned previously, the goal is mixed armies of combat units. Mixing battle tanks and anti-air is fine, but the tactical goals for such an army are often quite simple, depending on the type of enemy that is coming at you.

Now that we know what makes monospam powerful, how can we avoid it? The first principle is that mixed armies are 'allowed' to be much more powerful than monospam. My gut says 1.5-2x as powerful, but there is no definite value. The principle is great for guiding balance discussion though. For example, say we are thinking about how Rover might counter Fencer. Scorcher is a decent suggestion, but then some theorycrafter objects that Scorcher is solved by mixing in a few Rippers. At this point, we can invoke the principle, and say that Scorcher losing to a mix of units is fine. Forcing your opponent into a mixed army is half the battle, with the other half being to wait for them to succumb to the extra complexity. So we are free to focus on whether pure Scorcher beats pure Fencer.

Likewise, the second principle for avoiding monospam is that everything needs a hardcounter. It is not enough for a unit to have bad matchups, it needs some absolutely terrible ones. This because straight-up cost-for-cost fights fail to take logistic and self-synergistic advantages into account, and such fights in a vacuum are an important part of judging counter relationships. So any unit that manages to not lose too badly against anything is a prime candidate for monospam. This is not to say that hardcounters have to feature prominently in how the game plays, they just have to be lurking in the background, threatening players with annihilation if they invest too much into one unit type.

This is where atomic unit design comes into play. A unit that does one thing well tends to have weaknesses everywhere else, so must rely on other units to cover those weaknesses. Atomic unit design is not a strict rule though, as it often fights the Rule of Cool. This is a hard fight, especially when big units are concerned, but we still try to keep the abilities of complicated units pointed towards the same purpose. Sea has struggled the most with the Rule of Cool, since ships want to have multiple weapons, and the disparate weapons of Siren are a remaining nod in that direction. The worst offender was Envoy, which used to have a depth charge that acted as inbuilt riot support against anything on or below the water.

Factory abilities further dilute the idea of atomic unit design. If you count things like personal shields, jumpjets, and spider legs as abilities, then a lot of units have two abilities; one weapon and one utility ability appropriate to their factory. However, this extra complexity is well worth it, as having an ability in common strengthens the feel of factories as cohesive factions. The same could be said of, say, Zerg Burrow. Besides, a "faction ability", one shared by many units, has a much lower complexity penalty than an ability that arbitrarily exists for a single unit.

Atomic unit design also applies to structures. For example, Complete Annihilation had a few types of metal extractor, including an armed metal extractor. This structure was not atomic since it had two distinct abilities, metal extraction and a laser turret, so it was removed in favour of the more interesting method of defending a metal extractor: just make a Lotus. This confers all the subtlety inherent in atomic units, A turret might be built forwards to better protect the mex, or in a more defensive position and use the mex as cover. A weak raiding party might have to choose between killing the turret or the extractor. Armed metal extractors provide none of these decisions, approaching one is the same every time, and a fight with one only has two possible outcomes.

Commanders, being the opposite of simple, are a constant thorn in the side of atomic unit design. They are upgraded a bit like a composition of units, with each module adding a single weapon or ability, but fight like a single unit. A high level commander is akin to a one-unit monospam, with all the logistic simplicity and self-synergy, so it needs strong counters. This is hard to square with the feel of commanders, but that deserves its own whole article.

By now you might be wondering, is this all just Quant's Rule? Yes and no, I would say that the ideas are complementary. Atomic unit design is more of a goal than a method, while Quant's Rule is not so strict about how many strengths a unit can have. Quant's Rule guides us through day-to-day balance changes, while atomic unit design is more holistic. Waffling aside, it is mostly just useful to look at things from multiple directions, and it should not be surprising that many of the principles behind Zero-K lead to the same place. So stay tuned for the third I can't believe it's not Quant's Rule article, where I expect to cover Moonwells and the nature of greed.

Index of Cold Takes[zero-k.info]