Zero-K runs on the Spring engine (now Recoil), which is written in C++. This is a great programming language for speed, but a slab of solid C++ is too daunting for the average game developer to dive in and edit. This is especially true with the engine handling so many fundamental systems, such as multiplayer, pathfinding, and physics. Luckily, Lua was added to the engine in late 2006, and as a result, Zero-K itself is written almost entirely in Lua.

Lua is a popular language for game scripting and modding. Spring games can include Lua code, which the engine then triggers on a wide range of available events. Once triggered, a Lua script can do things such as modify the game world, or draw things on the screen. For example, the flame-spewing Pyro triggers UnitDamaged to tell Lua to set units on fire. Being on fire is not an engine concept, rather, Lua implements it by drawing flames within a DrawWorld event and applying damage on GameFrame.


Scripting took a bit over a year to add to the engine, and it was a gamechanger. Prior to Lua, new mechanics came from the engine, so they could only be added at the speed of engine development. This was much slower, since the pool of C++ developers is smaller, and engine code is held to a higher standard since it is shared between games. Even worse, engine updates are released periodically, further lengthening the feedback and iteration cycle. The methodical release process of the engine is great for the stability of RTS fundamentals, but not so great for rapidly iterating on new mechanics.

Some experimental mechanics were added prior to Lua, although most since fell by the wayside. The problem with engine features is that they are hard to modify or update, so most games evolved past the more obscure ones. Even if you can muster the C++ mana, other games might want the old version of the feature, leading to a proliferation of configuration options that multiply the difficulty of working on the feature. Tweaking the simplest thing can quickly turn into a discussion between multiple games, and everything has performance or maintenance trade offs.

Do not take the above to mean that the engine is useless. It supports the complete RTS experience, without scripting, and has robust systems for Lua to interact with, such as the command handling system. Some of the more experimental features are even used by most games, such as bubble shields and area commands (although I heard that COB scripts could technically make area shields in Total Annihilation). There just happen to be many other vestigial mechanics, such as aircraft flares, repulsion shields, seismic detection, and an early form of line move, that are rarely used by Spring games.


Spring supports Lua in essentially two flavours: widgets and gadgets, known collectively as wupgets. Widgets run independently on each player's computer, with their own internal state, and are fair in the sense that they can only see and do the same things as the player. People can even play the same game with a completely different set of widgets installed. Gadgets are completely different, they run as part of the game itself, and implement game mechanics. Most of the flashy new stuff in Zero-K is run by gadgets, such as jumpjets, terraform, overdrive, cloakers, and unit AI, but many "mundane" parts of the game are also managed by a gadget in the background.

There was an explosion of widget development in 2007 and 2008, with the creation of many widgets that underpin the basic UI features of most Spring games, including widgets such as custom formations (line move) and command insert (Space + Click). This was mostly being done by players freely sharing code and ideas, rapidly experimenting and discovering what worked. Anyone can install a widget to run on any game, which means you can tweak your widgets from match to match. The iteration speed and direct player involvement has never been greater, and as such, widgets quickly outstripped the engine UI, to the point that engine-side UI development stopped completely.


Widgets were hugely influential on Zero-K, since Complete Annihilation was concurrent with the widget explosion, so we saw firsthand how widgets were upending the design of existing games. For example, Fencer could fire while moving up until I wrote an early version of the autoskirm widget. Players were curating their own UIs, and they were getting more powerful, so the options were to either block it completely or embrace it. We chose the latter, and strove to make a game that survives the pressures of powerful UI, ending up at Fight your opponent, not the UI.

Gadgets were also influential, but more on the development side. Complete Annhiliation development was fairly open; once you had commit rights, you could experiment and add almost anything. So people just did stuff. Jumpjets, area cloakers, terraform, overdrive, shield link, construction priority, laser bombers, morph - these were added by people who wanted to add them, without much room for other developers to tell them not to. We attracted people interested in pushing beyond TA, and it paid off.


The initial explosion of creativity lasted perhaps five years, at which point we started consolidating. Most notably, rather than just cram the game full of cool widgets, we started creating sensible defaults, with an eye towards giving new players a functional UI. Widgets moved from something players brought with them, to something the game provided. Gadgets were refined too, and a few, such as experience morph, were removed entirely. Removal was a last resort though, we wanted to retain the creativity. The UI was rewritten in a bespoke Lua-based UI framework called Chili, although some of the most important UI work was not with widgets at all, but with the creation of unit AI gadgets.

Unit AIs tend to start as widgets, since it lets players tinker permissionlessly, without any concerns for stability or release cycles. Good widgets come from this system, however, there are two big issues. The first is fairness, since enhanced unit AI confers an advantage. This can be resolved by including all widgets in the game, although this relies on the author being willing to share and polish the widget. Sharing is easy enough, there has never been a problem, but polish is hard. The second issue is also fairness, but at the deeper level of latency, one fundamentally unsolvable by widgets.

Widgets suffer from network latency, from ping. This is because players have latency, and widgets effectively run alongside the player. We usually deal with latency as an unavoidable fact of online gaming, and a few 100 milliseconds does not mean much in an RTS, as players can adapt to it. However, widgets are fragile code, that have trouble adapting to delayed commands, causing them to break or have highly varying effectiveness. Essentially, AI widgets are prone to amplifying the inherent unfairness of latency. Technically the widget processing happens immediately, due to the network structure of the engine (see below), but the responses still suffer from the round trip ping to the server and back.


Widgets cannot solve latency, so we had to migrate unit AI to gadgets. Gadgets act directly on the state of the game, observing and responding with no delay. This is why there is no autoskirm widget; it is now baked into the game. Unfortunately gadgets are not easily configured, which is why Zero-K now has a large number of unit state toggles, but this is a small price to pay. The gadgets also have to be careful not to cheat, since technically they are omnipotent and omnipresent, but Spring provides ample tools to limit Lua to what a player can see.

Gadgets are not just for adding mechanics and polishing widgets; they are also used to polish (replace) the underlying engine. For example, the basic move command, the thing that happens when you right click the world, is a custom command handled by a gadget. The engine offers a basic move command, but it causes units to jam up around waypoints, which is not good enough for the standard of control set by Zero-K. The engine implementation was even worse before Zero-K replaced it, but the engine has improved a bit in response. There are many other examples, such as the engine failing to split resources evenly between constructors. Ideally these things would be in the engine, but until they are, Lua can pick up the slack.


Replacing the engine with Lua is not without its challenges. C++ has much better performance, so we are careful to use as much of the power of the engine as possible. Luckily, large swathes of the engine are exposed to Lua so, for example, the custom move command uses Spring.SetMoveGoal rather than attempt to find paths for 1000s of units on its own. This is a fine division of labour, with the engine handling the resource intensive tasks, leaving lua to stitch together the results.

The above barely scratches the surface of Lua. The entire main menu happens to be written in Lua, using the same framework as the ingame UI, but this was more a matter of Lua mana than a technical necessity. Units animate with Lua scripts, and entire opponent AIs were written in Lua. But perhaps the greatest ongoing impact of Lua harkens back to the creative explosion of 2007: Zero-K itself has many mods with many new features that are only made possible by using Lua to delve deep into the engine. So if you want to write some Lua, rather than read about it, consider giving modding a go.

Index of Cold Takes

Raven was arguably the single most influential unit in Zero-K, and is definitely the most reworked. As the main bomber for 15 years, its burst damage defined the health thresholds that determined vulnerability to air. I say was because the bomber lineup has since been fleshed out, with the addition of Magpie and Odin, as well as the de-Owling of Phoenix. But that is only the end of the story, after many tweaks and redesigns. The full story is of a conflict between physics and reliability, and involves Raven trying almost as many weapons and abilities as the rest of the bombers combined.


