How many factions are there in Zero-K? I get asked this from time to time and am never quite sure how to respond. It looks like a simple question with a simple numerical, like two or seven, but it is actually quite complex. The questioner may not stick around for the full answer, and I might not have the time to give one, so what am I to do? Finally I have the solution: just link this post.

Strictly speaking, Zero-K has one faction, but in many ways it has somewhere around eight to eleven. Many parts of the game are designed to satisfy most of what people want from factions, and it is these desires that lead to questions such as "how many factions are there in Zero-K?". This is why I have such trouble just answering "one", as it gives the incorrect impression that we have nothing to offer people who like games with many factions. The faction-like entities of Zero-K are the eleven factories that produce most of the units in the game.

Here is a quick overview of factories.

• There are eleven factories: three for walker robots, two for vehicles, one for spiders, two for amphibious units, two for aircraft, and one for ships.
  
• Your first factory is built for free, instantly.
  
• The land and sea factories have enough variety to see players through to at least the midgame.
  
• The air factories are designed to support the other factories.
  
• Factories are expensive enough to dissuade people from building extra factories until the midgame.
  
• Production rate is best boosted by assisting with constructors, using construction turrets, or adding cheap parallel production plates that depend on the main factory.

Essentially, a factory is a technology structure that unlocks a "faction" of approximately ten units, and these "factions" are designed and balanced in much the same way as a faction from any other game. This has been called a soft faction system, since players start the game with one faction, but are free to dip into any others later in the game. It is similar to the way factions work in card games like Magic: The Gathering or Android: Netrunner, which have both distinctive faction and flexible deckbuilding systems that technically allow any two cards to appear in the same deck. Zero-K has a similar sense of factions, with the big distinction being that the decision to dip into a faction is made during the game itself.

I would like to go into the history of how factories as factions came about, and will some day, but it touches too many parts of Complete Annihilation to cover in one post. For now just know that CA had two factions, and that Zero-K was born from the idea of condensing them into one. The original motivation was to reduce the amount of art we needed, but the idea quickly grew into a design direction that was justified in its own right. This justification is just as valid today as it was back then, so I can cover it without too much background. Then, when it is time for the background, I can refer to this post. There is a plan here, so it might not surprise you to hear that the two pillars of factories as factions are Quant's Rule and avoiding fights between the player and the UI.


The two factions of CA, Arm and Core, go back all the way to Total Annihilation, and they had quite a lot of overlap. Faction diversification was a major goal of CA, and we were making good progress by applying Quant's Rule across the game as a whole, as well as by adding new faction-exclusive mechanics
(such as area shields and cloakers). There was a limit to this though, since each faction needed access to everything required to play a full game. It is also hard to differentiate factions without creating powerful cross-faction combinations, since differentiated factions naturally cover each others weaknesses. This was particularly evident in team games, since each team almost always had players of each faction. Any difficulty in coordinating the units from different factions was just considered a UI limitation. So the principle of avoiding fights with the UI was telling us that team games already has a single faction - the full unit pool of the game. Worse, this faction still had very similar Arm and Core versions of many units, which goes against Quant's Rule.

The Nuke Silo is a good example. Core, being all about brute force, had a larger and more expensive nuke than Arm. We could try balancing each into a distinct role, but there is a limit, since both factions need a full set of lategame options for when they are played on their own. A Core player might decide the team needs an Arm nuke, but to build one they have to ask a teammate to share a constructor, which is a terrible situation as few people play RTS to fiddle with the unit transfer UI. Situations like nuke occurred across CA. mostly for structures, but also for many staple units as such as the basic Raven-like bomber or the Ravager-like assault vehicle. In each case we either gave each side a perfect duplicate, which works for Wind Generators but is a bit unsatisfying for nukes, or we end up with a Quant's Rule violation plus the possibility of fighting the UI.


Most issues caused by factions were avoided in 1v1 since each side was truly only Arm or Core. In fact, condensing the factions was seen as an improvement for 1v1, rather than a fix, as condensing the faction would allow for a wider range of factory designs. In CA the capabilities of Arm and Core had to be fairly closely balanced, since one being clearly better on a particular map type would be unacceptable. So CA had four choices of initial factory in 1v1, a bot and vehicle factory for each faction, but each of bots and vehicles had to behave fairly similarly across the factions. It was not so bad that it felt like only two options, but it did not feel as diverse as a full set of four options either. Simultaneously balancing factories individually and across the factions was restrictive, since anything added to one faction needed some sort of equivalent in the other. With Zero-K we removed the restriction of factories fitting into a larger faction, so we were free to design each factory independently. It took some time to get here, but it paid off, as we now have eight land factories, each more unique than anything seen in CA. Players certainly treat the factories like factions, arguing about their viability and complaining about particular matchups, just as they would for factions in any other game.

The remaining PvP game mode, free-for-all (FFA), was wild, and we might have lost something here by treating factories as factions. Might. I remember a match that soon turned into a 3-way Core-only game on Comet Catcher, between Saktoth, det and I. As Core we had shields, but lacked the EMP weapons to break them. The game was at least three hours long, Zenith was not enough, and approaching the shields stealthily was not an option either since area cloaking was Arm-only. I forget who won, but there was a turning point when det found and resurrected an Arm constructor from a defeated player. I have fond memories of this game, but largely because it was exceptional. Most FFA games were played with all the units, since Arm constructors could capture and Core constructors could resurrect. Saktoth summed it up in a thread about condensing the factions.

I just played a FFA where i started core ships, went core walkers, lost both those factories, ressed an arm con, went arm tank for a while and was down to a single Freaker for core tech. Made core tank factory, lost my arm tank Factory to nuke, played core tank for a bit, got an arm air con, made an arm shipyard, lost my core tech entirely, took over the sea, made an arm air plant, and captured a core hover con for the grand finale where i built a zenith.

The factory diversification enabled by merging Arm and Core was unexpectedly beneficial for team games. There are now enough distinct "factions" for each player to feel like they have something unique to contribute. Consider a large team game on a wide open map. In CA, most players would play Arm or Core Vehicles, with some air support, and maybe a few playing bots. In Zero-K, the most straightforward options are Rover, Tank and Hovercraft, which already feels nearly three times as diverse as Arm vs. Core vehicles. There are even more options though, as Cloakbot and Shieldbot work well anywhere, and there are niches for the remaining three factories to fill even on a wide open map. In general, any of the ten factories feel viable (eleven if there is enough water), which makes it highly unlikely that the players on any given front end up in a mirror match. It feels good to be one of the few players in a team with your set of units, it gives you a distinct role, and this is most of what I want from factions.

