Projectiles in Zero-K are physically simulated, meaning that shots fly through the air and collide with anything that gets in the way. This is standard for games inspired by Total Annihilation, but Zero-K leans into the mechanic hard, and embraces the implications. Not content with taking only one thing to the extreme, Zero-K also has a strong aversion to armour classes and damage bonuses. We completely avoid damage formulas of the type that let pikemen deal extra damage to horsemen, or tanks take reduced damage from rifles. The goal is to create a game world that is visceral and intuitive, something that is best engaged with as a physical space, rather than as an abstract collection of numbers.

Complete Annihilation steadily removed the damage formulas inherited from Balanced Annihilation, and it looks like BAR might head the same way too. These were mostly things like commanders taking extra damage from turrets, and various EMP resistances. Bonuses like these suffer from being confusing and hard to remember, especially in a futuristic setting with no historical precedent or clear notion of infantry to guide intuition. Besides, completely removing damage bonuses is just so elegant, and making it work is a fun challenge. So we saw damage bonuses as a crutch, they solved problems in BA, but we could use physics to come up with better solutions.



To stack hubris on hubris, we also wanted the units of CA to have roles. Roles in the sense of pikemen beating horsemen, which is a bit more detailed than the roles found in Total Annihilation and most of its progeny. The roles in TA tend to be big "theatre of war" style designations, with roles like "bomber", "fighter", "scout" and "artillery". These roles are about dominating air, land or sea, or about projecting force from one domain to another. Artillery even fits this description if you consider bases and open ground to be different domains. In any case, all this theatre-on-theatre action left little room for diversity within a domain. This limits the options for combat within a domain, and in particular, land armies designed to fight other land armies could end up quite similar. The generic "army unit" would change as the game escalated, but at any given point the unit selection felt slim.

Armies in Zero-K should consist of multiple unit types, and it should be possible to exploit deficiencies of enemy armies, all within the ground vs. ground game. So Zero-K is designed around roles. Fast light raiders beat ranged skirmisher, which beat slow beefy riots, which beat fragile raiders. Whether these are "hard counters" or not mostly depends on how you define "hard", but I think they are mostly soft counters. Units can often beat their counters with a slight numbers advantage and a good engagement. We still have the "theatre of war" style roles, since cross-domain interactions are great too, but these counters tend to be harder. Artillery is very good against static defense, and fighters are very good against bombers.

How does Zero-K have such roles, all without any bonus damages? What makes the horseman-equivalent particularly bad against the pikeman-equivalent? In many cases, the answer is physics. Game physics, not real world physics, as the goal is depth rather than realism. Physics means the way units move around the world and interact with each other. It is things like unit positions, ranges and speeds, weapon area of effect damage, and how projectiles move. This is not new, every RTS has physics, and without it they would essentially be spreadsheets. Physics is fundamentally what gives players any reason to care where anything is. Every game with time, space, and simple rules linking them together has some sort of physics.



Not only is physics used by every RTS, it is often a large part of their design and balance. Horsemen counter archers because speed physically counters range, and any arrow-resistant armour is just icing on the cake. Zero-K just takes this a step further, eschewing damage modifiers and relying more on physics instead. This is a design constraint, a rule we have set for ourselves, because it means that units need to be physically different to have different roles. Spearmen can be designed to counter horsemen with physics alone, but it becomes tricky when it is time to implement a physically similar swordsmen. There is still plenty of freedom though, since quite a bit can be done with basic stats such as speed, health, damage and range. On top of this, Zero-K uses projectile physics to a much greater extent than the average RTS.

In most games, units shoot projectiles as a form of delayed damage, and to animate the act of shooting. A standard projectile will hit its target, and nothing else, unless the target does something weird (such as dying or, in some cases, teleporting). In Zero-K, each projectile is an independent entity with its own physics. Plasma cannon shots arc through the air, lasers fire in straight lines, and missiles try to track their target. If a projectile hits something, anything, then it explodes and deals its damage. The visuals are used to convey all this, rather than just being an animation to show that a unit shot.

Projectile physics increases the importance of units' speed and model size. Many longer ranged weapons shoot slow or inaccurate projectiles, which gives small fast units a chance to dodge while closing in. The slow rockets of most skirmishers are tuned to hit large assaults and riot units. In turn, the even slower projectiles of assaults and artillery units give most targets a chance to dodge, with the notable exception being turrets. There is space for soft counters here. Skirmishers can still beat fast raiders, but it is more a matter of creating a blizzard of rocket fire than having individual skirmishers fire at and hit individual raiders.