The proto-Raven was inherited from Total Annihilation (via BA), and was originally the generic light bomber. It was generic in the sense of being a weaker and cheaper version of the heavy bomber. This was not good enough, we wanted units with roles rather than generic monospam, so the first order of business was to make these two bombers distinct. We also wanted the light/heavy bomber divide to fit into our fuzzy approach to tech levels, so if the heavy bomber was to take over later in the game, it should be because the situation has changed, not because it just has better stats.

Our solution was to give the heavy bomber more bombs, to create a real carpet bomber, while the light bomber was pared down to drop a single, precise, bomb. Raven was born, and in a sense, so was Phoenix, although Phoenix ended up much closer to the old heavy bomber. Here is the theory behind the role split.

• Carpet bombing is great against clumped armies, which are more prevalent later in the game.
  
• Precision bombing is great at taking out key units, such as turrets, riot units, and commanders, and individual kills have more impact early in the game.

The most important job for the precision bomber is commander sniping, which is a timeless tactic where the attacker tries to blow up the enemy commander in one shot. The possibility of a snipe warps the game around it, with commander health largely balanced around how hard it makes them to snipe. The original light bomber was already the unit of choice for such snipes, since it was a more efficient source of damage for its cost, which made it a natural choice to rework into a precision bomber.

A commander sniper needs to know how many bombers are required to kill a commander. Too few, and the commander survives and is repaired, wasting all the bombers that died in the attempt. Too many, and the attempt is delayed, giving anti-air more time to build up. Shooting a spray of bombs, like the original light bomber, makes the outcome somewhat random. Perhaps four bombers only have an 80% chance of firing a tight enough spread of bombs, so you need to bring a 5th one to bump the chance of a kill up to 99%. This level of randomness felt bad.



To be more precise, randomness can be split into two types: output randomness and input randomness. This concept has been blogged to death elsewhere, so in short:

• Input randomness is where something random sets up a situation, then you make decisions about how to deal with it. Think random map generation.
  
• Output randomness is where you make a decision, then a random process determines the outcome. Think rolling to hit in X-Com, D&D, or Starcraft.

The general consensus is that players dislike output randomness, because it removes control. My view is that output randomness is necessary for a game like Zero-K because the outcome of one decision sets up the situation for the next one. That said, the range of outcomes for a single action, the swing, should not be too large. A commander snipe is a single decision with a large impact on the game, so the final outcome should not depend on where the bombs happen to fly. Hence, the precision bomber.


The theory behind precise Raven was sound, but we failed to account for one thing: commanders can move. Commanders do not enjoy being sniped, so move out of the way when bombs are lobbed at them. In fact, Raven could not even hit commanders walking in a straight line, since the default bomber weapon type does not lead targets. This is an engine limitation that stems from the fact that bombs inherit the velocity of their bomber. Bombs are not fired, they are dropped. This ties aiming to movement, and no one was game enough to figure out target leading with this complication. So Raven needed a new weapon.



The first rework came about due to Complete Annihilation being a collection of contributors doing cool things, rather than by design. Someone woke up one day and thought "All the Arm bombers should shoot laser", so all the Arm bombers shot lasers. Phoenix was light show, Likho abducted units with a thick purple beam, and Thunderbird shot a spray of lightning rather than cluster of Imp-like bombs. Only one of these changes stood the test of time. As for the Raven-equivalent bomber, it shot a short burst straight down, like an awkwardly airborne Grizzly.

Lasers highlighted, rather than fixed, the problem with pure movement-based aiming. Laser Raven had perfect accuracy against anything directly beneath it, but again, commander can move. Even a slow commander could walk sideways fast enough to overwhelm the Raven's ability to turn and correct. The angular velocity of a dodging commander increases dramatically as Raven gets closer, necessitating a ridiculous turn rate that would make Raven behave more like a figure skater than an aircraft. We were too committed to planes that behave somewhat like real planes, so went back to the drawing board.



With lasers out, we looked to rockets. Technically, rockets have cylindrical range so a short-ranged rocket would be able to fire at targets far below. Verisimilitude has a few things to say about this hack, but it mostly works. Lingering issues were fixed by moving the firing point along the underside of the wing, towards the side that the target is on. The result was a Raven that could be relied upon to shoot and hit a commander walking in a straight line, even a perpendicular one. However, curved lines were another matter.

Target leading works by predicting where a unit will be based on its velocity. It cannot take into account turning, because a unit could choose to turn at any time. The result was the Raven "quick time event", where players would tell their commander to do a little dance, or just walk in circles, whenever a Raven fired at it. We made the rocket-bomb fast enough to make dodging non-trivial, but we were limited by trying to avoid Raven being too good against fast units. The ideal was a Raven that could reliably hit slow units, without massacring medium raiders. A solution to this conundrum came in the form of a new ability: diving.


Dive started off as an unrelated attempt to resolve a fight with the UI. I had noticed three things:

• Raven has enough damage to 1-shot large shield generators.
  
• Raven flies slightly higher than the shield, which can absorb many bombs.
  
• Landing brings bombers closer to the ground.

In theory, you could fly a Raven over a shield, tell it to stop, and fire a fraction of a second later once it is inside the shield. I am not sure whether anyone actually did this, but that was besides the point, there was a clear case of a unit misusing its abilities. This could have been solved by making Raven fly slightly lower (and eventually was), but instead I gave it the ability to dive under shields. It later turned out that Saktoth had intended for Raven to be bad against shields, but the fight with the UI was clear, so shield diving made it in. Of course, ability use cannot depend on the presence of the enemy, so we also let players tell their Raven to continuously fly at the lower altitude.



The result was immediate, people started telling Raven to fly lower to score more hits on commanders, significantly increasing their reliability. The default behaviour was subsequently updated to make Raven dive when attacking mobile targets, and they even modulated their height by the speed and size of the target. The mechanic had the neat side effect of making Raven more vulnerable to return fire against faster units, and slowing down the bomb accentuated this aspect. Eventually we made Raven slow down as it dove, making it particularly vulnerable to fast raiders. This was Raven for over a decade, from 2011 to 2022, but it was not a solution without problems.

The first problem was that dive is a complicated and powerful ability. Raven had the implied ability to choose its altitude from moment-to-moment, trading off against speed, so that is what the unit AI used. This turned it into effective anti-air as it could fly to the generally-static height of other aircraft and spawn bombs inside them, for massive damage. We eventually added an arbitrary target restriction to prevent this for non-gunships, but needing to do this is a red flag. On the complication side of things, Raven gained many ways to be stupid, such as diving too low too early against particularly fast raiders, and never catching them.

The second problem was visual. Raven diving down to engage speedy units in melee looks a bit silly. Especially with its relatively wide model. Flying low also looks weird around uneven terrain, since Raven has to climb quite steeply to avoid bumping into it. So, after a decade of dive, we gave the idea of firing from cruising altitude one more try.




The final rework resulted in one of the more complicated weapons in Zero-K, especially compared to how important it is for players to understand in detail. But each detail solves a specific problem, so here we go.

Modern Raven shoots a homing missile, but unlike other missiles, this one is constrained to only ever point in the approximate direction of the ground. The result is a sort of guided "parachute" bomb that manoeuvre itself to hit anything within a cone below it. The firing logic takes the speed of the bomb and angle of the cone into account when determining the likelihood of a hit. Structures will be shot at maximum range, while slow units can be shot at a slightly reduced range. There is a minimum firing range, to avoid the Laser Raven problem, and quick raiders can even outrun the bomb. Raven still tries to hit raiders, as not doing so could look like a bug, and it can always be used as a zoning tool in an active battle.