The UI has also benefited greatly from treating factories as factions. Giving every constructor the same set of build options is amazing, it just solves so many UI problems before they arise. The build options are always in the same spot, with the same hotkey, and players no longer have to hunt around to find the right constructor to build what they want. Admittedly, condensing the factions also bloated the build list since we could not bear to discard the unique turrets. But I am sure many people see this as a benefit as well.


I sometimes worry that continuing to remove UI limitations will eventually remove the faction-like feel that we have managed to create. Factory plates were particularly worrying. These are a recent addition that lets players make cheap extra factories of the same type, using the main factory as a sort of tech hub. Factory plates can be placed for allied factories, as anything else would be a UI limitation, which makes switching into the factory of a teammate much easier. Thankfully, the faction feeling survived, and if factory plates are unable to kill it, then perhaps nothing can.

There was opposition to factories as factions at the time, with some people even predicting that it would kill the game. Their main concern was that we lost the benefits of overall faction identities, the way a set of factories for Core or Arm that share design elements. People weigh things up differently, but I think this was a fine price to pay, and it has worked out better than anyone could have predicted. At this point we would not split Zero-K back into two factions, even if the art required for the extra structures magically appeared. I think Zero-K is about creativity, and stopping players mixing and matching units from any set of factories feels like it goes against that. This is before considering all the Quant's Rule violations and UI fights that splitting Zero-K would generate, and the fact that CA team games were secretly one faction all along.

Again, apologies for glossing over the history, but this felt like enough for one post. It does create the opportunity to play a game in the comments though: try to guess the original faction of Zero-K units, using TA, BAR, or anything in between as a guide. Remember, the faction "Zero-K Exclusive" is an option, and to give a hint, if that were a faction of old CA, then it would be ridiculous and barely playable.

Index of Cold Takes

Many players mention Zero-K's powerful controls when asked what they love about the game. Some even joke that we spoilt other RTS for them. By now there are a few other games with parts of the Zero-K suite of controls, but I know of none that are driven by the same underlying principle. That principle is "Fight your opponent, not the UI (user interface)", and it goes back to the early days of Complete Annihilation. It is as central to Zero-K as Quant's Rule and was possibly coined by Saktoth, an early developer who liked to cite it.

A player is "fighting the UI" when they have a clear idea of what they want their units to do, but the controls make it difficult to tell their units to do it. Zero-K tries to resolve this fight, this conflict between the player and UI. This involves eliminating busywork and making simple ideas require few clicks to implement. The principle is the antithesis of things like clicking every 12s to build a worker, or routine frenzies of active ability targeting. At its most extreme, the principle advocates for a direct telepathic link between the player and game, removing all intervening interfaces. Putting aside the current state of psychic technology, other design goals prevent us from going that far.

The principle is not about removing micromanagement, as the 1v1 community can attest, Zero-K can be fast and frantic. Rather, it is about giving each click as much meaning as possible. Consider line move. Spreading units out along a line requires many clicks in most games, since numerous subgroups have to be selected and told where to go, while in Zero-K a line takes one click. If an "average line" takes 10 clicks to create, then each of the clicks has 1/10th the meaning of the one click required in Zero-K. The effect of this efficiency is not that Zero-K players click 10x less, but rather that they can be 10x more expressive with their unit control. This capacity feeds back into the rest of the game. We can expect more expressiveness from players, so the the game can be that much more nuanced as a result. Basically, Zero-K made surface-level micro easier and found more interesting micro underneath.


We need a more precise definition of UI to know exactly what is being fought. This involves drawing a distinction between the game world, the abilities units use to affect the world, and the UI itself.

• The game world is everything that describes the state of the game. This include the state of the terrain, the position of all the units and their statuses, and global things such as metal storage and innate income. Fundamentally, a game¹ is some number of players trying to manipulate the game world into a state which counts as victory.
  
• An ability is any action that may be taken by a unit. Jumpjets and Swift boost are abilities, but so are moving, firing, and building. Players indirectly affect the game world by having their units use abilities. Characteristics such as health and sight range are part of the game world, not abilities, because they are innate.
  
• The UI shows the player a summary of what their units can see, and players use the UI to tell units to use abilities. The UI is their eyes, ears and hands, players never see or touch the game world directly. The UI also has its own states and can show them to the player. For example, command queues are not abilities or part of the game world, they are owned by the UI.

Chess provides a nice example. The game world of chess is an abstract list of piece positions (plus things like the draw timer), the abilities are the ways pieces move, and the UI is the physical chess board and pieces. Distinguishing between these three parts of chess makes the concept of a UI sound a bit silly, but that is the whole point. People rarely consider the "UI" of chess, since strategy stays the same regardless of whether the board is made of stone, wood or plastic. Chess players already fight their opponents, not the UI (except in blitz), so it fades into the background. This is foreign to RTS players, who seem to love arguing about UI.


The key difference between chess and an RTS is that chess expects the player to perfectly micromanage everything their pieces do. At the risk of heating up this take, chess is only a sedate game because very little happens. Strictly speaking, every step taken by a unit counts as an ability, so more abilities are used in the first few seconds of an RTS than in an entire game of chess, and games only gets more complex from there. RTS UIs have to filter and aggregate these abilities since the game would be impossible to manage otherwise. Turn-based strategy players might be aware of this issue, as these games sometimes end up in an awkward spot between RTS and chess, with too much to do each turn relative to the tools provided by the UI. At least RTS designers have a hard real-time constraint, whereas designers of turn-based games have to deal with the more nebulous constraint of the player's patience.

The filtering applied by RTS UI has a significant impact on the feasible actions within the game. Consider line move again, if it were suddenly added to a game, then area of effect damage would be much worse. Or to flip it around, poor area of effect damage was being propped up by a UI that made it difficult to split units. Fights between the player and the UI bias strategy away from a pure expression of what units can achieve with their abilities. and this bias is often particularly strong for new players, which can delay how long it takes for someone to start playing the "real" game.