The whole "Physics vs. Formulas" dichotomy is about which parts of the game are more important. It is about whether a player choosing which unit to build thinks more about how it moves and shoots, or about damage formulas that determine what it counters. Zero-K is on the side of physics because it is cool, and it seems so intuitive. Players can see whether a projectile hits a unit and extrapolate the results for other projectiles and units of a similar speed. On the other hand, formulas are invisible and can be arbitrarily complex, taking into account armour, unit type, weapon type, and upgrades. Enough of a reliance on formulas can make the physics of a battle irrelevant, which is a shame because it is the part of the game that players can interact with moment-to-moment. Exploiting a formula is more down to unit choice than unit usage.

Great mechanics have more than one purpose, and physics of Zero-K has many. A big one is to fight Lanchester's square law, which essentially says that an army of twice the size is four times as powerful. All games have to grapple with this law, that is, unless they are happy with players just rolling a big ball of units around the map. The trick to fighting Lanchester's square law is that the "square" only applies in ideal situations, so to fight it we just need to move away from the ideal. Most games do this via units of inconveniently short range, to limit what can fire, and area of effect damage, as it deals more damage to dense armies - armies which are dense because everything is trying to get into range. Zero-K makes use of these approaches, but uses projectile physics to add even more.

Unguided projectiles act a bit like area of effect damage, because dense forces take more hits. Consider how a large force of Ronin will fire more rockets than a smaller force, but also runs into more rockets. At least, unless the Ronin spread out, but that risks moving some too far away to shoot. This all fights Lanchester's square law, but in a dynamic way where there are tradeoffs between dealing and taking damage. A small force can hold off a large one for a while if the larger army is unwilling to take any damage. It also makes attacking from multiple angles even better, since it reduces your own density. But perhaps the most notable effect of simulating projectiles comes from allied units blocking each other.



Projectiles hit units regardless of their allegiance, and going this far with projectile physics is rare even among games inspired by TA. It means that a dense blob of units loses most of its damage to blocked lines of fire. This further encourages armies to spread out in a line. Density and facing is very important, since a good flank can leave most of an army unable to return fire, even if they are in range. High density is not all bad though, since it concentrates power and prevent units being surrounded by enemy raiders, so there is a constant tradeoff. Still, Zero-K tends to have lower density armies than the average game, which encourage spread out battles across multiple fronts. The advantages of low density even play a central role in the escalation from cheaper to more expensive units.

Projectiles have a lot of parameters, which in turn allows for a large range of weapon types. To cut down on complexity, most weapons fall into one of three categories.

• Plasma cannon that fly through the air in a ballistic arc.
  
• Unguided rockets or homing missiles. Some are fired directly at the target, while others arc.
  
• Lasers and lightning that instantly hit and require a direct line of sight to fire.

These weapon types results in a variety of tactics, since each type has its own relationship with unit density. An arcing projectile allows units to clump and still be able to fire, but still leaves them vulnerable to return fire. An army armed with lasers or homing missiles needs to spread out to fire, but the inability to miss removes an opponent's incentive to spread out. Being unable to miss is quite powerful, but remember we still have non-physics balance tools, so such units tend to pay for their accuracy with poor raw stats. Direct fire weapons are also particularly weak to being blocked by terraformed walls.



This all sounds great, hopefully, but it also sounds fiddly. Luckily, Zero-K is built on fighting your opponent, not the UI, so we are careful to keep the physics manageable. We avoid implementing unnecessarily fiddly weapons, and provide powerful controls to deal with everything else. Line Move lets players create formations and dial in their density with ease, and becomes their default way of issuing orders. Attack Move lets players tell short ranged units to jink around to avoid projectiles, and longer ranged units to move away from enemies that try to close range. Anti-Bait lets players tell units with big important shots to not waste their time trying to hit a speedy raider. And it almost goes without saying that units have the intelligence not to fire when allies or terrain is in the way.

I have been a bit misleading, and it is time to come clean. Zero-K has a damage formula. To start with, some units have an armoured mode that causes them to take 33% damage. I am not sure whether this counts though, since the multiplier applies uniformly. The most common damage modifier is for anti-air, which deals only 10% of its damage against ground units. But anti-air is not even capable of firing at ground units, which is a fine mechanic provided the target categories are clear. The anti-air damage modifier is mostly just insurance against anyone figuring out how to work around this restriction. Then there are shields, which have to convert status effect damage such as EMP and slow to ordinary damage. This is done at a rate of 33%, which is a bit arbitrary, but it has to be less than 100% because status effects have very high raw damage. Finally, gauss and flamethrowers deal extra damage to shields, because something something piercing something something... there is actually no excuse.