We finally have a Raven that can be relied upon to shoot at and hit a commander, with the exception of the jump Recon commander, but it pays for this ability with reduced health. Speaking of which, jumpets and Raven grapple with similar design issues, as they can create high-swing outcomes. The difference is that jumpjets started off reliable, and we had to resist adding jank, while precision bombing is inherently difficult, so it took many years to find a solution that is both reliable and physically sensible.

Raven is too big for one post, so expect more Raven facts in the future, such as why bombers need to reload, or why terraform necessitates the inclusion of a bomber that can shoot underwater and straight down.

Index of Cold Takes

Zero-K is freer than the average free game. Even the fact that none of it is locked behind payment or grind surprises people, but it goes deeper than that. Zero-K is free software that anyone is able to modify to suit their use, provided they also share it freely. This might be even more surprising. Surely it cost quite a bit to make a fully-featured RTS, so why is it all free - and who paid for it? In short, nobody was paid for anything, because Zero-K was entirely built by volunteers in their free time. It all works because it is free.

First, some caveats, since the above is technically incorrect in a few ways. Donations cover the cost of running the server, and these donations are rewarded with commander skins and a badge on the forums. Which means there is something to buy, although it is nowhere near the scale of full cosmetics stores. I also have a Patreon of a few hundred dollars per year, and if you want to get really nitpicky, then sequential missions in a campaign are technically a form of locked content.

Zero-K inherited its license from the early community around the underlying engine, the Spring Engine. Spring was created by a Total Annihilation clan called the Swedish Yankspankers, and was initially designed to run TA content. They released the engine in 2005 under the GNU General Public License (GPL), which essentially allows anyone to modify their code provided that they release the changes under the same license. I do not know why they picked the GPL, perhaps they were involved in free software more broadly, but it seems like it was a deliberate choice.



The GPL is a restrictive license in the sense that it limits your ability to retract the freedoms it provides, but this is great for contributors who want their work to remain free. So Spring attracted developers and grew, as did the games it ran. The GPL also applied to code included in the games themselves, which formalised the kind of sharing common to well-functioning modding communities. This expanded the effective feature list of the engine faster than any team could do alone, for example, morph and jumpjets are game-side gadgets that showed up in a few games. Projects could even split completely to take different directions, which is how Complete Annihilation, the predecessor of Zero-K, forked from Balanced Annihilation. The engine itself was even forked recently (and renamed to Recoil), demonstrating how the GPL allows projects to outlive their maintainers.

It might sound like Spring revokes all notions of ownership, but remember, games are not just code. The license treats games as packages of content with independent licenses, and explicitly omits art from the GPL. There was even a commercially released game called P.U.R.E. that put proprietary licenses on its art. Some of the rationale for the carve-out was that art is static and game-specific in ways that code is not, so most reasons to share code are absent from shared art. In any case, it means that Zero-K is freer than the engine licenses require, so we need to cover a bit more of the history of early Spring.

Spring was in an awkward spot in the late 2000s. A handful of Total Annihilation mods had been ported to Spring and were still using TA models from 1997. This was, at best, legally dubious, and did not look good, especially to the developer of non-TA games who put in the work to make original art. The art carve-out was even clarified to avoid the nice new art lazily appearing alongside stolen TA content, without permission. So the idea of replacing the TA models was ever-present in the community, with modellers releasing packs of models from time to time, all released in the spirit of free software. Complete Annihilation was the first game to embrace this goal, and we even set up a model repository to track remodelling efforts.



Zero-K was born of the final push to rid Complete Annihilation of the old TA content. At some point we realised that most of the remaining old models were units or structures that were essentially duplicated between Arm and Core, so we focused our efforts on remodelling the remaining interesting units, and dropped the rest. This was the impetus behind factories as factions, although it is also backed by solid design principles. Some remodelling of remodels continued after Zero-K emerged, as well as the addition of new units in cases where an old unit was remodelled multiple times. This is why both Jack and Buoy are based on the old Can.

Zero-K continues to be free to honour the dozens of people who contributed with the understanding that it would remain free. That, and the non-commercial licenses used for some of the models, and most of the sounds. The disadvantage is that volunteers are often low on free time, and boring tasks languish, but the advantage is that anyone can contribute. There are no licenses to navigate, just clone the repository and start developing. The occasional player gets involved, builds their expertise, and becomes part of the development team. It is how I started, although it is admittedly harder with less low hanging fruit to be plucked. Luckily, the licensing of Zero-K also makes modding a great place to start.



The volunteer development model continues to pay off, with many of the coolest features of the last few years being one-off projects by keen community members. ThornEel's plasma cannon trails are just the most recent example. These improvements compound over time and have the advantage of addressing what at least one player would like to see, rather than being handed down by a developer who might not play the game. Everyone being a volunteer means that these ideas can take longer to bring to fruition, but some tasks even benefit from being worked on slowly. For example, changes to terraforming and aircraft had to percolate through the playerbase for years, with the long timeframe giving us the time to iterate and get things right.

Most ideas can be tackled relatively quickly and a lot can be learnt on the job. We especially need volunteers in our weaker areas, such as marketing. If you would like to see something polished up or added to Zero-K, come talk to the current volunteers and consider contributing.

Index of Cold Takes

P.S. I've been using the term Free Software over Open Source on the advice of Richard Stallman to push back against the corporate open source bandwagon. The strengths of Zero-K and Spring/Recoil come from being free, not merely being open source.

This update sports fancy new plasma cannon visuals and an engine update. The engine update is fairly well tested by this point, and should resolve a few rare crashes and improve performance. It might need a bit of time to scan your maps when you first launch the game. In terms of balance, the game seems quite stable and the recent Felon nerf is still being assessed, so we only touched the second-smallest and second-largest turret.


Picket requires an extra Ronin shot.

• Health 340 -> 375

Disco Rave Party almost turns as fast as it used to.

• Turn rate 3 -> 4 degrees per second

• Plasma cannon trails! (thanks ThornEel)
  
• Made a start on Japanese localisation (thanks syuumu200).
  
• Fixed the way a few units handle projectiles in Tech-K (thanks XNTEABDSC).
  
• Lobster cooldown is now shown in the selection windows (like other manual fire weapons).
  
• Big Bertha now only fires into terrain when force-fired a the ground.
  
• Added Skuttle as an option for automatic unit marking.
  
• The Reset button on the ingame menu now resets hotkeys as well as settings.
  
• Reorganised the camera change settings for and de-duplication and clarity.
  
• Units built in a factory while under a cloaker no longer take 8 seconds to cloak.

Light units are great at absorbing large amounts of burst damage. A burst, i.e. a single high-damage shot, from a Heavy Laser Turret may evaporate a Flea, but at least it only kills one Flea. Recluse also dies in one shot, and costs ten times more, so Flea is a comparatively efficient absorber (or rather, waster) of burst damage. High burst and wasted damage is used throughout Zero-K, in part to fill a gap left by our no-damage multiplier policy, but mostly to fulfil a desire for big impactful weapons.



Burst is nothing new, since reload time is fundamental to RTS, and most games have at least some variety. Discussions in Zero-K also use "alpha" as a synonym for burst, which a quick search suggests may be due to early cross pollination from Eve Online. In terms of balance, there is a tradeoff between burst and sustained damage (DPS), as burst tends to make a unit more powerful, with the large caveat of wasting damage to overkill. Burst lets units front-load damage, since they start the battle fresh, which increases their effective damage output and limits retaliation. In terms of the feel of the game, large units one-shotting smaller ones reinforces a sense of scale, and the potential for burst adds variety and excitement to battles.