How many people remember looking for Starcraft II advice and being told to focus on macro (Starcraft speak for micromanaging the economy)? People were basically told to fight the UI before even considering fighting their opponent. That said, fighting the UI is fine, it is a preference. Many games and genres are built around it. The solitary battle between player and UI can be rewarding, and has more reliable progression than fighting opponents. Zero-K is just the crazy project that asks whether the fight is necessary in RTS. Can we have fast, real-time, action in a strategy game, without a UI that new players have to overcome, and which avoids biasing strategy?


Time for some examples. Back in the early days of CA, Lurker and I talked about the disguise ability of the Spy from Red Alert 2 (which appeared later as the Changeling in Starcraft 2). Enemy Spies look like your own units, but are not actually under your control. We decided that disguises just create and then exploit a conflict between the player and UI, so they never made it into CA. The argument was that, since Spy is only controllable by its true owner, a powerful UI could constantly attempt to control every unit that seems to be yours, and flag any that refuse.

A mechanic that did make it in to CA, briefly, was radar spoofing. This was an ability that generated fake radar dots. The problem was that players were pretty decent at spotting fake radar dots after a bit of observation, but there was no nice way to tell this to their units. Players were forced to work around their units constantly firing at invulnerable radar dots, revealing their positions and wasting reload time. We could have solved this conflict by giving the player more powerful tools to fight the UI, but what would be the point? The fakes were fairly easy to spot, so we would be putting in a lot of work to end up with basically the same game. A Red Queen's Race against ourselves.

By now we have seen two approaches for solving conflicts between the player and the UI. The first is to make the UI more powerful, such as with line move. This gives the UI fewer ways to get in the way of a player trying to tell units how to use their abilities. The second approach is to remove conflict at the source, as we did with radar spoofing, or to avoid creating it altogether. This barely looks like work from the outside, so whenever we considered adding a mechanic we tried to imagine what perfect play would look like. If the game seemed like it would be worse, or not change at all, then the mechanic would be rejected. Sometimes we would come across mechanics that seemed good, but which would require a lot of UI work to deal with new conflicts. In these cases we would try to tweak the mechanic to put less strain on the UI without otherwise modifying its effect.


So far you would be excused for thinking that we simply figured how the UI should work, then implemented it. This is far from what happened. The principle itself was put in place fairly early, but it served more as future proofing than as an action plan. We did not know how powerful the UI could become, only that we were ready for it. This meant avoiding designing new conflicts, and assuming that existing conflicts would be solved eventually. We had, and still have, an open approach to players modifying the UI, with the expectation that people share anything useful. Sometimes an advance in UI causes a problem, but we approach these cases with the idea that powerful UI just reveals issues with game mechanics, so strive to fix the mechanics.

It took over a decade for the UI to reach its current state. Overkill prevention was only added in 2015, and anti-bait was as late as 2021. These were not small changes, but they still failed to upset the overall balance and design of Zero-K that much. Admittedly, Lance has been nerfed since then, but prior to anti-bait players were still using Hold Fire to manually snipe commanders, so it was already using its abilities well when doing so mattered most. Artemis has not even been nerfed since it stopped wasting shots on Gnat. This is because Artemis was bad for quite a while, but being bad was better than the alternative. We try to balance units under the assumption that they use their abilities well, because otherwise we would have powerful but unwieldy units enticing players into fights with the UI.

In the end, Zero-K was never going to reach the level of control characterised by chess, but we have found fertile and relatively unexplored ground along the way. Powerful controls (hopefully) make the design resilient to players improving at micromanagement, and basic unit intelligence eases the difficulty of balancing for both new and experienced players simultaneously. The "opponent" part of "Fight your opponent, not the UI" is a bit of a misnomer though, because the principle is really about closing the gap between what players can tell their units to do, and what their units are really capable of. The idea can be extended to games without opponents, and even to games without units.

The principle touches every part of Zero-K, from the economy to the tech tree to movement mechanics. It is also at the centre of a few ongoing questions, such as how good units should be at dodging projectiles. If this post seems a bit light on detail, worry not, because this principle is going to come up throughout the rest of this series.

Index of Cold Takes


P.S.
This did not fit in the main post, but my thoughts about UI were refined by Achron, the time travel RTS. I started playing Achron from the end of 2009 and it handles the UI in a very interesting way. In Achron the player is a time travelling commander, jumping around and giving orders throughout time. An order given in the past costs a global resource, "chronoenergy", and has a continual effect on the timeline by activating whenever a parallel world "hits" it. The details are complex, and a lot of can be done with this system, but the important thing for now is that the order exists in the game world. But if that is the case, where is its UI?

Commands in Zero-K are not part of the game world. They are UI constructs used to track which units are going to be told to use which abilities. But the commands in Achron work differently, so it actually has a very simple UI, which led me to make some weird feature requests. One of my requests was a way to delay issuing a command, because this could be used to save chronoenergy. Essentially, a sort of "command queue" of commands to queue later. Trust me, a desire for this sort of "meta-UI" makes sense with time travel. A similar thing happens with the Psychic Sensor in Red Alert 2 (mark your bingo sheet). Once you see the distinction between UI, abilities, and game world, you start seeing it everywhere.

¹ This includes singleplayer games, but not games without intrinsic victory states. There is probably more to say about games in general since most games have some form of goal, but that is beyond the scope of this post. I am talking about strategy games, and possibly even any game where challenge is one of the primary engagements.

The Blastwing rework continues, with most of the feedback suggesting it dealt too much damage, although a few edge cases in its behaviour have also been fixed. There is also an overdue Corsair buff and tweaks to make Disco Rave Party less fiddly. The big feature is a command to split large autohosts with many waiting players, so everyone gets a game, and the big graphics update is darker, faster, and better looking "terrain" beyond the edge of the map.


Blastwing gained more damage than it needed to in the recent rework.

• Health 100 -> 80
  
• Speed reduced by 5%, which also reduces bomb toss range.
  
• Damage 320 -> 300 -> 280 -> 250
  
• Burn time 24s -> 14s -> 12s

Corsair is even better against Hunter and can stand up to Siren.

• Health 1350 -> 1500
  
• Speed 81 -> 90
  
• Range 293 -> 300
  
• Spread 1500 -> 2500
  
• Damage increased by 18%

Disco Rave Party no longer innately loses spin while turning.

• Instead, DRP now turns slower at high spin. There penalty ramps up from none at 50% spin, to 3x slower at 100% spin.
  
• DRP now has unit AI that voluntarily reduces spin to turn faster. The AI optimises for time taken to turn then spin back up to 100%.
  
