1. Zero-K
  2. News

Zero-K News

Zero-K v1.12.1.1 - Ship Shape


This update follows the Corsair buff from last month with a wider range of ship tweaks. The largest are that Siren and Envoy are much heavier, and that Reef drones capture units. This should give smaller ships time to shine and make the larger ships more impactful. Many ship hitboxes have been fixed to better match their size and shape, some visual sizes were tweaked, and ship wakes have been improved for look and consistency.

Beyond the shipyard there is an experimental Ronin buff that makes it much faster when out of combat, as well as buffs for Grizzly and Magpie. There are a few more Cloakbots buffs, foreshadowed by the matchup chart in last week's Cold Take. In terms of features, the ingame menu can be brought up over the Victory/Defeat screen in the campaign, and Comet Catcher Redux/Remake has the classic corner start boxes for 1v1.

Balance


Siren is larger and heavier. Even though its average damage output is unchanged, the increased range, rate of fire, and explosion radius are a noticeable buff against swarms of light units.
  • Cost 600 -> 900 (+50%)
  • Visually 20% larger
  • Physically about 18% larger
  • Health 5200 -> 7800 (+50%)
  • Range 270 -> 290 elmos
  • Now prepares to aim at units about to enter range.
  • Reload time 1.7s -> 1.066s
  • Damage 280 -> 175
  • Explosion radius 95 -> 100 elmos
Envoy is larger, heavier, and fires in a burst. It can 1-shot Lance but is still vulnerable to them.
  • Cost 850 -> 1200 (+41%)
  • Visually 20% larger
  • Physically about 9% larger
  • Health 2000 -> 2600 (+30%)
  • Turn rate reduced by 7%
  • Burst 1 -> 2
  • Reload time 5s -> 7.3s (damage output increased by 37%)
Reef size matches its model and drones now capture enemy units.
  • Physically about 20% larger
  • Each drone captures at 55% the rate of Dominatrix
  • A drone reloads for 5 seconds after capture
  • Capture control is transferred to the Reef
  • Drone health 180 -> 260
  • Drone altitude 150 -> 120 elmos
  • Drone weapon range 360 -> 250 elmos
  • Maximum drone count is still 8.
Hunter looked too large but was physically too small.
  • Visually 10% smaller
  • Physically 7% larger
Mistral now looks like it costs more than Hunter.
  • Visually 15% larger
  • Physically 42% larger
Corsair has the AI improvement many riots and raiders received a while ago.
  • Now prepares to aim at units about to enter range.
Ronin is much faster when out of combat and half a recent health nerf has been reverted.
  • Health 380 -> 400
  • Speed 69 -> 84 elmos/s
  • Reload slowdown 80% -> 66% (55.2 -> 55.4 with the base speed buff)
  • Fixed the reload animation so it shoots as soon as it reloads, except when firing backwards.
  • It is now slowed for the full reload, rather than speeding up for a split second at the end.
Reaver has a few of its recent nerfs partially reverted. The focus is on making it easier to build early.
  • Regen rate 15 -> 20 hp/s
  • Range 265 -> 270 elmos
Gremlin is better overall and cloaks for free.
  • Cost 140 -> 130
  • Cloak cost 0.1e/0.5e -> 0e
  • Decloak radius 140 -> 125 elmos
  • Speed 87 -> 93 elmos/s
Grizzly is healthier and cheaper to move it out of the Cyclops cost range.
  • Cost 2000 -> 1900
  • Health 8400 -> 8700
  • Turn rate increased by 5%
Magpie is yet to break the game so can try rearming faster.
  • Rearm time 18s -> 15s
Features


  • Improved the look and consistency of most ship wakes.
  • The mission Victory/Defeat screen is now displayed behind the ingame menu.
  • Added N to toggle hold fire to the default hotkeys.
  • Added classic corner 1v1 boxes to Comet Catcher Redux/Remake.
  • Improved lighting on Izki Channel v1.0 and MiniChess_v2.
  • Incidental ability sounds (such as Djinn) are now controlled by the battle volume slider.
  • Added support for modded Push/Pull weapons on units with On/Off toggles.
Fixes


  • Shielded Chickens now float, since shields are disabled underwater.
  • Fixed Reef looking peculiar when it tries to beach itself.
  • Fixed visual jitter for capture and Lobster effect lines on moving units.
  • Fixed initial queue mid-queue removal.
  • Fixed Battle Value Tracker rounding for numbers less than 10.
  • Tweak map extension grid thickness to avoid triggering a hardware bug with GoogleFrog's screen.
  • Modded tint and glow now survives reloading lua.
  • Fixed some issues with shutting down the depth of field shader.
  • Update json library for a bit better performance.
  • Fixed a very rare healthbar bug.
  • Fixed an overhead icon bug.

Cold Take #4 - Factories as Factions

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

Cold Take #3 - Fight your opponent, not the UI

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.

Zero-K v1.11.12.4 - Blastwing Split



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.

Balance


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.
Waiting List Split


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.
Features


  • 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).
Fixes


  • 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.

Cold Take #2 - Quant's Rule

"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