Zero-K likes to explore the extremes of design space, so we have ended up with some quite bursty units. Lance fires once every 23 seconds, significantly more than the six second fire rate of its ancestor in Total Annihilation. Such a long reload time would not be out of place on a manual ability in other games, and Zero-K players often use these weapons as manual abilities. This is done by toggling the hold fire unit state, which lets players take direct control when required, without fighting the UI the rest of the time. Units exist across a range of reload times, with units even as low as 10 seconds frequently being set to hold fire to snipe commanders.



As alluded to earlier, burst can be used to specialise weaponry against heavy units. Raiders swarming a Heavy Laser Turret is the classic example, but this applies whenever a projectile from a heavy tank or artillery piece would deal far more damage than necessary. Conversely, riot units should have low reload times, to deal with swarms of units. Raider against raider is an interesting case, since a bit of burst is quite an advantage, but one that can vary a lot across matchups. The bursty light raiders - Duck and Dagger - have been particularly hard to balance, and are yet to find a really good spot. The problem is not even due to raw overkill, but rather, the more subtle issue of breakpoints.

Burst damage is important even when it is not dispatching foes in one shot. Consider Dagger, a light raider that deals 110 damage every 2.83 seconds. Light raiders have between 200 and 500 health, so the exact damage of Dagger compared to the health of any given raider can be quite important. For example Bandit has 340 health and Glaive has 230 health, letting Dagger kill them in four and three shots respectively. If, for some reason, Bandit needed a nerf against Dagger specifically, we could reduce Bandit health to 330. This would barely affect its other matchups, but would effectively reduce its "health" against Dagger by 25%. Alternatively, we could increase Dagger damage to 114. The current incarnation of Dagger has dealt as little as 95 damage, but no higher than 110, because we do not want to cross the Bandit burst threshold.

Some weapons are so impactful, so ubiquitous, that they warp the rest of the game around them. The prime example is Raven, a bomber with an 800 damage bomb. Bombers shoot one shot before returning to base to reload, so their burst is very important. Raven was the dominant bomber for over a decade, so units lived or died on their interaction with it. The lightest riot unit - Reaver - has 820 health because being sniped by a single Raven leaves its factory too vulnerable to raider follow-up. Mace, which costs nearly twice as much as Reaver, has been plagued by only having 1400 health, and Light Laser Turrets have 785 health to let Ravens clear them out. The Recon Commander Chassis has 3250 base health, because commanders were balanced around how expensive they were to bomb. Factories have 4000 health because it is assumed that a nearby constructor can repair them mid-bombing, allowing them to just barely survive five Ravens.



Other sources of burst damage are important, but not as impactful. Lance deals 3000 damage with its heavy laser, further preventing commander health from dropping below 3000. Similarly, Phantom, a cloaked sniper, deals 1500 damage. Phantom demonstrates how balancing around breakpoints can become a bit silly, since Felon was buffed to 1600 health specifically to avoid being one-shot by Phantom. The Felon is the signature Shieldbot unit, and costs almost as much as a Phantom, the signature Cloakbot unit, so losing it in one shot was too punishing. Tuning Felon health to Phantom burst let us make a change that barely affected other matchups, since dealing an extra 100 damage is not too onerous for most other units. So burst is a good tool for precision-balance, however, overuse can make interactions feel gamey, less "natural".

Imagine a Felon with 1501 health. At a mechanical level, such a unit is fine, but it would look odd whenever it survived a Phantom shot with one hit point. The injunction against Felon having 1501 health is akin to the verisimilitude principle from Aim and Fire, namely, that a "real" Phantom could surely "overclock" its rifle to eke out an extra 0.1% damage. So it is for this reason that we stick to reasonably round numbers for health and damage. A Felon with 1600 health looks more natural, even though 1501 health would achieve the same balance goal.

There is a limit to how close damage can be to health, and that limit seems to be 20. Consider Reaver with its 820 health against Raven. Two other cases are evident in the precise light skirmishers: Moderator and Scalpel. These units deal busts of 460 and 660 damage respectively, and each have 20 more health than their burst. We decided, long ago, that having such units 1-shot each other was far too swingy, and that making units uniquely bad against themselves would encourage more interesting army compositions. Lance does not get the same treatment, since being unable to see as far as they can fire already creates enough counterplay, and artillery should be particularly flimsy.



Revenant vs. Engineer Commander is a notable recent example of balancing by burst breakpoints. Revenant is a tanky gunship that fires a burst of medium damage missiles, and it was a bit underpowered, so we gave it an extra missile. This increased its damage to 1980 (9 missiles, 220 damage each), which let it 2-shot un-upgraded 3800 health Engineers. This went unnoticed for many months, until Engineer gained the blueprint ability, increasing its popularity on the front lines, which in turn increased the viability of rushing a Revenant to snipe commanders. The resulting nerfs included reducing missile damage to 210, for total burst of 1890, leaving Revenant 20 damage shy of 2-shotting Engineers.

Burst creates a threshold effect for health and damage, but it also creates thresholds for time. This is best seen with anti-air and bombers, since bombers only stay in range for a handful of seconds. The result is a sensitive relationship between the reload time of anti-air, and how long the planes hang around in range. A weapon can be good on paper, but be underwhelming in practice if targets tend to leave range just before it reloads. Burst also helps specialise anti-air into anti-plane and anti-gunship. Anti-plane weapons tend to be bursty missiles, with high alpha damage to deal their damage early, while anti-gunships weapons are geared towards high damage-per-second, since gunships hang around to deal their damage, and are likely to kill bursty anti-air before they get off their second or third shots.



Balancing by burst breakpoints runs the risk of filling the game with opaque and unintuitive interactions, much like an overreliance on armour classes can in other games. No player is going to know, without any experience or research, that Revenant can only 3-shot Engineer Commanders. Repeat for the 25-or-so units with reload times greater than five seconds, and there is a potential memorisation problem. Many of these units deal imprecise area-of-effect damage, which fuzzes the breakpoints, while others deal such large bursts that their damage may as well be infinite in most cases. For the rest, there is a part of the interface that shows the combined burst damage of the selected units. This also helps people who happen to have individual burst damages memorised.

Even weapons with nominally precise burst damage are slightly fuzzy in practise. Projectiles can miss, and burst lasers deal damage over the 30 game frames that make up a second. This adds an asterisk to the relationship between Flea and Heavy Laser Turrets (as well as Lance and Grizzly), as a few tightly packed units can all die to the same laser shot. This anti-swarm capability is not ideal for Quant's Rule, but physical beams of death are far cooler, and lets players pull off tricks such as lining up two light turrets to kill in one shot. It would be easier, and more "balanced", to have lasers deal a single instance of damage, but, in the end, feel trumps balance.

Index of Cold Takes

Zero-K technically has "space" combat. This is true of any game where units can end up high in the sky, and where being very high up has any mechanical meaning. In our case, extreme height makes units immune to weapon fire from below. Even missiles with cylindrical range have a fuel limit that gives them a maximum reach. As a result, advances in space travel tend to be patched out, which is notable because we generally err on the side of keeping creative special tactics in the game. But over time, the "Zero-K cannot into space" rule has emerged as a result of space travel being so non-interactive. Viewing space alongside the ground also causes interface issues.

Complete Annihilation saw our only fully intentional foray into space. This was the original Owl, a spy satellite (probably) added by CarRepairer.