• Reduced maximum turn rate by 25% to compensate, and to make the optimisation work out.
  
• This DRP should be much easier to control since it will spin up to a high minimum, and stay there unless large turns are required. Minor shifts such as radar wobble no longer reduce spin.
  
• Advanced DRP users also have more options. A 90 degree order can be issued to make DRP turn ASAP, or Alt+Ctrl+Shift attack can be used to drag 1-shot orders to walk slowly through the enemy base if punctuality is not a priority.

A new command, !split, is now available in large teams autohosts.

• Anyone can do a !split when at least 40 players are waiting (so at least 8 are on the waiting list).
  
• The command sends 40% of the lobby to a new autohost, so everyone has a chance to play.
  
• The top rated players are sent to the new host, to give everyone more evenly balanced games.
  
• The uneven split is an experiment. Experience suggests it will create more games. Send feedback.
  
• Everyone needs the update for this to work smoothly, so the first day may be rough if players don't restart to get the update.

• Added Battle Value Tracker, a widget that tracks kills and losses in engagements as they happen (thanks citrine). It was useful for Blastwing. Enable under Settings/Interface/Battle Value Tracker.
  
• Reworked the offmap terrain. It is now a dark opaque grid of uniform squares that match the resolution of the terrain, rather than a stretched texture. It also costs less performance.
  
• Language can be overridden locally by copying files from the repository to LuaUI/Configs/lang.
  
• Added minimap preview tooltip.
  
• Enabled https for all external zero-k.info links.
  
• Update Italian, Polish, and Chinese/Taiwanese translations.
  
• Brightened first ally blue (in a previous patch).
  
• Improved thermite and flamethrower effects (in a previous patch).

• Fixed various issues with Blastwing having trouble finding a place to land.
  
• Fixed Blastwing overshooting when told to attack something at the base of a cliff.
  
• Odin can no longer fire without ammo while touching down or sitting on a rearm pad.
  
• Cerberus now aims even when its current muzzle position is blocked.
  
• Reduced Cerberus and Lucifer hitvolume sizes, to keep them within their footprints.
  
• Lobster throw indicator no longer highlights structures and aircraft.
  
• Fixed Raise tooltip values for blocking vehicles and bots, and tweaked Alt snap to match.
  
• Removed Odin's redundant reload bar for its shield cluster.
  
• Fixed invalid events in action tracking camera.
  
• Particularly quick double-click-drag selections no longer ignore selection rank.

"Buff strengths, nerf weaknesses." - Quantum, Lead Developer of Complete Annihilation (CA)

Quantum devised the rule above early in CA history, perhaps as early as 2007, and it is still at the core of Zero-K. I don't know exactly when, or even if, Quantum said the rule in its eventual form (I wasn't there right at the beginning). However I do know that Quantum was the lead developer (he responded to the ticket "Your lead developer is a nub" on the issue tracker). In any case, the rule is responsible for keeping the 100 or so units in Zero-K unique, useful, and interesting.

Quant's Rule is about game balance, and vitally it is an active rule rather than an abstract principle. It tells us what to do when a unit is to be made weaker (nerfed) or made stronger (buffed). It was devised to guard against the concern that a balanced game is a boring game. The validity of this concern is up for debate, but if you play enough RTS you will see both extremes. At one end there are games with many exciting tools which barely feature in viable strategies. At the other end there are games that seem balanced, but at the expense of any interesting unit variation.

Original Total Annihilation was towards the "zany but imbalanced" side of things, with tonnes of units, but few that turned out the be viable. Many games were like this in the late 90s. You might say that viability is only a concern for hardcore competitive players, but we think it matters for anyone who really wants to puzzle out the game. In other words, to strategise. No matter the game mode, it is a bit disappointing when the unit roster effectively shrinks as your understanding grows. Some TA mods tried to address this with balance overhauls, and Complete Annihilation comes from that lineage, so the question of how to balance many units was front of mind.


Take Lance as an example of Quant's Rule in action. Earlier this year it was identified as a bit too powerful, so needed a nerf. As per Quant's Rule, its weakest aspects were the first candidates for potential changes. We kept those candidates in mind while discussing and reviewing replays, watching for ways to make them worse that would affect its overall performance, without making it feel terrible to use. Other attributes may be nerfed, but not its main strengths, so Lance was extremely unlikely to lose any of its impressive burst damage. In the end Lance was mainly nerfed on cost and reload time, which are both significant weaknesses, with minor nerfs to range and speed.

Stepping back, what even is a strength or a weakness? It seems like a silly question, but consider that units are made of numbers, and no number is objectively "weak". The answer is that strength is relative, based on comparisons to other units, but here is where it gets interesting. Units can be compared within roles, across roles, across factories, or even across the entire game. There is flexibility here, and it is where unit roles and factory identity are taken into account. Were the minor range and speed nerfs for Lance appropriate? On one hand, artillery is slow and and long ranged. But on the other hand, Hovercraft are fast and Lance has below average range for heavy artillery.

Which attributes are sacrosanct varies by unit and role. Consider Bandit, the Shieldbot raider. As a raider, Bandit is one of the fastest units in the game, but within raiders, Bandit is one of the slowest. The interplay of speed between raiders is vital, which causes Bandit's speed to be judged as a weakness. This means Bandit is very unlikely to receive a speed buff, just like how Lance is not going to have its damaged nerfed. As an aside, Bandit is not going to have a speed nerf either due to another rule dating back to CA.

Bandit Rule: Raider speed is at least 90 elmos/second.

There is a subtlety to Quant's Rule that highlights the difference between balance and design. A designer is like an architect, with a high level idea of how units should feel and interact. The balancer is like a builder, implementing the details of a design, finding numbers that make units behave as they should. The same people often do both jobs, but the mindsets are different. Quant's Rule is a guide for those deep in the weeds of balance, where things are made much simpler by not having to simultaneously think like a full designer.


As a design principal, Quant's Rule is about giving units space to be unique. Consider the design space of units, like the plot above, but with many more dimensions for things like health and cost, as well as for fuzzier attributes like firing pattern. Then realise that this is not a static space, for if Ronin were given more range then it would shift to the right. Balance patches bestow the space with concepts of "movement" and "force". Quant's Rule is a force that pushes units away from each other, since buffing strengths and nerfing weaknesses stretches units out along each dimension. This naturally expands the space, makes units more distinct. A more conservative, or directionless, approach to balance risks units gradually drifting towards each other into a black hole of banality. Quantum presumably saw such a drift towards the average as the default, and created a rule to counteract it.