It gets worse though, as some units shoot through allies, or even terrain. And not in a consistent way, like how flamethrowers burn through everything in their path. Nukes and tacnukes pass through allies because having one explode on an errant plane sucks (although when they hit an enemy plane it is hilarious). Anti-nukes pass through everything for similar reasons, but also because they do not know how to try again if an anti-nuke misses its target. A few other weapons here and there pass through allies, although in most of these cases units still avoid shooting at allies. There is a difference between colliding at allies and firing at allies. A few units with fast ally-piercing projectiles still aim as if they would hit allies, so the caveat is more about edge cases. Some edge cases are bad, and the best uses of physics know when to relax and let things feel good. In short, know when to dial back the jank, because sometimes it just sucks.

Speaking of jank, weapons can impart force on units, pushing them around. Clearly this means there should be gravity gun weapons that just push or pull units, and there is no reason not to let it target allies. The result is unit cannons made of Newtons (the gravity gun turret) and terraformed ramps, and it is my favourite incarnation of a unit cannon. Anything can be fired, anything, provided you have the resources and skill at engineering. Such a thing would get repetitive if it were common, but somehow it hits a sweet spot. It is often impractical, but sometimes it is time to fling Jacks into the back of the enemy base.



Gravity guns and edge cases aside, the goal of Zero-K's physics is to evoke a particular feel. The game world should feel like something that should be engaged with as a physical space, rather than an abstract collection of numbers and circles. Games can end up feeling quite abstract. Put more enemy units in your circles (ranges and spell radii) than your opponent manages to put in theirs, and you win. Formulas can vary the effect and suitability of each circle, but this just mixes up which circles are used, rather than change the fact that everything is circles. Zero-K fundamentally disrupts the circles, deforming them into weird and wacky shapes, the consequences of which are too numerous to cover in one article. But it is sure to come up again and again.

Index of Cold Takes

Games in the Total Annihilation lineage almost always have the same two resources, metal and energy. Metal is produced by building Metal Extractors on deposits scattered around the map, while energy comes from power generators that can be built, by and large, anywhere. The more important resource is metal, simply because metal deposits, or "spots", are rarer than free space to produce energy. Metal is the limiting factor, which causes players to expand out onto the map, capture territory, and interact with the enemy. A game without metal would mostly consist of players sitting in their base, building energy.

Many TA style games also have Metal Makers, economic structures that drain large amounts of energy to produce a bit of metal. Supreme Commander calls these Mass Fabricators, but mass and metal are just two names for the same thing. These structures are less efficient than metal extractors, otherwise players would have no reason to leave their base, but they allow players to scale up their economy without capturing more metal spots. The only requirement is space and resources, which makes them useful later in the game when all the metal spots are taken and defended. The early developers of Zero-K liked the idea of a growing economy, but not how it was implemented with metal makers.


Metal makers were removed from Complete Annihilation, the precursor to Zero-K, just about as soon as it forked from Balanced Annihilation. For context, the average 8v8 BA team game had a few players on each team fighting over unclaimed territory, while the rest of the team sat in the back and mostly built metal makers. The back players players were not slacking, they were necessary, because games were rarely won before metal makers became a deciding factor. Any team that ignored metal makers risked being overwhelmed by the compounding income they would eventually provide. Eventually, once a team had enough metal makers, territory no longer mattered. This did not sit well with the CA developers, as they preferred fighting and expanding to sitting in the back.

Metal makers are fundamentally a way to spend resources now to be more powerful in the future. Every RTS needs something like this, some way to invest in the future. Investment can take many forms, from simply increasing income, to upgrades that increase how much power you can squeeze out of your existing income. Investment is vital because it is a dimension of the strategic triangle, with the other two dimensions being aggression and defense. Without investment, there would be no way to outproduce and overwhelm an overly defensive opponent, and there would be nothing for aggressive play to punish. So we knew that CA needed some form of investment. We tried subsisting on advanced metal extractors, another feature of the TA lineage, which are expensive income upgrades for basic metal extractors. These were a bit finicky though, and the ability to invest hits a wall when there is nothing left to upgrade, so we came up with overdrive.


Just as an aside, I recall discussion on the Planetary Annihilation forum about whether it should have metal makers. It ended up without them, and without a replacement, which might be fine, although I lost track of PA so cannot say for sure. I suspect relying on advanced metal extractors works because there is a lot more frontier to defend when playing on a planet, and PA was fairly spammy with its metal spots. So upgrades can carry the investment game, just in CA's case the maps tended to not have a ludicrous number of metal spots.