This stealthy orb can serve as a spotter for your artillery or spy on an opponent's base. It uses a lot of energy to stay in the air but is safe from nearly all units. Vulnerable to advanced fighter planes and long range missile towers.

It flew 5x higher than the highest aircraft (Nimbus), moved slower than the slowest ground unit (Jugglenaut), and had a tiny 300 elmo sight range. It cost 300 metal at a Core Gunship Plant and, as per the description, could only be shot down by the heaviest ground-based anti-air and air superiority fighters. In other words, this unit only interacted with Artemis and the missile-based Raptor equivalent of the day.



Owl did not last, and became the namesake of the term "To Owl" something. It was nerfed to the point of uselessness because the main balance designers didn't have the heart to remove it, but could see how troublesome it would be if it were at all common. If the enemy had a Plane Factory, then it is just dead, but without access to planes it required very expensive anti-air to dislodge. The hard-counters were too hard and too expensive, while there were zero soft counters. So it was soft-removed, and did not survive the transition to Zero-K.

The reception of Owl set the pattern of subsequent space exploration, and the lack of direct support fostered creativity. People would have to repurpose units to achieve their space dreams, with the main culprits being the gravity shenanigans of Newton, Lobster, and Placeholder. Each of these units has been patched to curtail space travel, although Newton has received the most attention, as the oldest of the three.



Newton is a turret that uses gravity guns to attract or repel targets. Units are allowed to aim and fire at anything, provided there is some reason they would want to, so Newton can target allied units. People quickly realised that Newtons could fire units across the map, with terraformed ramps to help aim and angle the shots. These Newton Cannons were the first form of "space" travel, yet they still exist today, which seems at odds with the injunctions above. What makes the current uses of Newton "legitimate", and what else had to be patched out?

Space is a problem when it dominates entire parts of the game, with little or no counterplay. Newton cannons sometimes win games, but they are hardly a source of cheap, unblockable, death from above. Most Newton cannons launch jumpjet units, but these can be seen as they float down, and shot down in the sky or intercepted. It is a fine back-pocket strategy, but can be countered without too much more investment than it costs. It is also quite important that the units barely go to space, i.e., they can be seen at a comfortable zoom level. The worst cases of space travel let units fly so high that the map is merely a tiny square in the distance.



The first dominant Newton cannon strategy was due to Skuttle, which is a troublesome unit that can cloak, jump, and explode for massive damage. The first issue (mentioned last year) was that it used to be able to jump from space to float down, cloaked, onto the enemy base. The only theoretical counter was to hover gunships above everything important, and station overwhelming firepower nearby to kill the Skuttle in the brief proximity decloak window. So we invented jumplegs to stop Skuttle jumping while mid-air. But this did not stop people raining cloaked death from above.

The next issue with Skuttle turned out to be a broader issue with gunships. A gunship can be pushed by Newtons, but cannot crash, which makes it great for safe space travel. A transport with a Skuttle could be shot high into the sky, beyond the range of anti-air, and flown over the enemy base. Then the Skuttle could be dropped onto important targets below, cloaking on the way down. This prompted a few changes. The first was a general nerf to gravity guns such that only 25% of the vertical component of their force applies to gunships. The second was a targeted nerf for transports, namely that they accelerate downwards towards their desired height faster (a buff in any other situation), and they give units a small random push when dropped, to remove the precision of orbital drops.



Gunships can cause issues without the help of Skuttle. After high-flying gunships were blocked, people began experimenting with horizontal "space". Newton cannons can be designed to shoot gunships sideways off the map, beyond the range of ground anti-air. This let transports and Krows sneak around to the back of the enemy base without having to penetrate front line defenses. The tactic has far more counterplay than orbital Skuttle, but by this point out-of-bounds tactics were established as an exception to the usual protection of creativity. So we put a stop to gunship slingshots by pushing aircraft back into the map, with a buffer zone of 400 elmos, which is approximately the turning circle of the most cumbersome aircraft. Planes could be launched off the map too, and the buffer even had to be halved with the more recent addition of Odin.

Another borderline, yet still ultimately removed, tactic was the Flea launcher. Fleas are cheap and very light, which makes them cheap to launch with a basic Newton cannon. The issue here was that sight ranges are cylindrical, or 2D, by default, which made Flea launchers dominate other lategame scouting options. We were happy with the spread and effectiveness of other, more nuanced, forms of scouting, so the Flea launcher was nerfed. The nerf involved dynamically reducing the sight range of launched units, to approximate a form of 3D sight range (the actual shape is a cone twice as high as the sight range). Players are still free to scout by shooting Fleas at fast, low, trajectories, but this requires a much more expensive Newton cannon.



What of Lobster and Placeholder? Both units used to be able to create self-powering floating space stations, arbitrarily high in the sky. Lobster achieved this by continually firing a large enough clump of Lobsters, since it used to be able to shoot while mid-air. Placeholder can target allies, and tends to lift its target slightly above the ground. Enough Placeholders can form a self-sustaining clump that gradually drifts upwards. The major issue here is that disappearing into the sky makes defeat almost impossible, and Zero-K prides itself on having a better draw situation than Chess. Sky bases are also good places to give ballistic weapons a height advantage, although this is a cool ability, provided it does not become unreasonable.

Space Lobstervator and Placestation were removed on the same day, shortly after Lobster's defeat-avoiding ability was showcased. The fix in both cases was to make the abilities of Placeholder and Lobster decay with height. Lobster cannot boost anything more than 400 elmos above the height of the target terrain, and since then lost the ability to fire while mid-air. A Placeholder shot exploding more than 1200 elmos above the ground has no effect. This happens to be the altitude of the old Owl, although the ramp down to 1200 means that in practice the mass will float around 1000 elmos up. So units can still be maintained quite high in the sky, just not arbitrarily high.



The last, and silliest, way to go to space is due to Dirtbag. The idea is as follows: Dirtbags drop a bit of terrain when they die, so why not stack 500 or so on a single position, then detonate them? The result is a very thin, very tall, spike. This became a problem when people figured out how to glitch Crabs up this spike, which let them shoot at absurd ranges due to their ballistic trajectory. This sort of thing is a neat creative way to create instant spires for Crabs, but the spires could be so high that the rest of the map becomes a few distant pixels. We patched this out by limiting the steepness of terrain created by Dirtbags. Such spires are now limited to 800 elmos, which is still significant, but do not turn Crabs into full-map artillery.

That is it for ways to go to space, apart from simple bugs, such as a bug that let players store impulse and release it all at once. That is also about it for creative tactics that have been patched out, since by and large we try to keep them in, with Newton cannons being a prime example. Space is the main exception, since it is too far removed from the terrain and interactions that make Zero-K great. The same can be said of underground units, but since that was only an ability for one chicken, I would not expect an article on mobile burrowing any time soon.

Index of Cold Takes

Strategy games sometimes offer extra ways to detect the enemy, beyond the standard line of sight, with radar being a classic example found in Zero-K. Radar reveals quite a bit about player interaction, but we will also have to flesh out vision itself, since the two systems complement each other. Both systems use the same underlying mechanics, which were covered last time, although the details are not strictly necessary for understanding how the mechanics are used.



Radar is great because it achieves a lot in the design, yet is mechanically just a variant of sight. In Zero-K radar differs from sight in one way: it only reveals the approximate position of units, nothing else. The type of unit is not even revealed, although this information is remembered for previously scouted "radar dots" (to avoid fighting the UI). In terms of how the mechanics are used, the two systems could not be more different: everything has a sight range, while only a few specialist units and structures have radar. Radar can also "see" a lot further, with most radar ranges being around five times that of the average sight range.