As good as it might sound, remember that Quant's Rule is primarily about balance. You can interpret it as a design goal, but it works best when telling balancers which types of changes to prioritise, and which are off-limits. But sometimes, balance fails. This recently happened to Blastwing, which previously dealt most of its damage via ground fire, but just lost its ground fire and gained significant direct damage. This change would seem to violate Quant's Rule, if not for the fact it is a design change rather than a balance change. The change was a result of the balancer going back the designer, saying "Quant's Rule has been tried for years and Blastwing isn't working", and asking for a new design. It was then time to don designer mindset and teleport Blastwing to a new point in design space, because the balancer should not be expected to make long treks to more fertile designs by themselves. Almost all the units are in a good spot by now though, so these events are pretty rare.

It would be hard to claim that Quant's Rule is entirely unique to Zero-K. The formulation and centrality, perhaps, but similar ideas seem to have made it into other schools of game design. From time to time I come across mechanics or patch notes that have a definite flavour of Quant's Rule, and the games that do this regularly tend to be my favourites. It is also less demanding than I have made it out to be. In the end, it is a guide, and it is invoked less frequently as we improve at holding the balance and design mindsets simultaneously. It is still great for discussion between developers though, but only if we explain it to newcomers. Good thing there is now a 1000 word post on the subject.

Index of Cold Takes

This update adds fancy new flame effects, a Blastwing rework (it still sets things on fire) and a thermite bomb for Odin. It also has balance changes ranging from Metal Extractor to Disco Rave Party, and a bunch of features, fixes, and performance improvements from numerous contributors.


Blastwing always had a problem with chain exploding. The previous solution was low direct damage followed by high damage over time. This felt weak and niche. The new solution is to "safely" eject its bomb when it dies, rather than explode immediately.

• Cost 45 -> 55
  
• Increased deceleration rate by 60%
  
• Drops its bomb on death rather than exploding immediately.
  
• Direct damage 40 -> 320
  
• Explosion radius 144 -> 128
  
• Maximum unit-on-fire duration 1s -> 24s
  
• No longer creates area fire

Odin has its Disintegrator Bomb replaced with a Thermite Bomb. The disintegrator was prone to converting immobilisation abilities into delayed 1-hit kills, with too little counterplay. The new bomb deals damage over time in a small area, so a commander can be saved by preventing the second Placeholder shot, or with a nudge it if it is stunned. Thermite also hits shields, fully draining a few before it is blocked.

• Deals damage to everything in a small area around it over 30s.
  
• Damage ramps up over time, from 0 damage per second to 1000.
  
• Typical damage 8k -> 14k
  
• Its trajectory is blocked by obstacles, but continues on when they are "removed".

Claymore has a buff to fix the occasional distance-closing issue in sea,

• Seaborne depthcharge range 280 -> 300

Lobster is slightly less nimble.

• Relob time 12s -> 14s

Gremlin follows Toad by gaining enough vision to see the ends of its lasers.

• Sight range 660 -> 760

Jugglenaut and Detriment now decloak when they land, since they deal damage.

• Detriment already decloaked on launch, so this only really changes Jugglenaut.

Magpie hits more trick shots.

• Missile turn rate increased by 8.7%

Metal Extractor loses a bit of health so Blastwing can deal less damage.

• Health 600 -> 560

Picket is a bit cheaper to save us from Blastwing.

• Cost 100 -> 95

Disco Rave Party switches to comfortably outranging Zenith, but costs a bit more, and is much less accurate in high trajectory mode.

• Cost 42k -> 45k
  
• Range 7000 -> 9600 (Zenith is 8800)
  
• Projectile gravity reduced by 44%.
  
• Low trajectory spread at max range: Two Inferno diameters.
  
• High trajectory spread: Two Trinity diameters.

• Units that are on fire now look more severely on fire depending on the remaining duration of the fire.
  
• Added a fancy animated flame effect (thanks Anarchid and engine devs) which has been applied to all flamethrower and napalm weapon effects.
  
• Antinuke construction is partially paid back from team overdrive, in the same way as the existing energy construction system. The first antinuke constructed by a team gives the builders 50% of its cost back over the next several minutes, with the proportion paid back dropping by 10% per previous antinuke.
  
• Moved the settings from "Settings/HUD Panels/Spectator Panels" and "Settings/Interface/Spectating" to "Settings/Spectating".
  
• Added an automatic action finding camera for replays and live spectating (thanks fiendicus_prime). Enable it under "Settings/Spectating/Action Tracking Camera".
  
• Added a widget to display player names over a unit on screen (thanks fiendicus_prime). Replaces commander nametags, but has a commander-only option. Enable under "Settings/Interface/Player Name Tags".
  
• The units that will be thrown by selected Lobsters are highlighted when the command is selected (thanks dyth68). Can be configured under "Settings/Interface/Falling Units/Lobster".
  
• Fire special weapon now shows range rings for all selected units, like Force Fire (thanks dyth68).
  
• Commanders spawned to the same location now spawn next to each other instead (thanks Shaman).
  
• Added a small drag threshold for terraforming to make Ctrl+Click surrounding buildings easier.
  
• Added an Alt modifier to the selected units panel to select/deselect half of unit group.
  
• Added the secret Ctrl modifier to the selected units panel tooltip.
  
• Added more descriptive short descriptions for missiles built in the Missile Silo.
  
• Changed the default self destruct hotkey from Ctrl+D to Ctrl+K. Only affects new installs.

• The new fire effects replace the existing cegs "napalmfireball_200" and "flamer". Mods that use these cegs as a base should get the new fire effects. Use "flamer_cartoon" for old style flamethrower fire.
  
• Exposed weaponDefID, projectileID, attackerID, attackerDefID, attackerTeam to widget:UnitDamaged. Spectators see everything, while players only see attacker stats if the attacker is visible, and don't get weaponDefID or projectileID.
  
• Removed the special techniques required to give weapons zero damage.
  
• GG.CheckStartBox returns true if startboxes are disabled. Set the 4th argument to true to read raw boxes.
  
• Added "/luarules battle <file>" to spawn preset battles. The system could be extended to ease mass preset unit spawning.

• Blastwings told to fly quickly after landing are no longer stuck in their landing animation.
  
• Blastwings now have collision, like other gunships, to prevent them stacking on one location.
  