Anyway, CA went with overdrive, which may have been invented by Licho. I know he at least wrote the first version of the code. The basic idea is that every metal extractor (mex for short) should also be a metal maker, because that links metal makers to territory. A complete system can then be derived by noticing and fixing a few immediate issues.

• Metal spots can be high or low yield. It would be weird for a map of low yield metal spots to allow more metal maker income than a map with fewer spots and the same total income. So the "metal maker" income of a mex is a multiple of its spot yield, rather than a fixed amount.
  
• The standard "drain 70 energy for +1 metal" style metal maker has the same issues as advanced mexes. In particular, economic investment hits a sudden limit when enough energy is being produced to run all your mex-metal makers. So we made mexes able to turn a variable amount of energy into metal.
  
• A variable input metal maker cannot have a fixed conversion ration, otherwise players would only ever need one. This would defeat the whole purpose, so we made a mex's energy to metal conversion efficiency worsen at higher rates of energy use.

The result was mexes that can drain X energy to multiply their income by 1+√(X/16). We call the extra income overdrive income, so for example, a mex with +2 base income doubles its income by draining 16 energy per second, and would need to drain 64 energy to triple it. Actually, the original equation was √(1+X/4)-1, but near the end of 2014 we discovered that it had not been solved correctly, and that the correct solution required the concept of "underdrive". So we switch to the simpler 1+√(X/16).

The diminishing returns of overdrive keep territory relevant throughout the entire game. Say there are two teams, one with 10 mexes and the other with 8, which each have 40 energy to spend on overdrive. The energy is automatically split between the mexes, as this yields the greatest return, so the teams spend 4 and 5 energy per mex respectively. Spending 4 energy on a mex increases its income by 50%, while spending 5 energy increases its income by 56%. Assuming +2 base income mexes, the team with more mexes produces 10 overdrive metal while the other team only produces 8.9. So territory is important because it lets the team with more mexes convert the same amount of energy into more metal.


Overdrive was also a break from the exponentially increasing income characteristic of standard metal maker economies. With metal makers, you can always spend a fixed amount of metal for the same increase in income, and this income can be reinvested in increasing your income, yielding exponential returns. With overdrive your income can still grow, but further growth becomes increasingly expensive. These two factors cancel out, leading to high initial returns followed by approximately linear growth, since spending twice as much energy on overdrive only increases your income by 41% (√2). The graph above demonstrates the difference, with overdrive via Singularity Reactor pitted against a modded metal maker. The metal maker does not drain energy, rather, it represents an energy-neutral combination of metal makers and power generators.

Removing metal makers was also great on the fighting the UI front. It takes skill and attention to scale up a metal maker economy since energy production needs to be balanced against expenditure. Overbuilding power generation is wasteful because the excess energy is lost, while overbuilding metal makers leads to a deficit. Metal makers can be turned off to avoid stalling, but idle metal makers represent wasted resources that could have been used to generate more energy. Truly optimising your income is hard. Overdrive does away with this. If you want to increase your income without more metal spots, just make energy and let your mexes automatically drain the excess. The underlying decision, to invest, is the same across games, but getting the most bang for your buck is tricky with metal makers. Players using either system still have to balance exploiting their existing territory against expanding into new territory, but that is an important strategic decision that involves the enemy, so Zero-K retains it.

Overdrive also led to some interesting map design around high yield metal spots. Mexes drain energy to multiply their income, so better mexes are more efficient and should use a larger fraction of the available energy. The overdrive system figures this out automatically, with the optimum split being to weight each mex by the square of its income. So a +4 mex should receive 4x the energy of a +2 mex. Map makers take advantage of this system by putting high yield metal spots near the centre of the map, for "king of the hill" style objectives that become increasingly important as the game progresses. The high yield mexes are valuable early, but not unduly so, because excess energy is scarce. It is only later in the game, once people have built up their energy, that holding high yield mexes confers a significant economic advantage.


The initial implementation of overdrive had a few problems. The very first version presented players with a graph and a slider bar to control how much energy they sent to overdrive. That was quickly replaced with an innate system that spends a proportion of your net income that depends on how much energy you have stored. The first version might have also been per-player, rather than pooling team mexes and energy for improved efficiency, but if so, it was revised quickly. In any case, there were other reasons to have shared mex income. Overdrive had one tricky, nuanced, problem, which we solved by adding an energy grid. These days overdrive is synonymous with the energy grid, but the entire rest of the system was designed without it.