The main purpose of radar is to allow for direct interaction outside combat. By direct interaction I mean interaction with a tight feedback loop, where you and an opponent can see and respond to each other in real time. Sight alone limits players to relatively short-range interactions, which are likely to turn into fights. Various forms of dedicated scouting can allow for more out-of-combat interaction, but that risks making information too cheap. Radar admits a middle ground, one where you can respond to large scale army movements, without being overwhelmed by information or cheapening the fog of war. Of course, if you know where the enemy is, then you should be able to shoot at them (again, to avoid fighting the UI), but to expand upon the implications of then we need to take a detour into sight.



The details of sight boil down to the following question: how far should units be able to see? Our answer is, for the most part, "Just a bit further than they can shoot". This is a deliberate reversal of the situation in many other games inspired by Total Annihilation, but the idea was that it is more satisfying to fight visible units than radar dots. A more thorough justification is that vision on the enemy is tactically powerful, and that scout units mostly gate such vision behind fiddliness rather than any significant tactical or strategic decision making. This stems from the fact that scouts are cheap, can see further than the average combat unit can fire, and are fast enough for death to be a Fighting The UI problem. Mixing scouts into an army is often just optimal, since it lets everything see their targets, but giving this job to scouts mostly amounts to giving them an extra way to be stupid. So to skip this whole rigmarole, we just let units see as far as they can shoot.

A notable exception to the above is artillery. Scouting targets for artillery is satisfying, as the scout has to be sent somewhere dangerous. To support this dynamic, artillery cannot see as far as it can shoot. In fact, we have a general rule that units can see 10% further than they can shoot, to a maximum of 660 range, which is is around the range of a Heavy Laser Turret. However, there are many exceptions to this rule. Some are due to technical necessity, such as the granularity of the vision grid requiring that particularly short-ranged units see a bit further. Other exceptions are deliberate design choices, such as the uniquely long sight ranges of Radar Towers, Owl, and Toad. Others, well, unarmed structures have a sight range of 273 for reasons lost to time, and the sight range of unarmed constructors appears to be essentially random.



By this point artillery seems to have two conflicting constraints: that we want to encourage spotting, and that units should be able to fire at radar dots. The solution, revealed paragraphs ago, is to make radar only reveal the approximate position of units. This is implemented via "radar wobble" - a drifting random offset of the radar dot relative to the unit's true position. Wobble discourages pot shots at dots, since they are likely to miss, so spotters have to venture out to gain vision. Radar wobble brings its own problems though, which we try to mitigate with various UI features. The main one is that radar wobble is removed for scouted structures, since structures cannot move. There is also a state toggle to tell particularly precise artillery to avoid firing at wobbly dots, although it is not enabled by default, for reasons that would require a whole extra article.

What about saturation artillery? A few artillery units are far too inaccurate to care about radar wobble. In this case, shooting at radar dots is a feature. An astute reader may recall a principle that comes up in the design of cloaking, namely that it is frustrating to spend all your time telling unit to shoot at unseen enemies that you know to be present. The same issue arises with area-denial artillery, and is mostly solved by shooting at radar dots, because doing so simulates players making guesses about likely targets just outside their vision. Situations without radar, or with jammed radar, can counter this ability, but this is acceptable because the goal is to make units handle themselves in the majority of cases, just enough to alleviate the repetitiveness of always handling saturation artillery targeting manually.



By this point, it is clear that radar is central to Zero-K, and we encourage this further by making radar very cheap. Not only do commanders have free onboard radar, but the basic Radar Tower almost free. This is a great example of balancing relative to how common a unit should be, rather than by absolute usefulness. Radar Towers also perform double duty as artillery spotters, with an unusually large sight range, which incentivises players to place flimsy structures in outrageous locations, which makes for great target practice. Advanced Radar Towers have even more sight, and 250% the radar range to boot, but cost a considerable amount of metal. This makes Advanced Radar much less common, but their utility lies in viewing the enemy base, which we are less interested in encouraging. Advanced Radar also used to reduce radar wobble, however this reduces the importance of spotting for artillery, so the ability was removed.

The most incongruent part of radar is the fact that radar dots have team colour. This leaks information to the enemy, yet team games rest on the idea that ownership within a team has no mechanical importance. This means that, if you know that the orange opponent has heavy tanks, then a slow orange dot is more likely to be a tank. Supreme Commander solves this with grey unidentified radar dots, and there was talk of adding such a thing to Zero-K, but I have been coming around to the idea that perhaps team colours on radar dots improves the game. At least in casual team games.



Team coloured radar dots efficiently tell your team how many opponents are present on each front, and it adds to the community feel to see who you are up against. It helps distinguish the aircraft of enemy air players, although in this case the vertical position of the dot is often sufficient. The principled stance against coloured radar dots would also advocate for removing enemy team colour entirely, turning the opposing team into an anonymous blob, which certainly feels bad for a somewhat social game. In any case, I would like to experiment with truly unidentified radar dots, but I fear the effect might be too far-reaching to measure in a short-term test. In any case, such tests will have to be postponed until the engine supports such a feature.

Index of Cold Takes

Welcome back to Cold Takes for 2025. The goal this year is to post one every three weeks, but to not fight for space with patch notes.

Just about every real time strategy game has fog of war. Without it, you could watch the enemy base and start countering anything they do. This dynamic can work - there are whole genres built around perfect information - but it seems ill-suited for games with incremental real-time decisions that take time to pay off. But before delving into the role of vision, it is worth taking a look at how it works.



Fog of war can be dead simple. All you need to do is draw a circle around each unit and structure, then declare everything within a circle to be visible. Plenty of games stop there, but I suspect the majority take the extra step of considering terraces and trees. A terrace sight system has clearly defined levels of terrain, with units on lower levels unable to see onto higher ones, and games often block sight with opaque static features, such as trees and buildings. And such simplicity works great, up until the simulationists get involved.

Games of the TA lineage are more simulationist than your Starcrafts or Command and Conquers. That is, they care more about mechanics that match reality, or at least seem to match reality. Zero-K often downplays this aspect, but it is still a bit too simulationist to use a terrace-and-tree sight system. For one thing, we care too much about terrain to approximate the expressiveness of hills and mountains by a series of plateaus with ramps between them. This makes the simulationist route attractive, but it is hard to know where to stop without clear guidance from other design goals.



Before thinking about those goals, it is instructive to consider what fully realistic sight looks like. Such a system would involve drawing straight lines between the "eye" of each unit, and everything the unit might want to see. If the line has a clear unobstructed path, then the unit can see the target, and we can even draw lines to the edges of units to see them when they poke around corners. This is a general technique called ray tracing, and it reflects how light behaves in the real world. But would such a system work for Zero-K, what does the rest of the design have to say about it?

To cut the chase, we will appeal to fight your opponent, not the UI. In short, the interface is your friend, it should not get in the way, and it should tell you everything you need to know about your forces. This includes information about what your forces can or cannot see. An interface that fulfils this promise has to be clear and simple, which is a problem for realistic sight. The crux of the matter is that you need to know what you don't know.

Any old sight visualisation can tell you what you know you know. If you can see a giant robot peeking over a cliff, then the UI just has to draw the giant robot. But how do you rule out the existence of a sneaky medium-sized robot? The UI has to tell you whether you would be able to see one if it were present. The standard solution - spooky black fog - is a great representation of the unknown, but it breaks if you try to do too much with it. Fog is inherently fuzzy, so how is it going to tell you that you could spot a giant robot, but not a medium-sized one? Shifts in opacity are hard to make out to any degree of accuracy, and clearer cues such as contouring or colour coding would be quite busy. So Zero-K straight-up avoids having the visibility of a unit depend on its size.