• Blastwing no longer cloaks mid air if it happens to come to a complete halt.
  
• Blastwings are now possible to use with area cloakers, instead of constantly cloaking and recloaking under them for no reason.
  
• Blastwings with a Force Fire order on the ground now explode, rather than just hang around.
  
• Blastwings told to attack a unit now consistently approach the unit and explode, rather than sometimes hovering next to it.
  
• Blastwings told to attack a moving unit now update their heading more than once a second, making them able to fly at and hit notoriously mobile targets like Lance.

• Starlight only deforms the map every 5th frame. It looks a little weird, but is better than people lagging out while we wait for an engine fix for the deformation performance issue.
  
• Fixed Paladin causing an unreasonable performance hit (thanks Porkch0p).
  
• More damage dealt by dead units, such as bomb damage, thermite and fire, shows up in the endgame graphs.
  
• Fixed spectators seeing the player-facing, hax free, unit damaged/killed midgame graphs, rather than the real ones.
  
• Fixed airpad exclusion orders with an even number of aircraft selected (thanks Helwor).
  
• Fixed giant Desolator death clone collision volume (thanks dyth68).
  
• Fixed bombers sometimes failing to automatically return to a pad when idle, especially after a Stop command.
  
• Fixed personal commander shield not having any regeneration.
  
• Flamethrower visuals no longer penetrate shields.
  
• Fixed the little generator ball effect on area shield generators not disappearing off when the unit is stunned.
  
• Fixed santa hat lighting.
  
• Fixed Storage XP.
  
• Fixed lighting on Small Divide Remake and LLTA Complex.
  
• Fixed passworded games of friends that exist when logging in sometimes not showing up in the battle list.
  
• Possibly fixed the occasional ghost or missing player in battle lobbies, often after returning from a game.

This is the first in a new series of design blogs about Zero-K. We aim to release one every two weeks, when there isn't a patch, and by 'we' I mean me, GoogleFrog (others might contribute later). Expect posts about Zero-K development, design, history, and whatever else comes to mind.

To start us off, why is Zero-K even called Zero-K? It started around 2009 when a mod called Complete Annihilation wanted to throw off the shadow of being "just another alphabet soup mod", the term for games on the Spring Engine that traces themselves back to Total Annihilation. The mod split off from Balanced Annihilation a few years earlier, which forked off Absolute Annihilation, which was based on Uberhack and subsequently ported to Spring. For those of you aware of BAR (Beyond All Reason), it is based on Balanced Annihilation and had the working name BA Reloaded.


Zero-K was picked after much discussion, deliberation, argument, and finally, a vote. We had a site at the time, called CaGov, where developers could create polls and vote on things. We voted on things from whether taking damage should decloak (it does) and whether all bombers should be replaced with laser bombers (only Thunderbird was replaced). The simple version of the Zero-K name is that it won, beating a few other proposals, the only other of which I can remember is Robocracy.

Edit: Longtime developer Sprung remembers "Ecce Machina" and the related name "why oh why is Deus Ex already taken". MidKnight remember "Open Conflict", because it's open source.

There were a few arguments in favour of Zero-K. The more narratively inclined like the idea of robots fighting pointlessly over the scraps of a universe approaching heat death, or zero degrees kelvin. That paid off in the lore for the campaign over a decade later (any more would be spoilers). We also coveted 0 A.D.'s alphabetically superior position on various lists, and thought we could force the shortening 0K. That did not work out.

Most of all, we wanted a unique name that would stand out and win at page rank, as search was all the rage in the late 2000s. We at least won that battle, defeating a book about cryogenics and a brand of dangerously cold single-use towelettes. The towelette company even sent us a sample after a Twitter interaction; the book still makes it to the image search preview in DuckDuckGo.


We may have been a bit too clever with the name. Zero-K stepped out of the shadow of Total Annihilation only a few years before Planetary Annihilation embraced it. Nostalgia aside, the latter is still a more descriptive name, and such names are common for strategy games. Think of all the names to do with armies or conquest. War, command, force, settle, empire, company, division, legion... the list goes on. Generic names indicate genre, which we gave up in favour of being unique. Maybe that sums up Zero-K.

Arguably the best aspect of the name revealed itself years after the decision was made - puns about low temperature - which far outweighs any downside. Zero-K: Nothing is cooler.

Index of Cold Takes

Zero-K began its life about 15 years ago as a mod built by volunteers, and development has continued in much the same way, except now as a full game. Admittedly we have slowed down a bit in recent years, in part due to the greater focus on polish, but also because we've already combined the best bits of RTS into a cohesive whole. Including some things that seem like gimmicks elsewhere, but really just need several years of refinement to get right.

Massive online battles and tight 1v1? Done. Campaign, AI, skirmish? Done. Spider-tanks, jumpjets, ships, planes and hovercraft? Done. Terraforming, cloaking, and 3D terrain that really matters? Done. Giant robots and superweapons? Done three times over. And there isn't much to do for the controls either, as we're so far ahead of everything else already. That's just what happens when people play for over a decade and improve what they notice needs improving.

Not that there isn't more to do. We release 3-4 major updates a year and don't plan on stopping. Just this month we added two new bombers and tweaked some other aircraft that needed a bit of love. In the last few months we improved the controls for Lobsters and notifications for tacnukes, in Don't Nuke Your Allies. As well as all the extra modding support of the past few years, so things can go full circle. So there is plenty to do, and we plan to do it for as long as we keep playing.

This update introduces two new bombers to fill out the aircraft roster. One is a bit like a light Likho, and another is like a heavy Raven, but there is a lot more to each. Other planes have tweaks and buffs, such as an area reveal ability for Sparrow, and a heavier Phoenix. Some gunships even got in on the action, with the most notable being a sizeable buff for Krow.

Other balance changes include a bit more health for light assaults, and better spinning for Disco Rave Party. In terms of features, bombers are well-served here as well, with selection icons for whether a bomber needs ammo, as well as smoother landing paths.

There are a few extra features for modding, such as scaling and tinting, which were technically in the previous hotfix. The campaign has the new bombers, a few features, and a new Records page which displays and aggregates your best stats for each mission. How fast can the campaign be completed, and with how few units lost?


Magpie is a light nimble bomber armed with a pair of missiles. It deals less damage than Raven, but makes up for it with speed, precision, and the ability to shoot from the edge of AA coverage.

• Cost 220
  