Grid-less overdrive was a bit prone to snowballing. A small difference in the number of mexes controlled by each team results in a persistent income advantage. More precisely, the energy to metal conversion ratio is √(X/Y) times better for a team with X mexes compared to a team with Y mexes, for the same input energy, assuming uniform mex incomes. This would compound into victory for the side with a slight advantage, before it "was time" for the game to come to a conclusion. The solution was an energy grid, so that overdriving a marginal mex required a bit more effort than just building the mex. Then a team with a slight advantage has to hold onto their mexes, and to build some vulnerable infrastructure, if they want to compound their improved overdrive efficiency into victory.

The energy grid works by setting a simple constraint: the total energy used by mexes in a grid cannot exceed the energy produced by structures within the grid. This makes overdrive usage mirror the roll-out of advance mex upgrades in other games. Players start by upgrading their main base, and then expand to increasingly dangerous territory. It creates a satisfying wave of "double expansion", where you have secured territory well enough to fully exploit it for resources, and the extra infrastructure is also extra raid-able.


The first grid was designed around dedicated pylons. These pylons gathered energy within their radius, and were the only structure that could link to mexes and to other pylons. As well as being too complicated, the system suffered from the distance threshold problem. In short, previously irrelevant minor variations in map symmetry were now extremely important. A pylon might cover four mexes on one side of the map, but only three on the other, conveying a noticeable economic advantage. We tried imposing a hard connection limit of three, and tweaking pylon radius, but maps were too variable to cover everything, and our attempts were making pylon placement increasingly fiddly. So we let everything link to everything, letting pylons fade into the background. This all happened rather quickly, the grid as it exists in Zero-K today may have been complete as early as 2008.

Letting everything link to everything turned out really well. Many RTS games have at least one spammy economic structure, most commonly houses or power plants, that can be built anywhere. Players will just pack these structure into the back of their base unless the game gives them a reason not to. Most games of the TA lineage let this happen to their power generators. Supreme Commander had a go at solving this with its adjacency bonuses, but personally I feel like they make base building a bit too prescribed, and packing a checkerboard of power generators and metal makers into the back of your base does not seem like much of an improvement. The way players make energy in Zero-K is so interesting, so flexible and alive, by comparison.


Players tend to start on their grid from the start of the game. They drag lines of wind generators between metal extractors, but these lines are perfect cover for enemy raiders. Expanding constructors might also build the occasional solar collector, which spices up expansion patterns and creates more targets for raiders. Two solar collectors are enough for a 50% increase income boost, so people often roll them out as cheap form of secondary expansion before fully gridding everything later. Placing energy in interesting ways becomes automatic, you can sometimes spot Zero-K players in other games this way. Giving players a reason to care where their energy is built creates so much nuance and variation in expansion and base layout.

Overdrive has a big drawback in that it can be harder to explain than metal makers. Telling someone about a structure that turns a fixed amount of energy into metal feels like a complete explanation, even though it leaves out all the detail of when you might want to use this structure, and how to manage an economy around it. The basics of overdrive can be explained with rules of thumb such as "build more energy than your metal income" and "link energy to mexes', but these are a bit too vague. Some players want solid numbers, even before they have the context for them. All we can give them is the energy conversion equation, and the way grids limit energy expenditure.

The trickier explanation of overdrive goes hand-in-hand with its role in Zero-K. For all its apparent complexity, I contend that mastering overdrive is easier than mastering metal makers. In general, systems made of simple discrete parts, such as metal makers, tend to be more complex than systems of smooth equations. Zero-K exploits the emergent complexity of simple elements in much of the rest of its design, but not at the core of the economy. This is simply because Zero-K is not a game about micromanaging your economy to eke out an optimal growth curve. Such a curve can be solved, and the solution has nothing to do with fighting the enemy, so we consider it to be fighting the UI. Rather than metal makers we have overdrive, which solves itself, but which has enough going on around it to remain interesting after it is solved. The different energy structures, with their different incomes, costs and vulnerabilities, act as our simple elements with emergent complexity.


We try to ameliorate the complexity of overdrive with mechanics that help players play it by ear. Grids change colour based on how efficient they are, and energy structures show an estimate of their payback time as they are being placed. This seems to work for the majority of players, and the system is very forgiving, because overdrive cannot cause an energy stall. Hopefully we do enough to get new players over the hurdle of using something so different, until they realise how smooth it is and how many problems it solves.

Index of Cold Takes

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.


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

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

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

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.