Here is the trick to line of sight, used by many games: units never actually see each other, they only ever see parts of the terrain. The line of sight shader blurs this fact, but vision works on a grid, with the visibility of a square determined by ray traces to the middle of each square. The ray starts at the "eye" of each unit, so tall units are better at seeing over terrain, while the end hovers a fixed distance above the terrain (or the surface of the ocean). Units are visible if they are on visible terrain, which makes the potential visibility of enemy units very easy to tell the player.

Zero-K sight is still a bit janky compared to simple terrace-and-tree. Smooth terrain makes it difficult to precisely predict what one of your own units will be able to see when it reaches a given location, but this is significantly better than not even knowing what it can see once it arrives. To ameliorate this further we tune the heights of the hover ray trace targets to be fairly forgiving, although in theory they represent the height of an "average" unit.

So there you have it, sight detection in Zero-K is based on whether a unit of "average" height would be visible, because doing it this way allows for simple binary fog of war to tell the player everything they need to know. Except, this is only actually true for ground units. It is time to talk about the exceptions.



Projectiles, explosions, and non-landed aircraft ignore the usual sight rules, instead, using a circular sight system called air line of sight. This is a parallel sight system, but we make sure the air line of sight range of everything matches their standard line of sight range. The system is a nod to realism, since it lets you see planes without being able to see the terrain underneath. On the visuals side, it is nice to have projectiles not blip out of vision when they are fired over a ravine. Why not add air line of sight for particular giant robots? Consistency and clear thresholds; a plane is clearly a plane, but there is no clear cutoff between giant and non-giant robot.

Except, that is not quite true either, as giant robots can often be seen by air line of sight. In fact, anything that has fired a weapon in the last few seconds is visible to air line of sight. This is sensible, since muzzle flares are hard to hide, but it also solves a few edge cases. Without this mechanic you would be able to position turrets behind tall cliffs, making them very hard to target, but still able to shoot at approaching units. As a bonus, a giant robot that spots your base over the edge of a cliff is likely to start shooting at you, so it is almost as if it were visible to air line of sight to begin with.



Sometimes I wonder how many people know about air line of sight. It is one of those mechanics that smooths things over in the background, making the game look good and make sense. Being unaware of it seems fine, and there is a cost to making it more visible. I know from experience that varying the opacity of fog does not look great, because air line of sight used to be drawn as a lighter form of fog. The engine default for air line of sight is 150% of sight range, but we override it to match sight range so that we can avoid needing to draw it (see above). I picked a map with good contrast for these images, but in general it is hard to make half-opacity fog of war sufficiently visible on all maps.

Zero-K also has radar and sonar, but they are nothing new to someone who understands line of sight. Radar is just a form of sight, ray tracing to the same points hovering above the terrain, while sonar is a simple circular system. It turns out the engine developers did not want to implement a full acoustic wave propagation and detection system. That is it for sight. Why units would want to see each other will have to wait, but at least there is now a record of how.

Index of Cold Takes

This patch has a slew of balance changes and a new game mode. Shieldball and Phoenix are the focus of the nerfs, but there are many more tweaks that ended up touching most of the factories. Some more notable ones are Bulkhead being worse at short range, and some cost reductions for the surface-only short-ranged ships.

The new game mode is called Tech-K, and it is a look at what Zero-K might have looked like with tech levels. There are infinite tech levels, because anything else would be arbitrary, with each level doubling the cost of units while slightly-more-than-doubling their power. Feedback during testing ranged from "Works surprisingly well" to "Not what Zero-K is about", so give it a try. It could be fun to run it as a tournament or other event.

Tech-K can be enabled in any game type via the Experimental tab in battle options, and more information is available on the wiki. The mode was partially created to motivate improvements to the dynamic unit attributes system, so there are API changes and extensions that mods will want to take into account.


Thug and personal commander shield offers more protection from area damage.

• Shield radius 80 -> 90

Felon is slower and less efficient.

• Speed 45 -> 42 elmo/s
  
• Reload time 0.133s -> 0.166s
  
• Shield drain per shot 75 -> 78

Aspis mobile shields are significantly more expensive (no change to Aegis).

• Cost 600 -> 700

Bulkhead has more downtime while being swarmed by raiders and assaults.

• Cost 230 -> 240
  
• Turret turn rate 180 -> 120 degrees/s
  
• Reduced targeting priority against gunships.

Magpie enjoys round numbers.

• Rearm time 13s -> 12s

Phoenix is more expensive and takes much longer to fire twice.

• Cost 460 -> 520
  
• Rearm time 13s -> 18s

Locust exploits its unenviable balance position to experiment with speed.

• Speed 212 -> 250 elmo/s

Nimbus can see as far as it can shoot.

• Sight range 600 -> 660

Mason gains a unique power among the cheap constructors.

• Build range 180 -> 210

Ripper should fare better against heavy raiders.

• Range 280 -> 290

Bolas is slightly faster.

• Speed 96 -> 97.5 elmo/s

Flail kills Magpie, Phoenix and Thunderbird in one fewer shots.

• Damage 375 -> 475

Kodachi is slightly slower.

• Speed 108 -> 106.5 elmo/s

Cyclops is harder to manoeuvre, as befits its weight.

• Turn rate 82 -> 74 degrees/s

Cutter is swarmier.

• Cost 65 -> 55

Corsair hopefully still has a counter from the Hovercraft Platform.

• Cost 240 -> 220

Reef repairs aircraft much faster than land-based airpads.

• Repair buildpower 2.5 -> 10

Hacksaw responds to a bit of power creep.

• Cost 220 -> 210

Wind Generators can be built diagonally with slightly larger gaps.

• Grid range 60 -> 63

• Added the Tech-K game mode.
  
• Manually shared units now clear their command queues.
  
• Chainsaw no longer avoids small targets by default.
  
• Players can now define multiple albums adding war, peace, victory and defeat folders to sounds/music/<your album name>(thanks Helwor).
  
• Increased the maximum configurable fade height for healthbars (thanks amnykon).
  
• Added an option to reduce the selection rank of rearming units (thanks amnykon).
  
• Added build range to space+click stats.
  
• Added units to buildpower in space+click stats.

• Fixed playerlist lag indicator (thanks Shaman).
  
• Workaround jumping units sometimes moonwalking when they land.
  
• Fixed minimap mex drawing when flipping the camera (thanks christianweinz)
  
• Mitigate a playerlist error caused by the host of an AI leaving (thanks Shaman).
  
• Fixed non-default music album selection (thanks Helwor).
  
• Fixed Nimbus gun flare (thanks XNTEABDSC).
  
• Fixed Bulkhead sometimes being unable to deploy when slowed (thanks XNTEABDSC).
  
• Fixed the default position of replay controls on large monitors (thanks ThingsWillCalmUp).
  
• Fixed bad socket error handling in the lobby (thanks saurtron).

Reworked the application of dynamic attribute modifiers.

• Attributes are now added via Attributes.AddEffect(unitID, key, effect) and removed by GG.Attributes.RemoveEffect(unitID, key).
  
• Effects are tables of attribute types. See the list here.
  
• Many more types of attribute can be modified, and many edge cases have been cleaned up.
  
• Spring.Utilities.GetUnitCost now takes GG.att_CostMult into account.
  
• The old method involved editing extra attributes into the unit_attributes gadget. The old attribute are still collated by this gadget, but all the effects are applied by the new system.

Other changes.

• Added gadget:UnitCreatedByMechanic(unitID, parentID, mechanic, extraData). Other gadgets should do gadgetHandler:NotifyUnitCreatedByMechanic(same signature) shortly after creating a unit. This allows gadgets to handle things like the difference between morph unit creation, and carrier drones.
  