• Health 900
  
• Speed 252 (between Raven and Likho)
  
• Rearm time 20s
  
• Range 550
  
• Damage 180 x 2
  
• Can hit small raiders most of the time, and most aircraft.

Odin is a heavily armoured rocket zeppelin that can fire a slow moving disintegrator bomb or a cluster of temporary shields.

• Cost 1500
  
• Health 5200
  
• Speed 185 (between Raptor and most gunships)
  
• Rearm time 35s
  
• Bomb range 200
  
• Bomb damage, it's a disintegrator (5-shots Detriment)
  
• The bomb is very slow, even Detriment can dodge it.
  
• Special weapon fires seven shields at 550 range.
  
• Each shield has 3400 charge and a radius of 200.
  
• Shields decay at 40 charge/s, expire at zero charge, and do not link.

Sparrow can now boost, and reveals and decloaks everything in an area when it dies.

• Boosts by 5x for 3 seconds.
  
• Destroys itself after boost.
  
• Reveals an area of radius 400 for 12 seconds when it dies.
  
• Revealed area scales up during boost, to a maximum of 640.

Phoenix is heavier and deals more damage over a longer run.

• Cost 360 -> 460
  
• Health 1060 -> 1450 (90 more than if just scaling by cost)
  
• Reduced turn rate slightly
  
• Rearm time 5s -> 8s
  
• Drops 15 -> 18 bombs over 0.93 -> 1.7 seconds
  
• Area of Effect 216 -> 320
  
• Damage per bomb 25 -> 40
  
• Burn time 10s -> 12s

Krow manoeuvrers a bit better and fires beam lasers with more damage.

• Improved brake rate by 25%.
  
• Pew pew lasers replaced with burst beam lasers.
  
• Damage increased by 22%

Raptor is more manoeuvrable and slightly more deadly.

• Increased turn rate while firing, to counteract the effect of slowing down.
  
• Firing cone angle 90 degrees -> 100 degrees
  
• Damage increased by 4.2%

Locust is a tiny bit better as raiding, as a great Locust is scary.

• Speed 207 -> 212
  
• DPS increased by 2.5%

Thunderbird is slightly healthier.

• Health 1120 -> 1200

Bolas has 4.5% more DPS and can 1-shot Flea.

• Reload 0.366 -> 0.433
  
• Damage 34 -> 42

Ravager is tankier.

• Health 2000 -> 2200

Knight is a bit tankier.

• Health 2400 -> 2500

Hermit is tankier and faster.

• Health 1500 -> 1550
  
• Speed 51 -> 54

Skuttle can survive a single Jack poke.

• Health 250 -> 380

Zephyr is also tankier, and now has missiles.

• Health 1900 -> 2200
  
• Replaced its front laser turret with missiles.
  
• Missile damage 72 x 2
  
• Reload time 1.6 seconds
  
• Range 1000 (same as lasers)
  
• The missiles have 30% less DPS, but fire in a burst.

Disco Rave Party has an interpolation of its May spin rate nerfs.

• Aim speed 4 -> 2.5 -> 3 degrees/s.
  
• Spin up time 60 -> 120 -> 90 seconds.
  
• Spin drop while turning is unchanged, but less spin is lost for any given turn due to the increased turn rate.

• Magpie is unlocked on Fel Diacia (the Thunderbird mission) and Odin is unlocked on Bavhakya (the Likho mission). Anyone with these missions complete will have their units unlocked.
  
• Added a Records tab to the Profile menu on the campaign screen. This screen can sort and display your victories with least units lost, in the shortest time, with bonus objectives and difficulties. Unfortunately the data is not retroactive.
  
• Removed a few Lucifers from easier difficulties on Onsally (the Phoenix mission).
  
• Worked around the Dominatrix build options bug for the Rover Assembly on Ganong (the Dominatrix mission).
  
• Clarified Lalata main objective text (the Jugglenaut mission).

• Added Units Lost to endgame graphs.
  
• Unit pictures for bombers now have an icon showing whether it is ready to fire.
  
• Aircraft now smoothly glide and stop when landing on airpads. This is technically a nerf as they take slightly longer to land.
  
• Improved shotgun visuals, with minor balance implications.
  
• Grizzly now aims smoothly and holds its gun steady as it fires.
  
• Tweaked the automatic handicap mode to give lower handicaps for ratings above 2000.
  
• Moved Raptor to the AA slot (D) of the Airplane Plant and Sparrow to secondary scout/raider (S).
  
• Taught the opponent AI about Magpie.

• Units can now be tinted, rescaled and made glowing via the customparams model_tint ("R G B"), model_glow ("R G B A"), and model_rescale. Colour values are from 0 to 1.
  
• Free units (0 metal and energy cost) no longer need to explicitly specify a non-zero buildtime (previous release).
  
• Added a function to effects/napalm for generating generic fireballs ala Inferno.
  
• Air pads now call ReammoComplete, if it is a units script, when bombers are rearmed.
  
• Added command AIR_MANUALFIRE for aircraft, since they cannot use the in-engine type.

• Fixed Tremor wheels not spinning.
  
• Gravity guns push and pull a bit more consistently.
  
• Jack can no longer pretend to be a missile in enemy Missile Silos.
  
• Slow damage makes shields charge slower again (it broke at some point)
  
• Fixed bombers sometimes seeming to ignore a move command.
  
• Attack Move on bombers is now is now removed after they shoot, unless the bomber is set to repeat. Previously this only worked for some bombers.
  
• Bombers are now much better at landing on Reef. Much better. Horrific things could happen before.
  
• Fix sun on Mercurial and Rogues River.

Lobsters have been taught to not fire when it would be redundant, making Lobster balls much easier to manage. Overkill prevention in general has a tweak, and some APIs were extended to make modding easier. The Artefact Control game mode which saw some testing about a month ago is now live. In terms of balance, Redback has a bit of a nerf and some of the least used units - Skuttle, Phoenix and Emissary - have small buffs.


Duck can now be dodged by a Glaive trying as hard as it can to run away.

• Missile fuel time 2s -> 1.5s

Redback is worse at taking map control and assaulting defenses.

• Cost 230 -> 240
  
• Speed 1.85 -> 1.75

Skuttle can see enemies before they break its cloak.

• Line of sight 280 -> 330

Emissary aims faster and no longer benefits from manually turning.

• Body turn rate reduced 105 -> 84 degrees/second
  
• Gun aim rate increased 40 -> 70 degrees/second
  
• Resets its gun between shots (as much as possible) in case it has to move.

Phoenix moves faster and hits its target sooner.

• Speed 8 -> 8.1
  
• Projectile gravity 0.7 -> 0.72

Overkill prevention, the system that prevents ten Scalpels firing at a single Glaive, is now available for Lobster, and is suspended for units set to hold fire. It is controlled by a state toggle that is hidden by default because there is very little reason to touch it. The state toggle can be enabled under Settings/Interface/Commands, and per-unit defaults to be set in Settings/Unit Behaviour/Default States, or by holding Space and clicking on a unit, then pressing Edit Behaviour.

Lobster is smarter, no longer firing unless there is a visible valid target.

• This prevents it from firing when it would do absolutely nothing, provided there are no invisible enemies nearby.
  
• As a result, telling a tight clump of Lobsters to fire causes only two to shoot.
  
• This behaviour can be configured with the hidden Overkill Prevention state.
  
• Removed the Force Fire command by default. This can be configured via another hidden state toggle.

Overkill prevention is now suspended by default when units are set to Hold Fire.

• Added the "Enable for Fire at Will" and "Enable for auto targeting" states. Previously it just had enabled/disabled.
  
• Most units default to "Enable for Fire at Will". The theory being that if you set a unit to hold fire you care more about its target dying than about overkill.
  
• Nothing defaults to "Enable for auto targeting", but it may be useful to try out.

Impaler now has an even stronger preference for targeting structures over units.

• Added a minimum wind icon and number to the left column of the wind generator tooltip during placement (thanks Porkchop)
  
• Cleaned up some inconsistent unit highlighting and selection. Units under interface panels cannot be clicked on by default, tooltips do not appear, and units are not highlighted.
  
• Selecting through the panel at the bottom of the screen can be configured under Settings/HUD Panels/Selected Units Panel.
  
• Drag selection can still terminate over a UI panel.
  
• Add some translations for the commander selector.
  
• Updated Global Build AI with some fixes and documentation (thanks esainane).
  
• Added username team colour in chat and removed white outlines for dark names (thanks Birdulon)
  
• Local widgets are no longer disabled for spectators on rooms with local widgets disabled.
  
• Added Italian translations for the main menu (thanks fvasco)

• Tweaked campaign text and replaced some Artefacts with more suitable structures (thanks Thorneel)

• Added boxes for Onyx Cauldron 2.0
  
• Improved lighting on Skulduggery (thanks Shaman)
  
• Improved water on Cull, Lost v2 and Lowland Crossing Revised v2.
  
• Fixed an issue with void water with new shaders on some graphics cards.

Added a control point game mode called Artefact Control under Experimental.

• Several artefacts are spawned on each side of the map.
  
• Each team controls half at the start of the game.
  
• Artefacts have 11k health and heal at 100 hp/second.
  
• Artefacts respawned with switched allegeance when destroyed.
  
• If a team controlls all the artefacts, they win.

Changed some keys in unit def files to match the lua UnitDefs table. Mods with the old keys are still supported.

• buildCostMetal -> metalCost
  
• buildCostEnergy -> energyCost
  
• energyUse -> energyUpkeep
  
• metalUse -> metalUpkeep (vanilla ZK doesn't use this)
  
• maxDamage -> health
  
• maxVelocity -> speed

Other changes.

• Unit defs no longer require unitname since it must match the table key, so it is redundant.
  
• Unit defs are now also read from subfolders of 'units'.
  
• Set undefined burst rates to 0 (rather than 0.1) as it can interfere with weapon modding.
  
• The game exits to menu when unit defs fail to load, rather than crashing.
  
• Added game-side GG.UnitModelRescale(unitID, scale) from Unit Level Ups.
  
• Added backwards compatibility for Spring.GetUnitIsBeingBuilt.
  
• Fixed backwards compatibility for Spring.GetPlayerRulesParams.
  
• Added customparams.buggeroff_angle for factories, in radians.
  
• Added customparams.metal_extractor_mult to support the creation of higher tier metal extractors.
  
• Fixed modding away the Sniper reload move penalty breaking the script.
  
• Cleaned up the build icon generator gadget.
  
• Napalm effects now contain an example of sin (replaces taylor series).
  
• Improved modded energy generator tooltips.
  
• Mexes suport morphing.

• Fixed commshare sometimes preventing resign or causing a crash when the game ends.
  
• War music no longer counts morph as violence.
  
• Fixed missing vote resign button.
  
• Marginal turret overshoot can no longer be circumvented with command insert.
  
• Fixed a few build icons incorrectly implying that a floating structure is built underwater.
  
• Fixed commander selector button image.
  
• Fixed backwards 'motion blur' on ejected shells.
  
• Fixed some large structure wreckages having much too large collision volumes.

Get ready for the next Zero-K tournament, a 1v1 tournament where dozens of commanders will fight for dozens of dollars. The format is bo1 double elimination but other details have not been fully finalised. Sign up with a comment on the thread and send any questions to Kingstad. If you are more interested in watching, then games can be spectated through the lobby or you can watch one of the commentary streams linked on Discord.

🗓️ Date: July 8th [Saturday] 2023
⌚ Time: (3 PM EDT | 9 PM CET | 1900 UTC)
⏰ Countdown to Tournament
🔗 Forum Thread
👀 A commentary stream

There was also a minor update this weekend. It is mostly fixes for the previous update, but there are also a few features and balance changes.


Redback is worse at dodging projectiles.

• Increased collision shape width by 11% and length by 25%.
  
• Reduced turn rate by 5%.

Ogre now ignores terrain and wrecks when aiming and firing. It has sufficient AoE and arc for making the attempt to often be beneficial.

Zeno now homes onto the actual position of a radar target earlier - early enough to hit it.

• Holding Alt while selecting units now filters out rank 3 (ie army units).
  
• Added a sudden death mode game option, under Map. It causes the game to end shortly after a specified time via a contracting death circle.

• Fixed a missile impact indicator error.
  
• Fixed a pathfinding issue to do with construction orders on terrible terrain.
  
• Tactical missiles no longer have inconsistent half-prediction of enemy velocity. They now fire exactly where they are aimed.
  
• Fixed contrast adaptive sharpening scaling with zoom level.
  
• Fixed moderator tooltip colour in the lobby.
  
• Improved Pylon collision and selection volumes.