• Added LuaRules/Configs/ModCommands as a unified place for mods to define commands, rather than via editing tables across a handful of files. See Tech Up for an example.
  
• Model scale, centre offset, and tint now survive /luarules reload.
  
• Fixed bugs with Lance and Crab model rescaling.
  
• The error caused by invalid reload times is now more informative.
  
• The command-counting use of Spring.GetCommandQueue(unitID, 0) is going to be removed. Use Spring.GetUnitCommandCount(unitID) instead.

Zero-K pushes the limit of team games in RTS, supporting up to 16 players per side - something that sounds impossible. Your average RTS caps out at 4v4, with a few going as high as 6v6. In Zero-K players regularly play games three times this size, and while such large games are not for everyone, I suggest trying them out just for the experience. There is a real sense of scale in a game with so many players, taking so many actions, in which you can only really zoom in and understand a relatively small part. But it is surprising that such games work at all, so in this article we are going to dive into the design that makes them possible.



The weirdest part of the story is that, for the most part, support for large team games came about accidentally. The rest of the Zero-K design philosophy just happens to inherently let teams have a large number of players. From time to time we added features aimed at large games, but most of the work is done by principles covered in previous cold takes. We could have deliberately removed large teams, but the attempt would warp the rest of the design, and it is not like they are hurting other game modes. Small games, down to 1v1 and 2v2, work fine, and the way I see it, supporting more game modes is good.

The bulk of the work is done by Fight your opponent, not the UI, plus the realisation that players coordinate with their team via the user interface. Essentially, cooperation within a team should be free of artificial limitations or hoops to jump through, in much the same way as any other action in the game. Zero-K contains simple examples of cooperation UI, such as the nuke indicator that tells players where an allied nuke is expected to land, but not fighting the UI goes deeper than that.



Zero-K is the game that designs the stupidity out of units and uses designs weapons using unattainable ideals, and we take the same approach to cooperation. Like units, players have abilities that influence the game, and we consider it a failure if the mechanics of the game force players down the route of boring and arduous use of the UI. So while most games would happily add a nuke indicator, few would go the extra step of excising fundamentally anti-cooperative mechanics to the extent that we do.

We inherited key player abilities, namely the ability to freely share units and resources, from Total Annihilation. This is a fairly standard function for RTS games, but the implications are far-reaching, and Zero-K has a penchant for taking ideas to the extreme and biting the resulting bullets. The issue with sharing is that sharing UIs are invariably some of the worst found in RTS. They tend to resemble big spreadsheets of fiddly buttons or sliders, which is not what we want in an RTS. So contact with this UI should be minimised, which relegates sharing to an almost "theoretical" ability, one that the game is designed around, but which players should rarely manually invoke. This generalises to the principle of the irrelevance of ownership:

Nothing in the mechanics of the game world is permitted to depend on the details of ownership within a team, because then players would be incentivised to touch the unit sharing UI to gain an advantage.

Few games use this principle, since it is automatically violated by player-specific upgrades. Even within the TA-lineage, Supreme Commander lets units of the same player shoot through each other, but not through allies. Even Zero-K violates the principle, since unidentified radar dots reveal team colour, which can let the enemy guess the identity of unseen units. This is something I have wanted to be able to turn off, but it requires engine work, and to walk back the extremism a bit, dot colour may well improve the game.

The principle of irrelevance of ownership sounds restrictive, but it is also quite freeing, and we were not going to add global upgrades regardless. A key implication of the principle is that resource income can be distributed arbitrarily within a team, without any theoretical impact on in-world game balance. In practise this let us fiddle with income sharing to "simulate" cooperation among strangers on the internet, which is part of what allows such large team games to work. For example, income from metal extractors is shared evenly between everyone on the team, which was called communism mode in early Complete Annihilation. Communism evolved alongside the rest of the game, and quickly became integrated with overdrive, since the overdrive formula benefits from shared resources.



The theoretical justification for communism is that securing territory is a shared effort, and much harder than merely building a metal extractor, so the team shares the benefit. The practical justification was more important at the time though, since we all had experience with people arguing over metal spots in Balanced Annihilation, which could escalate to teamkilling. A secondary effect in BA was the limited map pool; players tended to play a small set of maps, where everyone understood the meta of spot ownership, in part to lessen the potential for arguments over resources.

It is worth mentioning that I snuck an assumption into communism: that players want to cooperate. What if people want to keep their income to themselves? This gets at the core of the design: we assume that the team wants to cooperate, teamwork is the default. If players want to argue and destroy each other's buildings, then they might not find support for these actions in the UI. There is also a bit of a paradox here, as anyone who has played a team game with a range of skill levels can tell you: who owns what is actually very important. But instead of trying to judge the worth of each player, we opted to make a game where part of the skill is in being a good teammate, rather than rolling over the weaker members on your team as you grow your own personal empire.

Communism solved the metal spot arguments and opened up the map pool, but it suffered from the free rider problem. Some players would skip building metal extractors all together, hoping that their teammates would pick up the slack. Full communism was also not great at incentivising overdrive, even when it would significantly benefit the team. So we added rebates. For example, metal extractors refund 80% of their cost to the player(s) that built them, over a few minutes, in the form of a slightly increased share of the income. Energy structures offer a similar refund of 60% from their increased metal overdrive income. The numbers have been tweaked over the years, since a higher payback percentage can lead to perceptions of selfishness by energy spammers. We even recently introduced payback for the first few Antinukes built by a team, as a social way to nerf nukes in low-cooperation situations.



Shared metal extractors also helped with the "Tabula Problem" caused by some rotationally symmetric maps. Tabula has high terrain on its North and South, that is easier to take and defend from the North-West and South-East respectively. Before communism, Tabula was typically won by the team that invaded the weak low ground from the strong high groud, before their opponent did the same on the other side of the map. The low ground just lacked the metal income required to mount a defense, without players manually sharing units or metal extractors. Tabula continued to play a bit like this since communism, the low ground still has poor terrain, but the extra income makes the defense fairer and more interesting.

Income sharing alone is not enough to make large games fun. For that we need the rest of Zero-K, primarily its unit and faction design. Our large number of faction-like factories lets players carve out a distinct role and set of units within the team, and factory plop lets everyone build a factory without "wasting" resources. There was concern that the recent addition of factory plates would destroy this sense of having a role within a team, but the fear has not come to pass. If anything they seem to have improved team games by letting players take on a role they are not sure of, with the safety of being able to switch out of it cheaply.



The coordination feature that came closest to breaking the game was shared control mode, where players own and control the same set of units. The campaign has shared control, but it can also be enabled in team games via an invite system. The danger with shared unit control is that it can be powerful, but it is also quite annoying when someone else accidentally uses "your" units. This is the dreaded trade-off, power at the cost of fighting the UI, but the mode is barely used in public games. Tournament and campaign games are different, since people can communicate enough to avoid the downsides, and in these contexts it is a great feature.

As with many automation-type features, it is worth asking whether cooperation has been automated away. I think we are fine on this front; teammates send messages, flank, and otherwise help each other out. People still share the occasional unit to augment fronts that really need it. Mostly we have removed the excess UI interactions, and set a baseline level of cooperation so players can expand as much as they want without worrying about "stealing" metal spots. Perhaps the greatest benefit is too the map pool, as any map can be played with any number of players, for a really wide range of experiences.

This marks the end of the first series of cold takes. Twenty is a nice round number and it is time for a short break. Look forward to the next series starting in January next year.

Index of Cold Takes