Zero-K news & patch notes

Automation means making tasks complete themselves without player intervention. The concept has a bit of baggage, at least in RTS, as people worry it means that a game will play itself. Some spin-off genres have found success in automating away large parts of RTS, such as DotA and autobattlers, but Zero-K wants to retain the core RTS sense of full player control. Sometimes we are accused of automating too much with our powerful UI, but we hold that the value of automation depends on how it is used, as it is not inherently good or bad. What people consider to be automation can be quite hard to pin down since, technically, almost everything in RTS is highly automated. These games run at dozens of frames per second, with many units using their abilities on every single one of them. The player is not consulted about every incremental step their units take when told to move to a position or every swing of their gun when trying to track a target. As such, "too much automation" often means "more automation than I am used to". Multiple building selection, a feature decried by Starcraft players, is a perfect example. {STEAM_CLAN_IMAGE}/32557867/64fa8d71b6b4333fdf5e3729c19b2e81181dfcdc.png In Zero-K we try to avoid the subjectivity of automation by being guided by the rest of our design goals. One of our main goals is to focus on the strategy part of RTS. Players should be making plans, observing how they pan out, and adapting them in response to new information. This is not uncommon among games in the genre, but it often feels like it is gated behind intense micromanagement and rote learning. So, at least as a starting point, automation is good when it helps players engage with the strategy of the game, without first having to drill unit control or memorise build orders. The automation in Zero-K seeks to emphasise strategy by reducing the impact of other forms of skill. This does not mean that clicking quickly is unimportant, far from it, but it means that good decision making comes first. Players at the top of the ladder still click quickly to react to information and fine-tune their approach. More generally, automation frees up time to think when players might otherwise drown in micromanagement. But giving players time to strategise means nothing if there is no strategic depth in the first place, and inappropriate automation can even reduce depth. To think about how automation can make a game less strategic we need to know how it interacts with decision making. There are two things to look out for: automation can make decisions harder to implement or it can reduce the number of options available. One thing automation cannot do is make choices on behalf of the player, because, by definition, a choice is only something players can make. This might seem a bit pedantic, but strictly defining choices as player-only will help us avoid category errors. {STEAM_CLAN_IMAGE}/32557867/46688733257cd34b1ccfe158e59916b55e8cd3f0.png If automation cannot make choices, then what is happening when an idle unit shoots at one enemy over another? It sure looks like the unit chose its target by itself, but in fact the player chose implicitly by leaving the unit idle. The player could, in principle, understand the automatic targeting system well enough to know how their units would respond to any combination of enemy units. Leaving these behaviours as-is constitutes a choice, as the player could tweak some state toggles or take manual control if they wanted something else. There is no space left for the unit to decide anything for itself. Of course, it would be ridiculous to expect players to memorise an arbitrary list of targeting behaviours, which is why good automation hinges on trying to make these lists as sensible as possible. Players should know, or at least be able to intuit, how their units will respond to the orders they give. A player with no idea how their commands translate into behaviours is effectively making random choices, which makes implementing a strategy very difficult. In other words, automation works well when automatic unit behaviours match what the player would have done if they were directly controlling the situation. Behaviours also need to be learnable, to get new players to the point that they know what their units will do. {STEAM_CLAN_IMAGE}/32557867/5dbc33242f425bb3bfb8fd7dbeb3d2848fbd7c4b.png The other way automation can reduce strategic depth is by shrinking strategy space. In general, automation skews the set of strategies that players can feasibly implement, which can either increase or decrease the number of viable strategies. Automation gives players more options in any given situation, as it can reduce the cost of a decision from hundreds of clicks to a mere handful. But having extra options does not always mean deeper strategy as, for example, a unit may become completely overpowered when automated, shrinking the set of viable strategies to monospam. Alternatively, a dominant strategy might only be powerful because its counters are too taxing to execute. So automation does not inherently pull the set of feasible strategies in either direction. Players only ever play in the space of feasible strategies. Most RTS games are content to treat this space as the definitive strategy space, and not worry about all the degeneracy that would result if their UIs were a bit more powerful. But the space of feasible strategies has problems, most notably, that it varies from player to player based on ability. This is the source of the feeling that players need to drill their micromanagement before being able to strategise: without a certain level of execution ability, you are playing in a different strategy space. Other genres, such as turn-based strategy, operate under perfect execution. Automation has no impact on the strategy of these games as all combinations of actions are equally feasible, at least for a sufficiently motivated player. Zero-K is weird among RTS in that we like to imagine what the game would look like with perfect execution and take it into account when designing the game. Our principle that "players should fight their opponent, not the UI" could just as easily have been "players should strategise as if they have perfect execution". {STEAM_CLAN_IMAGE}/32557867/8e3ac03c758004a3444dc8bac530face13e972cf.png Automation in Zero-K will never reach the point of perfect execution, but perfect execution is not required to approximate playing in its strategy space. Our approach is to imagine what the strategy space might look like with perfect execution, then use automation to warp the space of feasible strategies to match. For example, players may want some of their units to poke at the enemy from a distance or to charge in to deal more damage. A lopsided application of automation would make either of these options dominate, and in most games fighting at range against an advancing enemy requires a lot of clicking, which makes charging in the default. We want both approaches to be on the table for all players, so we have automation that makes it easy to tell units to keep their distance. More generally, when there are two obvious approaches, we try to make sure both take about as much work to execute. Designing with perfect execution in mind is harder, but it is also rewarding. It restricts the design space and it means we have to keep track of an imagined strategy space as well as the one players actually use. We have other approaches as well, such as making the strategy space of perfect execution easier to approximate by avoiding mechanics that would require a disproportionate amount of clicking, which is a generalisation of designing away stupidity. As for the benefits, our approach makes Zero-K resilient to future automation, as we have already considered what a game with more automation might look like and have tried to avoid making it degenerate. {STEAM_CLAN_IMAGE}/32557867/8823ab748d2d0b53651074a98a8c2f4c7e650227.png Automation has a deeper purpose than those stated above, which is to deal with two sources of frustration: the feeling of being unable to adequately tell your units what to do, and the frustration of noticing idle units do stupid things. Everything reduces to this level eventually, since game design is fundamentally about what happens inside players' heads. The purpose behind all the code, art, and mechanics bottoms out at player experience. We seldom need to scrape the bedrock of game design by talking about feelings, but in the case of automation it helps us avoid a few traps. Specifically, players are not frustrated simply when their units do stupid things; they can only become frustrated when they notice their units do stupid things. Without noticing, there is no problem, and besides, stupid behaviour is subjective. Losing sight of this can lead to excess or useless automation. It is tempting to treat automation as a well-defined optimisation problem. For example, units have to "decide" what to shoot when idle, so surely they should pick the "best" target. But defining the best target is tricky business and ultimately depends on overall strategy. If, say, you are planning a bombing run, then you might want to prioritise killing anti-air units. The only way around the idea of "best target" is to realise that the ideal automation system is the one that elicits the desired thoughts and feelings in the intended audience. In our case the desired feelings are related to feeling in control of your units and being able to tell them to implement your plans, so the best automation is as we described above: powerful and predictable. {STEAM_CLAN_IMAGE}/32557867/a14eb40f929ee75c1de349542266607eaa6b164f.png For another example, consider path finding: when you tell a unit to move from A to B, what is the best path? The solution might seem obvious: the one that takes the least time, and players might even be frustrated when they notice their units take a slower path. But, as above, the answer is that units should take the least surprising path, because knowing whether your unit is going to wander into turret range is more important than saving half a second. In fact, the question is too narrow, because the ideal is to design movement and terrain systems such that the sensible paths are not too much slower than the fastest path. This allows us to avoid two sources of frustration: surprising paths and noticeably bad paths. This is just another form of designing away stupidity, but at a systematic level. Ultimately we want players to feel like they are strategising without being interrupted to deal with frustrating behaviour. We set our sights on strategising in the space of perfect execution, as there is no execution-related frustration to be had there, but this is only an abstraction which guides design. The main risk of this approach is forgetting that Zero-K is played by actual players, and that they enjoy the non-strategy bits as well. Everything above is balanced against other considerations, which can be found in past and future posts. Index of Cold Takes {STEAM_CLAN_IMAGE}/32557867/70989ded762458810a0bcc377335b13c0ca2960e.png

This update polishes a few mechanics and includes quite a few fixes. Singularity Reactors get their wobbly balls back and the guard command should be much more useful. Disarm no longer hard-disables jumpers while winding up and some pathfinding problems with cheap nanoframe spam have been resolved. Some of the changes are due to an engine update, which should stick as the engine is close to the end of a stable release cycle.

Features

• Enabled fancy guard handling. This is an engine change that causes guards to maintain their relative position, rather than just trail behind.
• Disarming a unit during jump windup now cancels the jump, rather than freezing the unit as long as it is disarmed.
• Added quaternion scaling to reinstate the functionality of the previous matrix manipulation system.
• Reinstated Likho and Singularity Reactor ball pulsing.
• Singularity Reactor ball and light disappears when disarmed (thanks SteelBlueZK).
• Thresher has a smaller collision volume and is smaller when not extended.
• Overdrive cables handle cliffs less jankily (thanks Anarchid).
• Improved gesture menu reactivity (thanks Helwor).
• Anti-bait tooltip mentions that the lowest level avoids cheap nanoframes.
• Improve sun on Otago 1.4 and Rainbow Comet v1.25.
• Enable shaders on all-but the most extreme compatibility mode settings.
• Added FeatureDamaged and FeaturePreDamaged for modding (thanks Stiofan-K).

Fixes

• Fixed pathfinding around previously non-blocking nanoframes.
• Facplop no longer causes subsequent nanoframes to be non-blocking.
• Stardust nanoframes no longer decloak enemy units.
• Thresher no longer gets stuck aiming in nearby allied structures.
• Fixed lingering AMD unit icon drawing bug (engine fix).
• Made an attempt at the Linux AMD overdrive issue (thanks Qrow).
• Update Gull description.
• Fixed unit portrait stretching when displaying extreme stats.
• Fixed a typo in com counter widget and Newton firezone.
• Fixed a rare Desolator bug which let it fire while closed.
• Fix brackets breaking chat nick highlight.
• Fixed a headless LuaShader error (thanks danfireman).

Zero-K is extremely customisable, which is great but risks making the game unapproachable. The problem with customisation is that it asks players to optimise their own experience without necessarily giving them the background required to make an informed choice. In general, an option is useful if players understand it well enough to sort themselves into the various versions of the game implied by the option. Good examples are colour blind modes and language settings, but Zero-K has far more options than these. Another issue is that of overwhelming players with too many options, even if they are all good. Zero-K was designed on the fly, with the UI coalescing out of a hodgepodge of experimentation, so it has been a challenge to make our options reasonable. Most people stick with the defaults. Of those that touch the settings, many will stay in the shallow end with the language selector and volume controls. But some players will want to dive deep, while others will want to keep the old defaults from when they started playing over a decade ago. To balance these desires we considered players at different levels of customisation, and put gates between them to keep new players from being overwhelmed. Our goal is to make the game work well at all levels, and even to allow players at one end of the spectrum to play with those at the other. {STEAM_CLAN_IMAGE}/32557867/47fb9abfbb0fc0b00b6a99584bdaf36204307c9b.png At Level 0 the player can barely read and rarely touches their keyboard. Most of their inputs are either context-sensitive right-click commands or structures selected through the build menu. Small buttons may as well be invisible, which for us includes state toggles and everything in the top left corner of the UI. Zero-K is not the simplest game, so it is not quite designed to work all the way down to Level 0, but we may hit something like Level 0.1, which involves reading the occasional tooltip and learning a state toggle or two. At Level 1 the player looks around the UI and reads tooltips. This unlocks features such as retreat zones and the anti-bait toggle, plus information about features such as terraforming. People sometimes ask why features like the anti-bait toggle are mostly disabled by default, and the answer is that it only becomes visible at Level 1. Everyone starts at Level 0 and might spend all their time below Level 1, so the game needs to make sense without state toggles. To a player unaware of the anti-bait toggle, units failing to shoot at the enemy looks like a frustrating bug, not something that motivates them to take a close look at all the defaults in the game. Level 1 also includes colour blind mode, language settings, and basic volume controls, as they are directly on the main UI. {STEAM_CLAN_IMAGE}/32557867/7789b3d298370017d31abcfd4c50ff77f1a4b5f8.png At Level 2 the player has opened the ingame menu. The menu has Simple Settings enabled by default, which removes the vast majority of options. At this level players only see the most important options, as measured by what new players think to look for, such as locking the cursor to the window or picking whether the minimap is on the left or right side of the UI. Level 2 also includes the full hotkey and default unit behaviour menus, so if we were to apply these levels to other games, it would be hard to find a game that allows customisation beyond Level 2. At Level 3 the player unticks Simple Settings. This is the first level that gives players the power to make their UI objectively terrible. This is achieved by enabling Tweak Mode, via a hotkey or button found in the menu, then moving and stretching their UI. There are also many alternate styles for in-world UI, such as unit selections, which come from a time when many widgets were being written and included. A lot of mostly superfluous bells and whistles, such as the attrition tracker and wind speed display, can be enabled here as well. {STEAM_CLAN_IMAGE}/32557867/312b536cb56e77dccdc5921a9e2da24ff1deeaab.png At Level 4 the player has fully "voided their warranty", meaning that they can now break things thoroughly enough to be told to reset their settings when they ask for help. This level is reached either by opening the widget list, or toggling Show Advanced Settings in the menu. Most of the advanced settings are boring technical details or debug tools, but it also reveals the hotkey for opening the widget list. This list allows players to toggle widgets on and off, some of which are vital for the UI to function. There are also widgets that exist in Level 4 because they are insufficiently polished or are just too poorly explained to exist at a lower level. Niche widgets with major bugs can end up being relegated to Level 4 until someone fixes them. At Level 5 the player has found and installed their own widgets. There is no central repository of third party widgets, so it is hard to know what exists at this level. A lot of widgets started out at Level 5 before being included in the game and shifted down to a lower level. Widgets often remain at this level due to obscurity or because there is insufficient interest in polishing them up for inclusion. The goal is usually to drop a widget to Level 3 or below, since the widget list is a bit of a doldrums. At Level 6 the player is creating their own widgets. We encourage people with anything particularly novel or useful to share it with the community, putting it at Level 5 for others, but have never had to enforce this. Even when widgets are shared, using custom widgets is a far cry from the Level 0 player who mostly just clicks around the default UI, so the challenge for us was to make the game work across all these levels. {STEAM_CLAN_IMAGE}/32557867/8cbcc02fbb142fe1e62d65ed6904115e4d5b710e.png In the beginning there was engine behaviour, which offered limited customisation, most of which involved hotkeys or UI colour files. Then lua was added, which triggered an explosion of widgets. Many players would browse the Spring forums and install their own widgets, placing themselves at Level 5. Some got into the open source spirit by rapidly iterating on each others widgets. Complete Annihilation was quick to include the best ones, jamming them in the widget list at Level 4. Levels 2 and 3 did not exist because CarRepairer had not yet created our fancy ingame menu. The result was a mess of disparate bits of UI and widespread use of the widget menu. To clean up the UI, Licho declared that core developers have to use the defaults, forcing us to operate at a lower level. Any developer that wanted to deviate from the default had to implement an easily accessed option, i.e. something a player could do without voiding their warranty. Personally, I want all my units set to Hold Position, and had a widget to achieve this, but the need to push it down the levels led to the fully general unit default state editor. The ingame menu was created and options were filtered into simple and advanced settings over the years, with the final push involving hiding most of the commands and state toggles. The settings in the main menu, outside the game itself, were not given a spot in the Levels of Customisation because the main menu is relatively new. I would put them at Level 1 or 2 because they are easily found by someone clicking around the main menu UI. The existence of these settings causes some confusion, but there is a lot to be said for being able to edit hotkeys and settings on the fly ingame, with instant feedback. The main menu mostly contains lobby and graphics settings that are infeasible to change mid-game. The main drawback is that the ingame graphics menu looks a bit empty. {STEAM_CLAN_IMAGE}/32557867/3f8739a18177983d330f64ed11af377a6130aa51.png The levels of customisation are also a way to think about the intended audience of features. In general our aim is to push as much UI power to as low level as possible, which is what lets players across all levels coexist in the same battle. The ability to write your own widgets would absolutely break most games and force any halfway serious player into Level 5 or 6. We only get away with it by committing to making the base UI as powerful as possible, which means either incorporating sufficiently powerful UI, writing our own more user-friendly version, or changing the game to make the widget unnecessary. There are rare cases in which widgets were blocked directly, rather than incorporated or rendered irrelevant, but such cases deserve their own posts. Index of Cold Takes

Space clicking wrecks and build options is back by popular demand ( https://github.com/ZeroK-RTS/Zero-K/issues/5742, https://github.com/ZeroK-RTS/Zero-K/issues/5747 and https://github.com/ZeroK-RTS/Zero-K/issues/5750 ). Thanks to everyone who opened tickets to remind us that this probably should have been a hotfix earlier.

Fixes

• Fixed space+click context menu crash when activated on a non-unit.
• Fixed map download for Planet Karuwal.
• Commander egg can be built underwater.
• Fixed Pheonix.
• Fixed some weird edge cases in grid cable flows.
• Fixed a rare landing pad bug that the previous patch allowed to trigger for any bomber, rather than just the first bomber built in a game.

The basic reclaim mechanic is as follows: units leave wrecks when they die, and these wrecks can be harvested by constructors for extra metal. This sounds like a simple enough mechanic, but the more I think about it, the more I feel like Zero-K would not work without it. Reclaim is common to most games inspired by Total Annihilation, although its importance varies depending on how lucrative it is. As always, I am only intimately familiar with the design of one of these games, so while the ideas that follow are likely to be widely applicable, I focus on how and why reclaim works the way it does in Zero-K. {STEAM_CLAN_IMAGE}/32557867/c244cdbd069c95127c918bd7093759d94aaded9c.png The main role of reclaim is to dynamically create areas of interest around the map. Some units die in a skirmish, leaving a few hundred metal on the ground, which makes holding the area slightly more enticing. This leads to more battles that drop even more wreckage, which can even snowball into thousands of metal worth of incentive to keep fighting in that area. Eventually the feedback loop is broken by one side gaining enough control to deplete the whole field. The pacing of this dynamic is great: the stakes keep rising while the outcome is uncertain, then quickly dissipate once one side wins, releasing the tension. A single wreck field, that everyone pours their armies into, would get a bit dull after a while. Luckily, there are often multiple fields scattered around the map. Reclaim essentially generates multiple shifting king-of-the-hill style objectives, but in a natural way that targets the most contentious parts of the map. Players shift their focus around to secure wrecks, which encourages the use of mobile armies that can make these kinds of strategic moves. The side that focuses more units on an area has a better chance at winning, but leaves themselves open to attacks elsewhere, which can trigger the creation of a new field of wrecks to fight over. Sometimes one side wins on all fronts simultaneously, but when this happens the reclaim lets them close out the game quickly, which is preferable to keeping the game going long after it is over. {STEAM_CLAN_IMAGE}/32557867/5003995b5f52c33c312f79af8fbd2c3ca6ab5b0d.png Contestable wreck fields only form if players have a reason to be out on the map. Metal spots fulfil this role generally, but many maps also kickstart the process by starting with reclaimable map features. The classics are rocks and trees, but sometimes a map will contain old machinery or magical purple crystals. Trees tend to be energy-only, which can lead to constructors being more efficient than Solar Collectors early on, while rocks contain metal. A lot can be done with small amounts of reclaim, as every bit counts early on. In addition to changing the value of an area, wrecks change the terrain itself. Most wrecks block movement and projectiles, to the point that an open plain can be transformed into a maze of passages and cover. Large units can crush smaller wrecks, at the cost of reducing the amount of metal that can be reclaimed, and not all wreckage blocks. Hovercraft and ship wrecks do not block movement because wrecks on the sea floor used to block surface movement. A smattering of light units also drops wrecks that do not block movement, presumably because the wrecks are so small that not being able to walk over them would look silly. {STEAM_CLAN_IMAGE}/32557867/081aacf5ec46d666eb4d40f5973340003bfeb73e.png It can be tempting to think of reclaim as a comeback mechanism, and it is in some situations, but it is more useful to think of it as a mechanic that increases variance. It can certainly provide the metal needed to rebuild after a raid on your base. However, if the enemy knew that you would come out ahead, then they would not waste their units on diving your base in the first place. So reclaim softens the blow of effective assaults and deters marginal ones, but a similar effect could be achieved by buffing defences. It is hard to call this a particularly strong comeback mechanism, in theory at least, because players should avoid making raids that just feed metal. In practice mistakes can be made, but the advantaged team is not obliged to make them at any greater rate than an underdog. Things get more interesting when we consider wrecks that have a reasonable chance of being claimed by either side. The long-term success of an assault often depends on who gets to reclaim the resulting wrecks, which introduces swinginess by widening the range of potential outcomes. So even if a player attacks with the expectation of a positive outcome, there is often a good chance that the defender will rally and take the reclaim for themselves, or at least take a sizeable chunk. This is the stronger form of comeback mechanism offered by reclaim, as uncertainty benefits the underdog. It has to, because if the game were to just plod along predictably, we would expect the disadvantaged team to lose. Base raids have less of this type of variance than fights out on the map because the defender is destined to get the reclaim. {STEAM_CLAN_IMAGE}/32557867/0801f483892a2b1d3ff98cbc9102dbb935cf8873.png The importance of reclaim depends on how much metal can be gathered from wrecks. Too much metal and the first bit of reclaim will snowball into a win, too little and the system becomes useless. In Zero-K units leave wrecks with 40% of their value when they die, unless they died to a massive burst of damage, in which case they leave 20% of their value. This value was picked very early on in Complete Annihilation, so perhaps the precise value is unimportant, although I suspect there is some leeway offered by tweaking the design of the rest of the game around a simple round number. The mechanics of reclaim are also important, although I might not think so if we did not start with quite a poor implementation. The default system offered by the engine has reclaimers fill a progress bar over their target wreck, which yields a lump of metal when filled. This was an ugly system for many reasons, as lump sums require extra storage to process, and being hit by chunks of metal makes your economy needlessly difficult to manage. It gets worse when you consider the arguments and jank caused by multiple players trying to reclaim the same large wreck, as only the constructor that contributed the final tick of progress was rewarded. {STEAM_CLAN_IMAGE}/32557867/d65665d3e280d4126ef52c5bda41d8ea61563c15.png Reclaim in Zero-K works by constructors gradually sucking the metal from wrecks. All constructors can reclaim, and they all do so at a rate equal to their build power, as any other choice would be arbitrary. This refusal to apply an arbitrary multiplier makes constructors quite bad at reclaiming, when you consider how long it takes to reclaim thousands of metal with five build power. The upshot is that reclaim can be taken during a battle, but that doing so at any significant speed requires a lot of investment, which increases your risk of losing the battle. A popular technique is to bury construction towers, or to put them behind walls, which works nicely as a way to encourage players to leave their mark on the map with terraform. Reclaim has another whole set of mechanics for reclaiming live units, and in this case the default offered by the engine is even worse. The old live reclaim system essentially armed every constructor with a reverse repair weapon, one where "killing" the unit resulted in a lump sum payment. The lump sum was bad enough, but the worse part was that it could target enemies. Units would not automatically reclaim enemies, so this ability was hidden behind a fight with the UI. We could have automated offensive reclaim, but instead decided that arming every constructor was too much of a nerf to raiders, so made (fully built) enemies unreclaimable. The old live reclaim system had another issue: it could be used to avoid explosions. Units killed by reclaim skipped their death explosion, which meant that a Singularity Reactor could be nestled in your base, provided there were enough constructors around to safely dismantle it when it came under fire. This was a neat trick, but would remove the point of explosions if automated, so the CA developer det added the reverse-build live unit reclaim system. This method of reclaim turns units back into nanoframes, at which point the unit can be un-built for an 80% metal return. The final step was to make nanoframes explode when over 80% completion, which was easy enough to do with a gadget. {STEAM_CLAN_IMAGE}/32557867/7d78fdda1c192bf983934d32eb066aa0b4b75f80.png I shouldn't complain too much about the defaults offered by the engine, as they were mostly inherited from Total Annihilation, and the engine was easy enough to extend. Some improvements even predate Complete Annihilation, such as area commands. Wrecks are much harder to reclaim without area commands, as the options are to either issue a patrol command, or to click on each wreck individually. Patrol was risky though, as constructors might decide to repair instead, or wander into turret range. Area reclaim gives you much more control over how far your constructors venture, and there are even keyboard modifiers to make them ignore trees and other metal-free reclaimables. Precise control of your reclaiming constructors is vital because players are encouraged to put their constructors on the front line, reclaiming at the edges of the battle. This is great in that it gives the enemy targets of opportunity to snipe, but losing constructors this way would be frustrating if they were not where you meant them to be. Constructors also have other frontline tasks, including repairing, construction, and some can even resurrect units from wrecks. A large part of the game is judging how many constructors to build, and where to deploy them, but that will have to be a topic for another time. Index of Cold Takes

This is a small fix update which also has some commander tweaks. The big wire change is that the settings are now local, which means people with the graphics bugs on Linux can disable them until we figure out the problem.

• Fixed cable settings being global, i.e., the last player who toggled cables controlled cables for everyone. This is what caused the setting to look like it needed toggling to work properly.
• Put cable settings in "simple settings" while we work out the linux graphics bugs.
• Fixed various problems with uneven teams and resigned players not allowing a team to hatch their full complement of commanders.
• Fixed Egg morph buttons being greyed out in some incorrect situations.
• Hatched commanders no longer have free radar and income. This is to retain the game impact of an early commander kill.
• Commander range module gives +25 range instead of +7.5%. This nerfs longer ranged weapons and buffs some shorter range ones.
• Commander Dgun base range 200 -> 180 to partially counteract the above.
• Eggs count as bombs for the transport drop prediction UI.
• Eggs now have Move and Attack Move, which hatched commanders inherit.
• Eggs no longer cancel their commands when completed.
• Fixed free morphs being slowed down by the state of the rest of the economy.
• Fixed EMP reference in various descriptions of the egg explosion (thanks Stiofan-K).
• Fixed SSAO widget (still disabled by default).
• Reduced the radius of a few projectile lights.

{STEAM_CLAN_IMAGE}/32557867/25f8735774d4f5fb996e5a914089f65776fee19d.png This update adds wires between structures to visually connect energy grids. This makes grids easier to use and more satisfying to build. We have also added commander eggs, which let players rebuild lost commanders. The egg can also be transported and thrown, to take advantage of its disabling explosion. On the more regular side of things we have a revert of the Hermit regeneration experiment, and numerous features and fixes. These include a new attrition graph for the endgame stats, and a lighting system update to fix the Pylon light bug.

Balance

Fixed commander morph costs being unintentionally far too high. Added Commander Egg.

• Buildable from the bottom right of the Special tab.
• Costs 600 metal.
• Morphs to commander for free if the team has lost commanders.
• Hatched commanders are given to players without a commander.
• Can be thrown and detonated for 20k disarm and slow damage.

Hermit loses its regeneration.

• Idle auto heal time 10 -> 60 seconds.
• Idle auto heal rate 10 -> 5 hp/s

Singularity Reactors can be built on the edge of the map again.

• Units that die outside the map explode far away, rather than on the map edge.

Discouraged movement blocking via nanoframe spam.

• Nanoframes placed in quick succession can be passed through until 15 metal is spent.
• Units can become stuck, but a move command seems to be sufficient to free them.

Features

{STEAM_CLAN_IMAGE}/32557867/6ebcab7d0f5885b9eaf83a97ecb6fa8b20e5c567.gif Added grid wires between Metal Extractors and energy structures (thanks Licho and Anarchid).

• Flow shows energy use and colour shows efficiency.
• Grid thorns flash when the grid is at capacity.
• The underlying mechanics are unchanged, but the enemy will have an easier time scouting.

Other features:

• Added two attrition endgame graphs. These damaged value or killed value dealt:received ratios.
• Ronin treats Scalpel and Moderator as skirmish targets, so tries to stay at max range (thanks D0ubleD0uble).
• Solar and Wind generators are now harder to select, or easier to not select accidentally.

Fixes

• Panning with middle mouse button no longer deselects terraform commands, which is consistent with other commands (thanks Birdulon).
• Fixed Pylon lights sometimes jittering around or drawing somewhere else.
• Overhauled the entire weapon lighting system behind the scenes. Lights should render faster and generally look better.
• Fixed the first Sparrow of the match being able to hover mid air.
• Fixed incorrect burst damage for Starlight in the unit stats window.
• Added overslow information to the unit stats window.
• Fixed inconsistency between weapons and death explosions in the unit stats window.
• Fixed other scores obscuring the highlighted player in the endgame graphs.
• Fixed Locust jets angling downwards at full speed (thanks Stiofan-K).
• Windmills no longer crash all gadgets when the energy multiplier option is set to zero.
• Fixed GL parameter pollution in an unused map extension widget (thanks Helwor).
• Added framework required for rml UI support (thanks loveridge).

The term "deathball" comes up whenever players complain that roaming around the map with a single army is too powerful. The complaint conflates whether deathballs are unfun to use, or just unfun to fight, but it is worth keeping both possibilities in mind. Most RTS designs address deathballing to some extent, but vary on how much they mitigate its issues or just outright discourage it. Deathballing is the natural state of RTS, in the same way that without a balanced strategic triangle, players would end up playing either all-in rushes or greedy economic booms. Another way to think about it is if you randomly throw together a generic RTS, it is going to be a game of deathballs. In fact, the deathball would probably consist of one unit type. This is a result of Lanchester's Square Law, which states that an army of ten units is more than twice as powerful as an army of five. Without any reason to give up this power, players will build deathballs. {STEAM_CLAN_IMAGE}/32557867/29c42286dc8216371e22c7bc95cd731127d56bd0.png There are many ways to avoid or reduce deathballing. At the strategic level, they can be discouraged by scattering multiple objectives around the map. These could be the metal spots in Zero-K, the control points in Company of Heroes, or even the creep camps in Warcraft III. These objectives offer greater rewards to players that split their army to control multiple at once. This approach tends to be most effective early in the game, when the map is empty, as maintaining control is often easier than taking control. A deathball in the centre of the map can control a large amount of territory by threatening to counter-attack any attempts at a flank. Deathballs can also be discouraged on a tactical level in a few ways, although they all boil down to taking the "square" out of Lanchester's Square Law. Melee battles follow Lanchester's Linear Law, where army power scales directly with army size, as long as the extra units of the larger army cannot find space to engage. This effect makes games with large units, relative to their range, sit somewhere between square and linear. Zero-K units can pack quite tightly if they have to, and few are melee, but the way allies block our simulated projectiles has a similar effect. Another way to limit deathballing, or at least provide counterplay, is to use area of effect damage, which causes your damage output to scale with the size of the enemy army as well as your own. Area of effect damage is perhaps the most popular anti-deathball measure in RTS, but its power often hinges on fighting the UI, so it is weaker in Zero-K. We have a lot of area of effect weapons, and it keeps swarms of smaller units in check, but mid-sized units are generally able to spread out and still form effective armies. Zero-K should involve flanks and manoeuvres, rather than just mashing armies together, and we need to support drawn out multi-front battles for large team games. This requires relatively weak deathballs, so we ended up with a loose rule against scaling buff auras. {STEAM_CLAN_IMAGE}/32557867/b941e42d258cd428b32f4d94010cf3faeb2105ad.png An aura is an ability that applies a constant effect in the area around a unit. A scaling buff aura is one that boosts friendly units in some way, and that is more effective the more friendlies are nearby. For example, it has been suggested that Funnelweb could passively heal nearby allies, which would be a scaling aura since the total rate of healing would increase with unit count. There are auras for any kind of buff, and most of them are in Warcraft III. A lot of the auras found in other games would also be too numbery for Zero-K, but effects such as healing or increased speed would otherwise be fine. Negative slow damage is possible. Zero-K has a few mechanics that behave like auras, but which do not scale. Cloak fields fit into this category due to the specifics of how cloaking is used. Recall that there are two types of cloaking: strategic and tactical. Strategic cloaking does not scale with army size because revealing a single suspicious unit gets you most of the way towards discovering the whole cloaked army. A large cloaked army is scarier than a smaller one, but the army does not gain extra cloak power due to its size, in fact, a larger army is easier to find. Tactical cloaking is similar: while it makes it harder for the enemy to pick their targets, as long as there is a target to shoot, the army as a whole takes damage. Bubble shields are similarly non-scaling, since they block the same amount of damage regardless of how many units are covered. There is an exception here in that shields that block area of effect damage can prevent that damage being taken by many units. This protection scales with unit count, which is why shields are particularly good against high AoE bombers and artillery. Shields also indirectly buff the damage output of Felons, which is why shieldballs survive as one of the most deathbally strategies. {STEAM_CLAN_IMAGE}/32557867/045a03bbf3055ae526c058e10c5744da3a6330ac.png The most aura-like mechanic in Zero-K, in terms of giving a scaling buff to allies in an area, may well be the lob of the Lobster. This is an active ability, but the threat of a lob makes the nearby units a lot safer. Lobster scales with unit count, as each unit in range feels the benefit of the lob, which is why Lobster is often included in shieldballs and other types of tightly clumped armies. So it turns out that, even with a rule against auras, an aura-like effect managed to sneak in. At least Lobster has a small area of effect, and as an active ability, has a cooldown. Many things look like auras if you squint hard enough. Anti-air units have an aura of aircraft repulsion, while riots have a similar effect on raiders, and units that are weak to aircraft or raiders like having these auras around. The purpose of avoiding auras is not to stop good army composition, rather, the purpose is to let our wealth of subtler interactions shine by avoiding simple multiplicative bonuses. Designing a strategy game often involves culling the simplest and most effective approaches in favour of strategic diversity. Index of Cold Takes

Planetwars is live right now. The second open playtest is in full swing, with 240 invasions launched in the past 26 hours. We designed the round to last the weekend, although it is hard to dial in, although we are considering pausing it during the week. This forum post summarises the changes since the last test. This patch makes command structures easier to kill, which is the main secondary ingame objective of Planetwars. This objective only occured in 6% of the games so far, so representatives from each of the factions agreed that it was worth trying a change to make things more interesting. The patch also has a few smaller features and fixes, we have notable changes in the works, but they will get their own release.

Command Structures

Main Command is weaker and harder to repair.

• Health 10k -> 8k
• Cost 150 -> 350
• Repair health/BP while under fire 25.25 -> 8.65
• Now requires 40 nearby BP to out-repair an Odin.

Extra Command is just harder to repair.

• Health remains at 6k
• Cost 100 -> 250
• Repair health/BP while under fire 22.73 -> 9.09
• Now requires 50 nearby BP to out-repair an Odin.

Command structures now spawn further from each other and closer to the enemy, on average.

• They now avoid spawning in the back 40% (the safest part) of their structure spawn box.
• They now spawn at least 1200 elmos away from each other (ally and enemy).

Features and Fixes

• Scouted command structures radar dots no longer wobble around like units. They are treated like normal structures.
• Added all Planetwars structures to the unit marker system, ingame under Settings/Interface/Unit Marker.
• Added categories and more presets for the unit marker settings menu.
• Scylla now stows its tacnuke correctly (thanks Stiofan).
• Improved Wind Generator performance.
• Fixed pew-pew laser trail offset for the new engine.

{STEAM_CLAN_IMAGE}/32557867/34795ae63d810f50904b3b313d881ba3912408b9.gif

This is a small lobby update to prepare for the next Planetwars test round. The round is starting in a little over 45 hours from this post (2026/05/01 at 12:00 PM UTC). More information on the changes is to come shortly. Factions can now be joined via the in-lobby faction selection UI.

Cold Takes usually cover a concept used in the design of Zero-K, but this one is about a term invented by players to describe an issue with the game. This issue involved the "retreat range bonus", but the term was initially perplexing because it describes something that is both emergent and ubiquitous. Nobody could tell me how other games dealt with it, and it seemed very hard to remove without breaking some of the basic rules of Zero-K. The retreat range bonus is the apparent range gained by units as they retreat from a battle. Consider two identical units called Chaser and Runner, locked in a battle where Chaser follows Runner while Runner tries to retreat. The retreat range bonus is the observation that, at a certain distance, Runner will be able to fire, while Chaser cannot. In other words, it appears as if Runner gained bonus range on Chaser merely by retreating. Taken at face value, this looks like a weird arbitrary bonus, and the type of thing Zero-K would certainly not want. {STEAM_CLAN_IMAGE}/32557867/28e88c4601b385f381188ca43386304f1a59b78c.png The paradox of the retreat range bonus is that it was not added; it is just the inevitable result of the common type of game physics. If a game physically simulates its projectiles, then it probably has some form of retreat range bonus. Many, possibly all, first-person shooters have it, and there might even be a term for it in that space. Games like Supreme Commander and Planetary Annihilation should have it too, but to this day I have not found any discussion of retreat range in those games. I am often met with confusion when I ask people about it, even after explaining the generality of the mechanism. The retreat range bonus is caused by units leading their shots. In other words, to hit a moving target, you need to shoot at where it is going to be, rather than where it is. In particular, for a unit to hit a fleeing target near the edge of its range, it would have to fire at a point beyond its range. Doing so would violate the No Void Ray rule, i.e. that the capabilities of weapons are independent of their target, so the unit cannot shoot at such a target. In the case of Chaser and Runner, both units are just within each other's range, but Chaser is moving towards Runner while Runner is moving away, so only Runner gets to shoot. The effect is compounded by the fact that units predict when an enemy will enter range, and fire towards the edge of their range in anticipation. The retreat range bonus is fundamentally caused by a lack of Galilean relativity. Galilean relativity only really shows up in actual sports, and is responsible for mechanics such as taking a run-up to throw a ball faster. Simulated games tend to avoid it, and are right to do so. Humans are pretty good at accounting for relativity when doing human things, but not when shooting pretend rocket launchers. Imagine firing while strafing, only for the shot to go wide due to your own velocity. I would definitely play a Zero-K mod with Galilean relativity, just to experience the nonsense, but I expect it would make units quite stupid, as many of them would want to suddenly lurch towards their target for extra range as they fire. {STEAM_CLAN_IMAGE}/32557867/1d2740f3d2025797f10654ca6a655eb29d405925.png So far so good. The retreat range bonus is baked into the game, and removing it would make less sense than leaving it in. The problems arise when we consider the tactical implications. The Chaser-Runner battle can be in one of three states, depending on the distance between the participants:

A) Neither unit can shoot at the other. B) Only Runner can shoot. C) Both units can shoot.

Runner would really like to deal damage for free by keeping the battle in the sweet spot at B. Chaser absolutely does not want to take damage for free, and would either like to kill Runner or chase it away. Both sides can control the battle by slowing down, for Chaser, this widens the gap from A to B to C, until Runner escapes completely, while for Runner slowing down closes the gap. This shared control of the situation creates a tight feedback loop of manoeuvring and fakeouts, with the potential for Runner to push its luck for a shot at killing Chaser at no cost. This results in intense bouts of clicking, especially in the hands of hardcore players with low latency. {STEAM_CLAN_IMAGE}/32557867/80a9820cbe059205a3e7d085081b69d8cc80ca78.png The retreat range bonus came up as part of a broader set of feedback about the swinginess of the early game. In short, some 1v1 players felt like too much hinged on the first few raider engagements, and that too few games made it out of this stage. This was by no means a universal take, but it was prevalent enough to be worth some experimentation, as we could end up somewhere that most people would prefer. Chasing feedback from players that are particularly sensitive to an issue can be useful, as this can reveal things that generally improve the game, yet were below the complaint threshold for most people. The feedback and testing culminated in the Superfluid Update. The Superfluid Update removed the retreat range bonus for raiders. These units have low range and fast projectiles, which made for small sweet spots, but it was large enough to dominate the opening. Some players were against removing the retreat range bonus as they liked the tactical options and its potential for large swings. Others just liked being able to furiously micromanage a raider to kill many times its cost, but this was offset by alleviating the frustration of players that were on the recieving end. The deciding factor in the removal of the retreat range bonus was the fight with the UI inherent in having units die by being baited into the sweet spot. The other option was to improve our unit AI to account for the sweet spot, but I felt that such an AI would be too unreliable and intrusive. These fights were not just about micromanagement; there were decisions to be made. For example, a fight between units of different speeds might have one try to push through the sweet spot, at the cost of taking some damage, and whether to do so depends on your strategy and the whole state of the game. The player needs to be able to implement these choices, but the remaining options are state toggles and special commands, both of which are much worse than letting players rely on simple move commands. Essentially, removing the retreat range bonus was a case of tweaking mechanics to preserve the power of the smoothest and most fun part of the UI. Feeling good to control is much more important than any specific interaction. {STEAM_CLAN_IMAGE}/32557867/c67bc2a10e3ce2e0e8eff94ae64b4ae874f09627.png On the technical end we removed the retreat range bonus by forcing units to not lead their shots, then hacking physics to cause their shots to lead themselves. Every time a Bandit shoots, its projectile is reoriented slightly to point towards the predicted location of its target. This lets raiders shoot very slightly beyond their range, breaking the No Void Ray rule, but their high projectile speed makes the effect barely noticeable. Unless you pause the game, zoom in, take a screenshot, then draw some arrows. If you cannot unsee the small deviation ingame, then I am sorry, but that is the risk we take when pulling back the curtain. As for the Superfluid Update itself, the rest of it involved making raiders and constructors take a bit longer to kill, and generally making units feel more responsive. These changes were walked back over time, to an average of the old and new states, but this was by design. I prefer to overshoot reworks to probe the outer edges of the reasonable area in the design space, to make a better map with which to navigate to the final state. The raider retreat range bonus has not returned though, and predictions of the raider game becoming trivial or pointless did not eventuate. Raider battles still involve a lot of position adjustment as players try to keep all their raiders firing on a target, while trying to block enemy raiders behind each other. Still, it would be good to hear some of the feedback from players who were there six years ago, to see how the changes have aged. Index of Cold Takes

This release includes an amazing new soundtrack by Vladislav Lapochkin (D.700). It is the new default, and all previous soundtracks can still be selected ingame under Settings/Audio. Big thanks to everyone who contributes music, eventually we will have enough to give each factory its own theme. The contributions don't stop with an hour of new music. This release also has some Gunship tweaks by Ixzine and a Dante rework based on a mod by StiofanKingofAwoo. The Dante changes are designed to turn it into a brawler, rather than a standoff missile platform, and will require feedback. There are even a few Planetwars balance changes that have come out of our ongoing live testing. This release also includes an unknown number of unintentional balance changes. It all started when some units were found in violation of a few subtleties of weapon design, which let them fire early at targets entering their range. This was hard to overlook because triggering this behaviour involved a bit of fighting the UI. The fix resulted in general aim improvements, might affect some unit interactions. Please report any issues.

Balance

Dante is better at brawling and leans less on the range of its rockets.

• Health 11k -> 15k
• Speed 52.5 -> 57
• Flamer burn time 15s -> 37.5s
• Rocket effective range A Lot -> about 400
• Rocket AoE 228 -> 168
• Rocket direct damage 120 -> 150
• Rocket burn time 37.5s -> 5s
• Rocket sets the ground on fire in much the same way as Firewalker.

Constable is slightly more efficient.

• Cost 140 -> 135

Fencer no longer responds to Set Target or Force Fire commands near the edge of its range. To compensate it now targets the edge of units, rather than their centre. Stinger also now targets the edge of units, giving it slightly more effective range. Locust can see a bit further and is easier to use.

• Sight range 500 -> 560
• Fire arc 150 -> 180

Harpy survives more Tarantula shots.

• Health 1200 -> 1250

Nimbus is better at using its range.

• Sight range 660 -> 740

Planetwars

Planetwars is undergoing live testing, which has revealed a few issues to do with units and systems that are relatively new to Zero-K. The balance changes are aimed at bringing Odin in line with other means of rushing the secondary objectives. This update also has some interface tweaks, and the match aborting and excess player count issues have been resolved server-side. We expect to make a server update and unpause the current round within a few hours of this release. The command structure is much cheaper so that it can be repaired at a faster rate. This lets it survive an Odin shot provided there is 10 BP nearby.

• Cost 1000 -> 150
• Drone count 6 -> 4

Each side now has two command structures.

• Both have to be destroyed to receive the influence bonus.
• The extra structure has around 60% the health, cost, and size of the main structure
• The extra structure only spawns two drones.

Increased to health of some structures so that they survive an Odin rush.

• Wormhole Generator health 12k -> 15k
• Improved Wormhole health 15k -> 18k

Generally reduced planetwars structure cost by around 25%, to make them a bit easier to repair.

Targeting Behaviour

Units are now better at leading their shots. This is a new engine feature that uses precise calculations rather than a rough approximation. Units would previously predict how long it would take to hit their target at its current distance, then project the position of the unit, without taking into account that the projected location could be closer or further away. Most units with homing weapons no longer lead their shots at all. Leading causes units to shoot before their target enters range, which for homing units can cause them to hit units that never entered range. Homing weapons were always designed to not lead, but many weapons slipped through the cracks.

• Some of the most balance-sensitive units already had no target leading: Duck, Scalpel, and Ogre.
• The change may noticeable affect a few units: Puppy, Fencer, Harpy, and Magpie. Previously these units would gain some range against approaching targets, but lose it against fleeing ones.
• Some weapons had the capability to lead their target, but it was rarely relevant: Racketeer, Reef missile, Zeno, and Paladin missiles.
• Many mobile anti-air units are affected: Vandal, Angler, Tarantula, Crasher, Flail, Zephyr, Trident, and Swift. These units should be barely affected due to rarely triggering the condition required to gain extra range (see target acquisition below).
• Multiple turrets are affected: Claw, Picket, Urchin, Chainsaw, Artemis. These were even less likely to trigger the condition as they would require a manual attack command from players.
• Units with very limited homing, e.g. Revenant, still lead their target.

Units are now better at acquiring targets beyond their weapon range. This is useful for units that lead shots, because they can shoot as soon as the projected position of the enemy is in range. We thought this was capability working correctly, but certain commands were found to boost target acquisition range significantly, while particularly long ranged units (mostly anti-air) required manual Force Fire commands to acquire targets beyond their range. Locking smart unit behaviour behind specific commands is bad, so the general target acquisition range has been boosted.

Features and Fixes

• Embiggened Duck, Ronin, Rogue, Mistral, and Dante missiles.
• Added a bindable clear selection hotkey to the ingame menu under Hotkeys/Selection.
• Readded the battle autostart chat warning.
• Fixed damaging a commander sometimes being worth too much experience.

A conflict has been brewing over the course of this series. Half the cold takes, those on general design principles, often imply that Zero-K avoids special abilities, while the other half shatter this impression by being about specific special abilities. In this post we will try to resolve this apparent disagreement by exploring how special abilities work and what makes an ability suitable for Zero-K. The set of design principles arrayed against special abilities is truly daunting. To start with, abilities that require frenetic or precise clicks are rejected by the idea that players should not have to fight the UI. Many other potential abilities are ruled out for being too numbery, making units too stupid, or for imposing arbitrary target restrictions. Atomic unit design pushes us towards having few abilities, special or otherwise. But despite all these restrictions, Zero-K has many more special abilities than other games with Total Annihilation ancestry. {STEAM_CLAN_IMAGE}/32557867/e991e03446d2915fc97b229ba3493478ff8b8f94.png Some design principles encourage special abilities. Quant's Rule reflects a desire for units to be unique and interesting, and special abilities are certainly a way to achieve that. More importantly, special abilities are fun, and not just to use. Zero-K steadily accumulates special abilities as a result of its open source laissez-faire development style, with many contributors working on whatever they find most interesting. This process predates Complete Annihilation, as early engine developers added features such as bubble shields and the deformable terrain that makes terraform possible. The pace of special ability development ramped up with the advent of Complete Annihilation and Lua scripting. Many of our design principles were also being hammered out around this time, but the purpose of them was more to channel this outpouring of creativity, rather than attempt to stem the tide. This period gave us area cloakers, morphing, jumpjets, terraform, and a host of manually fired weapon-like abilities. It is hard to overstate how satisfying it is to mess around with new abilities, I have even written abilities that my designer side knew had little chance of making it into the game. In fact, the design principles that seem to restrict special ability design actually let it flourish. We were free to experiment within the guidelines without worrying too much about whether the result would be fundamentally at odds with the rest of the game. Our experiments could still fail, but less catastrophically; the game would not break. Without any guidance we may have been too scared, or disorganised, to try anything new. {STEAM_CLAN_IMAGE}/32557867/3edb73d1ec79821abc7776dce6a246de96b0859b.png So Zero-K allows, and even encourages, special abilities as long as they fit into the design. In practise this means abilities have to pass two tests: they need to make sense within the game world and they should not be too hard to use. Whether an ability makes sense is the easier of the two to judge, since we have reasonably clear rules about things like armour classes, and the "theoretical ideal ability" test from Aim and Fire can be used for more than weaponry. How hard an ability is to use, i.e. how fiddly it is, can be harder to judge, since it involves tradeoffs against how much the ability adds to the game. The two guiding principles for fiddliness are that players should not fight the UI, and that abilities should avoid making units implicitly stupid. A lot of fiddliness comes down to how much attention is required to use it. The least fiddly type of ability is the passive ability. Damage types such as slow and disarm can be considered passive abilities, as could uncontrollable abilities such as shields. There is little risk of fiddliness or stupidity with such abilities, however the risk is not zero. For example, Racketeer needed quite a bit of AI work to make it smart enough to stagger its homing disarm missiles to maximise uptime. Technically the issue with Racketeer boiled down to firing being an active ability, but all units use their active abilities to control how their passive abilities are expressed, so accepting this technicality for this definition would render the concept of passive abilities useless. The next-best thing to a passive ability is a toggled ability that is designed to rarely need disabling. In practice this works a lot like a passive ability, but it is theoretically quite different due to the UI/Game World split, pictured below. Units are free to choose when and how to use active abilities, which opens up the possibility of units failing to do so correctly, either while idle or in response to player commands. The advantage of an automated rather than passive ability is that it can be disabled in edge cases, and that being able to disable an ability often makes more sense within the logic of the world. For example, Solar Collectors have a state toggle to keep them open under fire, because closing feels like a choice rather than something that is forced. {STEAM_CLAN_IMAGE}/32557867/22446832a867a9f89856992bf0f0aee8e3de3ce7.png The third type of ability, beyond passive abilities and automated active abilities, is manual abilities, which require direct player intervention to use. This category causes the most trouble, with the fiddliness of a manual ability largely depending on two things: the type of command used to control the ability, and how often the ability is used. There are broadly three types of command, categorised by the type of target they usually require: no target, ground target, or unit target. The simplest type of commands are those with no target. Examples include Swift boost, Krow cluster bomb, and the self-destruct button on crawling bombs. Just click the button (or press the hotkey) and the ability fires. This does not mean it is easy to know when to use an ability, just that issuing the command is not the hard part. The special abilities in Warlords Battlecry are all untargeted, which may have been an influence for Swift boost. State toggles can be considered as a sub-category of untargeted commands, but the mental overhead of tracking the state makes them a bit harder to use. Most toggled abilities, such as cloaking and floating, can be left on their default state, but there are a few that require toggling to use their full mechanics. The Pull/Push toggle on gravity guns is a good example, as is the manual hunker down ability of heavy turrets. {STEAM_CLAN_IMAGE}/32557867/b90ea685243eea05a85eb9dac5054651b3183c2e.png Ground targeted commands are the next-easiest type of command, the reason being that the ground is large and static while units are relatively small and often mobile. Ground targeted commands could be broken down further into line moves and area commands, but the added complexity of dragging a line or a circle trades off against increased expressiveness. Every targeted manual ability in Zero-K can be shot at the ground, and most are designed with this use in mind. Unit targeted commands are the hardest type to use. Structures are easier to click than units, and allies are easier to click than enemies, but they are all harder to click than the ground, so very few of our manual abilities are meant to be shot directly at units. Only a few of the most expensive units (Reef, Scorpion, Detriment, and some advanced commander weapons) have this type of command. The result is that players will rarely need to click enemy units, however, the word "need" is doing a lot here. Strictly speaking, players do not have to click the enemy units to have their own units use their abilities, however, this leaves the choice of target up to the unit AI. In practice players often tell their units to pick off a particular enemy unit by right-clicking it to issue a Force Fire command. The target priority even persists until overridden by another attack-type command, which is neat. But Force Fire has another use, one that, in conjunction with Hold Fire, circumvents the aforementioned guidelines for manual ability design. This is because, in Zero-K, if a unit has a single weapon, then it will (almost) always be treated as an ordinary weapon, regardless of how "special" it is. {STEAM_CLAN_IMAGE}/32557867/d3ebefb16a48371a30db2fab3e2d968fa5813111.png Quite a few of the ordinary weapons in Zero-K would be implemented as special abilities if they were to appear in other games. Some artillery units have reload times in the teens, with Lance even taking 23 seconds to reload. Firewalker fires bursts of fire that linger on the ground, while Placeholder launches miniature black holes to trap units in place. Players frequently set these units to Hold Fire and use them manually, just like a special ability. Even our nuke and missile silos use ordinary weapons, although these structures are set to Hold Fire by default. The only weaponless unit with a targeted special ability is the Lobster, as it caused too many accidents back when it responded to Force Fire. Using Hold Fire to turn ordinary weapons into special abilities might seem like a bit of a hack, but doing so has many benefits. To start with, using an ability by right clicking is more fluid than the two-step process of selecting the ability then left clicking. Hold Fire also lets players opt-in to complexity, and unit AI toggles such as overkill prevention and anti-bait let players configure how eager units are when told to use these abilities on their own initiative. The usual pattern is for players to micromanage a handful of units early on, then set groups of them to Fire At Will later. Returning to special abilities, weapons that are regularly used with Hold Fire work in much the same way as automated active abilities. They are expected to work in the hands of unit AI, which makes them much less troublesome than manual abilities. These weapons would actually make terrible manual abilities, because they regularly want to be fired as often as possible, which is one of the clearest indicators that a manual ability requires too much player attention. {STEAM_CLAN_IMAGE}/32557867/9c7e0911306741044ebfd7c4b434e1356a3b8dd1.png A good manual ability for Zero-K is one that players regularly have available, but do not use. Consider the alternative, if an ability takes 30 seconds to reload, and your aim is to use it as much as possible, then you now have a chore that requires your attention every 30 seconds. There is no decision in whether to use it, even though there may be some decisions to make in how it is used, it is just something that needs doing. This is why there are no ground-based sprint abilities: it is too easy for a sprint to be spammed to cross the map faster. Swift only gets away with it because it does not need boost to cross the map very fast. This brings us to a simple rule for manual abilities: they must have long reload times, or at least have some sort of opportunity cost, to prevent them from becoming chores. Jumpjets avoid this problem by being barely faster than walking, on flat maps, so that the distance gained is rarely worth the risk of being caught without a jump. Particularly expensive units can get away with breaking this rule, such as the Paladin's spammable EMP missiles, but rules like these can be broken by big expensive units that are expected to be the centre of attention. The design principles of Zero-K significantly constrain the special ability design space, but we still manage to have fun within it. Passive and automated abilities are relatively safe, with atomic unit design being the main hurdle, whereas too many manual abilities risk becoming chores. We currently have few enough manual abilities to put almost all of them on the same hotkey. The best way to add more would be to add more units, or even factories, to give players different abilities to manage, rather than more to manage at once. Index of Cold Takes

Almost everything players do in RTS is done by issuing direct commands or by toggling states. Direct commands give units a temporary goal, and include classics such as "move to this location" or "shoot at this enemy until it dies". State toggles make more permanent changes to how a unit behaves, at least until the state is toggled back. Examples include auto-cast toggles, toggleable abilities, and the stance and formation buttons used in the Age of Empires series. Toggles can be fine when used sparingly, but Zero-K did the opposite, to the point that we might have more than any other RTS. The upside is that we learned a lot about how and why to avoid state toggles. The allure of state toggles is that they seem to epitomise the idea of Fight Your Opponent, Not The UI. Players should be able to express their wishes with minimal commands; in Warcraft III you want a Priest to use its extra mana to heal, then being able to tell it to automatically heal implements that desire with one click. In Zero-K, players often want units to keep the enemy at their maximum range, which is much easier to do with a state toggle than a constant stream of redundant move commands. We can also think of state toggles in terms of the demarcation between a unit's abilities and its behaviours. For example, shooting feels like behaviour, so it makes sense to have a Hold Fire state toggle. {STEAM_CLAN_IMAGE}/32557867/3a25c011257767ea3187480b95f25edb139f0357.png There are broadly two types of state toggle: ability toggles and behaviour toggles. This is a useful distinction despite the fact that, at a fundamental level, everything a unit can do is an ability, and every different way it can choose to do it is a behaviour. In practise there is a often clear difference between controlling a specific ability or generic behaviour, although some toggles end up in between. Ability toggles are found in many games and include cloaking, burrowing and deploying. To be precise, we can define an ability toggle as a state toggle that is a necessary part of using an ability. You cannot set your tanks to siege mode without touching the siege mode toggle, but you can cast spells in Warcraft III without toggling auto-cast, so auto-cast is a behaviour toggle. On the topic of Warcraft and Starcraft, their Hold Position command is not a toggle at all since it has to be re-issued each time you want your units to stay still. Total Annihilation was one of the earliest games which put behaviour toggles such as Hold Position front-and-centre. Everything that moves had a move toggle with three states: Hold Position, Manoeuvre and Roam, with the latter two effectively being "move around a bit" and "move around a lot". Everything with a weapon also had a fire state with three states: Hold Fire, Return Fire and Fire At Will, with return fire causing units to shoot back after they take damage. Total Annihilation also had ability toggles, such as cloaking and the ability to turn Solar Collectors on or off. {STEAM_CLAN_IMAGE}/32557867/53a17fbd9d54954f86a3346e845031663f619366.png The problem with state toggles is that they are fiddly and are, for the most part, the least satisfying way to control units. Issuing orders, say to set up a flank or to unleash an ability on a group of enemies, is much more fun than fiddling around with buttons tucked into the corner of the interface. Many state toggles have subtle effects, which makes it hard for players to see that their actions had any impact. Seeing the states of units is itself a problem, as there is no good way to fully display the more abstract states. Zero-K fails to show all the different ways a state is toggled in a mixed selection of units, and while there is an option to show states overhead when shift is held, it is very messy so not something we would want to enable. The lack of visual feedback can be solved by reflecting the state of units in the game world, and games that limit themselves to a few high-impact ability toggles tend to do this well. Think transparent cloak effects or unit deployment animations. However, this solution does not scale, as it is most effective when the entire body of the unit is transformed, so multiple states end up fighting for space. It also does little to alleviate the fiddliness of toggling the state, or the mental overhead required to make sure your units are in the right state. Units with high-impact ability toggles require more player attention, which is a recipe for fights with the UI. Compounding these issues is the inexpressiveness of state toggles. A move command contains a lot of nuance about exactly where you want your units to go, and a line move contains even more, whereas a state toggle can only be in one of a few states. State toggles are a woefully inefficient way to communicate your intentions to your units. Admittedly there are exponentially many ways to set the states in an army of units, but toggling them all would take time better spent issuing many commands. We want to translate player intention to unit action as effectively as possible, and for this, state toggles are not the way to go. {STEAM_CLAN_IMAGE}/32557867/3972af3ced037d3f01786686343d5ccbea620eb8.gif Zero-K uses relatively few ability toggles and is a recovering behaviour toggle addict. Our use of ability toggles is curtailed by the idea that state toggles should be as optional as possible. This would seem to rule out many abilities, such as deploying to fire, but strictly speaking it only rules out versions of the ability that require a manual toggle. A toggled ability can have an automatic behaviour provided that toggling is never a bad idea. For example, our deployable units avoid state toggles by having their pack-up times tuned so that deploying is almost never wrong, so they may as well deploy automatically when idle. This restricts our design space, but removing a toggle is worth it. We have some true ability toggles, but many of them are designed to rarely need toggling. Cloaking is one example, as beyond the very early game it is rarely a good idea to turn it off. The cloaked constructor even has free cloaking to avoid micro-optimising it in the opening. In the case of necessary toggles we try to limit them to expensive units. These include the gravity gun push/pull toggle, high/low trajectory fire for particularly heavy artillery, and the hunker down ability of heavy turrets. The most common important ability toggle is probably the Float/Sink state for amphibious units, which is like deployment, but the transition takes a bit too long and it makes units vulnerable to surface fire. {STEAM_CLAN_IMAGE}/32557867/4c29dd62d86c8f16ba65f2e19f103c849f9881fd.png Sometimes a new ability toggle can be avoided by piggybacking on an existing one. For example a handful of light units and turrets can also hunker down to reduce incoming damage, but they do so fast enough for the behaviour to be automatic. Most of the time this lets them use the ability without touching a toggle, and in a situation where the units should stay armoured, they can be set to Hold Fire. The Float/Sink toggle works similarly since, by default, units only float to fire at the enemy. In more extreme cases we redesign units to remove state toggles, or avoid adding a toggled ability in the first place. Raven dive is an example of the former, while shield link is an example of the latter. It is important that state toggles can only be toggled by the player. This sounds obvious, but the default engine behaviour does not adhere to it. Cloaked units used to toggle themselves to "decloak" when out of energy, but revert back to "cloak" if energy became available. I assume the intent was to have the state of the toggle tell the player the state of an ability, but consider what happens when you want to decloak some units during an energy stall. Units that seem to be told to decloak are actually in a secret "cloak when there is enough energy" state, and this state was impossible to detect, let alone toggle. Trying to turn off a group of fluctuating cloaked units was a nightmare, so the player-facing state cloak and on/off states are now handled by Lua, and always reflect what the player told their units to do. {STEAM_CLAN_IMAGE}/32557867/8d4633562cbedb5e23e36f8feeba1ec8bf5861a4.png We managed to avoid having too many ability toggles, but went a bit overboard with behaviours. Early on in Complete Annihilation we had many developers adding all kinds of behaviours, so as a form of safety, each of these behaviours got their own toggle. Many of these behaviours were meant to be strict improvements, but we were humble enough to not expect everyone to want the new behaviour. The result was a number of toggles that were designed to never be touched, since the new behaviour should be better, and more flexible, to encompass everything a player might reasonably want their units to do. The behaviour toggle situation was dealt with in 2020. The more obscure toggles were hidden by default and the interface was changed to show at most twelve at a time, which is a limit that is very rarely reached. By this point few players could say where the engine unit AI ends and Lua takes over. The tactical AI gadget extends a lot of Attack Move and idle behaviour, including causing ranged units to stay at maximum range. Its toggle can be hidden because it is overridden by Move commands, and partially by Hold Position. Overkill prevention also has a hidden toggle, but is overridden by a Force Fire command. During the cull we also hid the mostly redundant third options for move and fire state, as a toggle with two states is much easier to use than one with three. The acceptability of a toggle depends on how it is intended to be used. Construction priority is one of the toggles we expect players to touch the most, but it is fine because it is rarely toggled in the heat of battle, and it implements a simple decision for which there are only a few options: high, low or medium priority. Construction is a long-term action and controlling its flow manually would involve a lot of redundant commands. For faster-paced situations, such as battles, the toggles are designed to be overridden by direct commands, to let players give commands rather than fiddle with toggles. {STEAM_CLAN_IMAGE}/32557867/1854022899ce453aa78e22582373bb5a7082db88.png The silver lining to all this state toggle proliferation is unmatched customisation of unit behaviour. Early on we added a section of the menu that lets players set their own default state for each unit type. Some players, including myself, like to set everything to Hold Position, while others set up preset construction priorities to make sure their metal extractors are built as fast as possible. The extraneous toggles that nobody wants to tweak in the heat of battle found their home here. Players can disable various bits of the unit AI on a per-unit-type basis, for every future battle. What started as a mess of widgets, all with their own toggles, ended up being a vast set of options to tweak unit behaviour to your liking. Index of Cold Takes

Most strategy games have tools for spying on the enemy, often at the cost of resources. This is known as scouting, and it is a tricky thing to design since its balance depends on the usefulness of information. Scouting is a waste of resources if you know the enemy's plans, or if your response would not be changed by knowing them. On the other end of the scale, games with large strategy spaces rely on strong scouting to keep strategic RPS in check. To complicate things further, the power of scouting changes over the course of a game as the strategy space expands. Scouting is always competing for resources that could be spent on building up your economy or deploying a larger army. Small differences early in a battle can snowball into a large advantage later, which makes scouting a hard sell for the early game. In Zero-K this is reflected by a lack of dedicated light scout units. Early scouting is done by raiders, which are able to deal damage as well as spy on the enemy. Even the nominal "Light Scouts" are armed and able to harass undefended constructors and metal extractors. {STEAM_CLAN_IMAGE}/32557867/f6125a120c7cd749a1fa44b4791238c1a4ae9254.png It would take a bit of a redesign to see pure dedicated scouts in the early game. Such a scout would have to be either very cheap or very powerful to offset its drawbacks. This power could be relative, i.e. raiders could become near-blind, but the issue with blind units is that regularly blundering into the enemy feels bad. Ultimately we avoided forcing dedicated scouts into the early game as it would be too much to manage. Remember, monospam is much easier to use than a mix of units, and there is already plenty to do early on without extra complication. We only discovered this relatively recently after adding the Sparrow. Sparrow is a light scout plane that is accessible to all factories by morphing a Radar Tower. These days Sparrow is a bit too expensive for the opening, but initially it was much cheaper, at 120 metal. This turned out to be too powerful as the ability to see everything made it too easy to punish deviations from a middle-of-the-road opening. In general scouting is too powerful when it removes otherwise reasonable strategic approaches. Most of the strategies that push at the edges of the strategic triangle are aided by the fact that the enemy cannot instantly start moving to counter them. In addition to being too powerful, early Sparrow was too onerous. Scouts take attention to keep alive, since they want to get close to the enemy, and it takes even more attention to use the information they reveal. Some of the immediate burden is reduced by the fact that scouted structures leave a persistent "ghost", but there is no such feature for units. Early Sparrow was particularly problematic because it could fly around dodging turrets for minutes. This is not so much of a problem later in the game, as once dedicated AA comes out scouting missions tend to be quick and one-way. There are other types of scouts, such as cloaked units, that can hang around, but they require much less attention to manage than a flimsy plane. {STEAM_CLAN_IMAGE}/32557867/39e8ba143aeff8fda308debb978f98e8d9bc9a17.png Different types of scouts are good at different types of scouting, and players pick them based on what they want to discover. One type of scouting is "weakness scouting", i.e. scouting to find a crack in the enemy's defence. Raiders are particularly good weakness scouts because they are equipped to follow up on the weaknesses they find. Another type of scouting is "threat scouting", in which players seek to reveal and preemptively counter enemy plans. In fact the cheapest dedicated scout in Zero-K is a threat scout: the Radar Tower. It is perhaps a little weird to call a structure a scout, but I would also call the Starcraft Comsat Station a scout. A Radar Tower provides threat scouting in the sense that it gives you a few extra seconds to respond to an incoming attack. This extra time lets players redirect their forces to repel the enemy, which lets turrets be a bit weaker than they would otherwise need to be. If radar did not exist then players might also have to leave several raiders on the outskirts of their territory to detect threats which, as with Sparrow, would be a bit too onerous. Players currently use raiders for threat scouting beyond the range of their radar, but they do so sparingly in important areas of the map. It is good in moderation, but making this the only way to detect threats would involve too much micromanagement. {STEAM_CLAN_IMAGE}/32557867/3ce7e0abaf2f282ef184bf854f9d2bed815a39a9.png The nature of threat scouting changes over the course of a game, with the main distinction being how early the threats are revealed. All plans are revealed eventually (such as when the nuke launches), but plans that take longer to implement can be revealed earlier than others. Threat scouting for long-term plans is a big part of the dance around the strategic triangle as it is hard to counter your opponent without knowing what they are up to. Long-term threat scouting comes to the fore in the mid-to-late game. By now the battle lines have met up and most short-term threats are adequately covered by radar. In this situation the type of threat revealed depends on how much you spend on scouting, and on how much the enemy tries to stop you. A shallow scout might find a medium-term threat, such as a Cerberus or Missile Silo, while a deep scout can find long-term threats such as nukes, Striders and superweapons. Long-term weakness scouting is also possible, with the most common being to check for antinuke coverage. Late game scouting in Zero-K is designed to be nearly impossible to completely counter, but it is not so cheap that it can be done at a whim. If scouting were easy to block, then people would do so, but this would create a blind strategic RPS situation so strategy space would likely have to contract. The most common form of deep scouting is to boost several Swifts, a light fighter, over the enemy's base. Boost causes a Swift to move much faster for a few seconds, and while it was not initially designed as a scouting tool, it has persisted in this form and sets a reasonable cost for a full scout. {STEAM_CLAN_IMAGE}/32557867/7595d7f90931c5e4b2777a9fe1879f05fabba3f9.png A limit to how little it should cost to scout was found with the discovery of flying Flea scouting, which involved launching Fleas into space with a cheap Newton launcher. Landing was a non-issue because line of sight was cylindrical at the time, so the Flea just had to fly high over the map to reveal a whole swathe of the enemy base. This tactic was far cheaper than other options, so we nerfed it by reducing the sight range of high-flying ground units. Scouting via flying Flea is still possible, but they need to be shot low and fast to see anything, which requires a more expensive launcher and gives the enemy a chance to shoot them down. The Flea launcher had one thing going for it: the enemy could see all the Fleas flying over their base. Being able to see that you were scouted is generally a good thing, as it enables more player interaction and mind games. For example, I have seen someone start a nuke rush, have it scouted, then abort the rush and count on the enemy spending resources on countering a nuke that is not there. The scoutability of scouts has exceptions though, primarily with cloaked scouting. The tradeoff here is that cloaked scouts are slower and harder to use, and often they are spotted, which alerts the enemy to the fact that they have been spied on. {STEAM_CLAN_IMAGE}/32557867/d8c61a3ed91d7198498f80666eab898828957cf6.png Scouts revealing themselves creates a weird situation when trying to determine which factory the enemy picked. You might spot the factory, or a unit from the factory, but the scout you send is guaranteed to give away your own factory. There are a few ways to get around this, such as with Sparrow, but they are impractical early on. In a 1v1, being scouted is the only reliable way to learn the enemy factory without revealing your own. Scouting and raiding is otherwise important enough for this to not be a concern though, and perhaps the interaction is not that unusual. Most multiplayer games reveal faction choice in the lobby, but some have a hidden random faction option which is only revealed when they scout. So the situation in Zero-K is more a result of factory choice (which is effectively your faction) being hidden by default. In spite of a few persistent bits of weirdness, I am quite happy with the state of scouting in Zero-K. Information on expansion and raiding is valuable early on, and there are many prime scouting targets to spot as the game progresses. Players have many ways to scout, with a variety of planes, cloaked units, and a few units that are tough enough to punch through into the enemy base. Even Sparrow found a place as a radar jammer and cloak-revealer, beyond its use as a readily accessible deep scout. Scouting feels rewarding and is rarely impossible, but is expensive enough to be a deliberate decision point. The decision to scout is the most important part, as if it were routine and decision-free it could be automated, but it would be a shame to effectively remove such a rich source of player interaction. Index of Cold Takes

{STEAM_CLAN_IMAGE}/32557867/7c2e8c8f7e085564a4f46f10530a00da2ae599c0.png This release is mainly about tweaking a few overused units. Venom is slightly worse at stunning to counteract the overstun change, and other Spiders were buffed to compensate. Lobster now gives the enemy a little more time to react and Magpie should be easier to scare away. Terraform is also UI-nerfed against Missile Silo, as the Force Fire UI now warns you about unintended terrain interactions. The engine was also updated, and it should stick this time as it was found to be quite stable in testing. The big feature is the adoption of quaternions for unit animation (just in the backend, no API changes), which makes units move and aim more smoothly. Missile trails are also much smoother, replacing the old jagged lines. These changes were blocked behind the game-side graphics update of a few months ago, and the work is ongoing. For example, this release includes a new shiny Likho texture by brunocb.

Balance

Lobster launch is slightly delayed and can be interrupted. It also costs slightly more, but at least none of these nerfs are to launch range.

• Cost 340 -> 350
• Reload time 14s -> 18s
• Time from initial upwards launch to sideways impulse 0.16s -> 0.4s
• Dead or disabled Lobsters no longer complete their launches from beyond the grave.

Magpie loses its exceptional health efficiency but gains a little damage efficiency (scary!)

• Cost 220 -> 210
• Health 900 -> 740

Venom is slightly worse at stunning, to the point that three are required to completely lock down a unit.

• Reload time 1.13s -> 1.2s
• Overstun time 0.5s -> 0.3s

Hermit deepens the Cloak-Spider ability exchange.

• Now heals at 10 hp/s after 10 seconds of not taking damage.

Redback is tougher and is better at aiming.

• Health 900 -> 980
• Turret swivels 50% faster.
• Range 300 -> 310

Tarantula gains damage to compete with lighter and faster anti-air.

• Damage 270 -> 310

Thug has a better weapon.

• Turret turn rate buffed by 20%
• Reload time 4s -> 3.9s
• Projectile speed buffed by 2.4%
• Damage 170 -> 180

Skuttle deals slightly more damage on near misses.

• Area of effect edge effectiveness 0.3 -> 0.4

Claymore is better behaved at sea.

• Fixed a bug that prevented it from aiming directly behind itself.

Flail leans into its weakness as it seems slightly too good since its buff.

• Reload time 5.2s -> 5.4s

Mariner becomes one of the more efficient constructors.

• Cost 200 -> 170
• Build range 330 -> 350

Ultimatum is slightly cheaper and harder to find.

• Cost 2500 -> 2400
• Decloak radius 120 -> 110

Amphibious water regeneration is no longer active when flying over the water.

Interface

• Queued jump commands now activate as soon as a units stun or disarm wears off. Previously the command could be delayed by up to half a second. This means that Pyro will always be able to find a split second in which to jump away from a pair of Venoms.
• The Force Fire area of effect preview now indicate when a vertically launched missile would hit terrain (Impaler, Trinity, Missile Silo etc).
• Added size settings for healthbars ingame under Settings/Interface/Healthbars (thanks therxyy).
• Units no longer lose experience when they damage units that were previously killed on the same game frame. For some reason this mostly affected Jugglenaut.

Graphics

• Updated Likho texture to take advantage of the new tech (thanks brunocb).
• Missile trails are no longer jagged.
• Unit animations are now smoothly interpolated between frames.
• Tone down Ripper roughness to restore some ambient brightness (fixed since v1.13.12.3).
• Thug model is no longer slightly off-centre.
• Toned down the slow component when mixed with EMP and disarm, to make EMP and disarm easier to see.

Modding

• Multi-unit piece attachment monstrosities no longer have a 1-frame delay when updating child positions. I.e. the subtle issue demonstrated below is fixed, and will scale to deeper trees of attachment. Just saying...
• Fixed potential bug with Engineer Blueprint blocking normal build options. The main game happened to avoid triggering it.
• Fixed massively overslowed units drawing the disarm effect.
• Fixed an issue with combining static and dynamic model rescaling (thanks XNTEABDSC).

{STEAM_CLAN_IMAGE}/32557867/20e54e554c121063006e78de803ca310d7e8b871.gif

Fixes

• Fix status effect bytepacking (floatpacking?) so slow + fire != disarm (fixed since v1.13.12.3).
• Being "stunned" by being in a transport no longer draws the EMP effect (unless the unit also has enough EMP damage to be stunned).
• Another attempt at fixing post-jump Jugglenaut, Detriment, and Recon Commander skating.
• Fixed Lobster-launched units sometimes leaving tracks on the ground below them near the end of their trajectory.
• The Tank Plate unit portrait now matches the unit.
• Fix crash when Draw on icons is not enabled (thanks Helwor)
• Fixed a small visual issue with terraform point rendering.
• Fixed Claws sometimes showing a radar dot shortly after death.

Strategic freedom is a fragile thing, yet the feeling of devising your own plans is something that many games try to instil. The issue is that, as players explore and refine their strategies, the space of viable strategies can narrow down to a few options. This is usually seen as a problem with competitive multiplayer, but singleplayer games are not immune. Any game that offers strategic exploration and mastery risks revealing itself to have only a single best approach, and if the challenges become great enough, players will resort to it. This problem is never fully solved, only managed, but there is still quite a bit in the managing. This post is on some concepts that help tackle the problem above: strategic RPS (rock-paper-scissors) and the strategic triangle. Strategic RPS is a simple model of strategy that reduces decision making to one of three approaches: offence, defence, and economy. These approaches form a natural counter relationship where offence beats economy, economy beats defence, and defence beats offence. Many players have an intuitive understanding of strategic RPS, as it is common knowledge that defensive play is beaten by investing in economy and eventually overwhelming the defences. {STEAM_CLAN_IMAGE}/32557867/5031c7bfce1e9c8e011c9d912dbe5ec1fd7f7633.png The power of strategic RPS is its generality, at least if we define it broadly enough. This requires a brief detour into the idea of economy. The standard economy of RTS involves extracting resources such as metal, ore, or minerals, then spending it on units and more economy. But the economy part of strategic RPS encompasses more than that. To start with, it is useful to think of construction capacity (buildpower in Zero-K) as a form of local, unstockpileable, resource. We can go further though, as the cost of anything can be converted into the time taken to assemble its prerequisites, which suggests treating travel time as a kind of cost as well. Many games have resources in the most general sense, but what sets strategy games apart is the ability to make choices that dramatically increase your resource income. We will call income-increasing decisions "economic investment", and the term encompasses all ways to reduce your strength now for the promise of greater strength later. This covers building metal extractors and power plants, but also covers actions such as research and increasing your tech level. An upgraded unit is a more efficient unit, so upgrades are roughly equivalent to generating extra income that can only be spent on unit production. Local actions can be economic investment too, such as moving a constructor to a better location. The constructor trades the work it could be doing now for the ability to do work in a more advantageous position later. It takes more time to "produce" a constructor far from your factory. {STEAM_CLAN_IMAGE}/32557867/39713112be9c43f175fdbecaca925d976367ce74.png It is worth taking a closer look at the relationships between the three aspects of strategic RPS. In doing so I want to demonstrate the strategic RPS is something intrinsic to strategy games. Once you have economic investment, you have strategic RPS, and it takes extra work to downplay or remove. It all hinges on economic investment, so we will start there. Offence beats economy because economic investment leaves the investor vulnerable to attack. RTS needs offence because otherwise there would be nothing to stop players funnelling all their income into more and more economy. Strictly speaking, a game with absolutely no offence would lack a win condition, as even the most economically focused strategy needs to turn its overwhelming resource advantage into a way to kill the enemy. This is how economy beats defence: if both sides leave each other alone for a while, the side with more economy will overwhelm the other. With the economy interactions of strategic RPS figured out, the relationship between offence and defence can only go one way. "The best defence is a good offence", or so the adage goes, but this is not the case in strategic RPS. Offence already beats economy, so for offence to not be the dominant strategy it had better lose to defence. Strategic depth in RTS requires that there be ways to spend resources defensively, and defences have to be good enough to fend off a greater investment in offence. Note that this does not mean all games need turrets. Producing defence-oriented units counts as defence, as does building in a more defensive way, at the cost of some economy. Starcraft provides an example with ramp walling, since it takes workers longer to reach structures when they are built further away. Strategic RPS is a decent model, but it is a bit unrealistic as players rarely go all-in on offence, defence, or economy. Back in the day we would use the term as a shorthand for related ideas. For our purposes we had better park the term here and start on the strategic triangle. {STEAM_CLAN_IMAGE}/32557867/1dd8e8a5b8725e1aab3ff0a5d4729125bdb61423.png The strategic triangle is a map of strategy space, where strategy space can be imagined as a nebulous cloud that represents every approach players could take in a game. The strategic triangle adds structure by scoring each approach by how offensive, defensive, and economic it is. The space is then stretched and flattened into a triangular shape so that the most extreme strategies sit at the vertices of the triangle, while everything else exists somewhere in the middle. To simplify things we also discard the pointless strategies, such as that of blowing up your commander at the start of the game. If you want to get technical you could consider the triangle to be the Pareto frontier of the projection of strategy space onto three dimensions. In other words, the strategic triangle is the nuanced version of strategic RPS. Players can do a mix of offence, defence, and economy. The strategic RPS relationships still hold though: we expect a strategy that focuses mostly on economy to lose to one that focuses more on offence. The first thing to notice about the strategic triangle is that it is inherently unbalanced. Remember "the best defence is a good offence"? That turns out to be good advice, in a roundabout way. The most general type of RTS strategy advice often boils down to making as much economy as possible while investing in as little defence as you can get away with. Offence is often an effective way to tie your opponent in knots and trick them into making more defence than they need, reducing their expenditure on offence and economy, hence the adage. Economy is the best way to get a long-term advantage, and economy beats defence, so whoever builds the most defence loses. This bias in RTS is probably due to the focus on armies and quick combat, compared to other genres of strategy game. {STEAM_CLAN_IMAGE}/32557867/5a93c566e537e86672d88b6b782acc1478d79931.png The strategic triangle helps us create a sense of strategic freedom because, as a map of strategy space, its size reflects the range of options available to players. But its main purpose is to highlight and avoid strategic RPS. As you may have guessed from its somewhat pejorative name, players tend to complain about strategic RPS when it becomes too apparent. A satisfying game involves jockeying for position on the strategic triangle, trying to counter whatever the enemy is up to via scouting and intuition. There is tension here: strategic freedom demands a large strategy space, while an aversion to too much strategic RPS demands that it remain small. The solution, used by Zero-K and many other games, is pretty simple: start battles with a small triangle and grow it as the match progresses. This is why there are relatively few options early in the game, with relative soft counters. It is only later that the hard stuff comes out, such as nukes and bombers. But how do we dial in the size of the strategy space, or in other words, how do we bound the strategic triangle? The trick to bounding the strategic triangle lies in the realisation that most actions achieve a mix of offence, defence, and economic growth. So, for example, if we wanted to prevent players spending more than 60% of their resources on offence, we would just have to avoid giving them any options that are more than "60% offensive". These numbers are just made up, remember that the triangle is conceptual rather than calculable, so it is time for some examples. {STEAM_CLAN_IMAGE}/32557867/9ea9e7a08ef341953c072deb6cceb4f6c4d58c5c.png Take the very first unit of the game: the commander. Its laser and high health pool give players a baseline level of defence, while its income and ability to construct constitute economy. This starts players in the defence-economy area of the triangle, and there is a limit to how fast their decisions can them in other directions, limiting the extent to a player can go all-in on offence. At one point we experimented with starting players with an ordinary constructor, but the lack of the commander as "strategic ballast" resulted in too much strategic RPS. Here is another example: constructors can build turrets, which makes sending a constructor out to build metal extractors a partially defensive action. Constructors can even end up taking on an offence role when they move close enough to the enemy base. So even the most greedy economic opening has built-in defence. Just imagine how swingy a Zero-K with dedicated economy-constructors and defence-constructors would feel. The cost of metal extractors has also gone up over time, limiting just how quickly a greedy opening can shore up its weaknesses. Most units perform all three roles. A riot that sweeps raiders from a potential expansion site is performing an economy duty. Alternately it could defend existing metal extractors or trundle towards the enemy expansion. The most generic view of resources considers units to be resources that are spent by placing them in different parts of the map, since they can only be in one place at a time. This flexibility of deployment smooths over a lot of potential excess strategic RPS, as it means that decisions are not just made when a unit is built. {STEAM_CLAN_IMAGE}/32557867/0dc662a35b3a5caa98d4735bfd643fc6ba2c6fcc.png Our attempts to bound the strategic triangle often butt up against other design principles. Atomic unit design prevents individual units from performing too many distinct roles, and Quant's Rule is always pushing everything to the outskirts of the triangle, where strategic RPS is the strongest. We have, at times, considered giving factories an inbuilt turret to boost their inherent defence, but ultimately felt that such a thing would feel too arbitrary. Similarly, we avoided adding armed metal extractors because we wanted to retain the feasibility of pure economic expansion, with no defensive aspect, at least once the constructor has walked away. The strategic triangle is most useful for thinking about the early stages of the game. This is fine, as every game has a beginning, and this part of the game is often the trickiest to get right. However, it does limit its applicability in large team games, as they quickly become too complex to analyse. The ideas are broadly applicable as, for example, a team that captures ground and invests in economy will beat one that does not, but these are rarely the decisions of individual players. Luckily for us, these games rarely have a problem with strategic RPS, so the strategic triangle can stick to doing what it does best. Index of Cold Takes {STEAM_CLAN_IMAGE}/32557867/e1112ff10b09cb2932a4de57cfc5776316906bb7.png

The Huge Graphics Update of last week was a huge success and only introduced a few minor issues. This update fixes the ones that we are aware of.

• Fixed a texture detail issue that made units slightly pixelated and a bit harder to distinguish at medium zoom levels.
• Tweaked outlines to be a bit more visible when zoomed out, by default.
• Fixed status effects clipping into undamaged nanoframes. The status effect shader thought that nanoframes should be deformed, but they are not.
• Fixed grid hotkeys missing from most build menus.
• Added Colemak keyboard layout preset (thanks allentiak).
• Factories now open automatically when completed.
• Amph and Spider now have to wait 1s to open before starting production, to match other factories.
• Fixed the lighting on a few more maps.

This update overhauls the tech behind drawing units, wrecks and map features on your screen. This has many advantages. To start with, it allows for more and better looking fancy unit rendering effects, many of which are showcased in gif form below. It should also be less performance hungry on most hardware since it makes much more use of the GPU. The deeper impact is that the new tech (physically based rendering) gives artists more tools to make units look even better. Tweaking textures to work with the new tech is an ongoing process, and one that would be much improved by the help of a volunteer artist or two. Another task is that of improving the lighting on many maps. Units are now more responsive to the sun, and tweaking it is just a matter of moving a few sliders around. Most of this work builds on efforts within BAR to push the visuals of the engine forwards, with special thanks to ivand and FLOZi for assistance with adapting and improving it for Zero-K. We also want to thank the testers and contributors that helped add features and find technical issues prior to release. Finally, thanks 64-Bit Dragon for putting together the video below.

Visuals

{STEAM_CLAN_IMAGE}/32557867/5a28a2f7dea8b116239d9fea9638dd86754f7ef1.gif New and improved status effects! {STEAM_CLAN_IMAGE}/32557867/16171926525092e9f5f433379162295ffd77b577.gif{STEAM_CLAN_IMAGE}/32557867/24413248118cd418ae69a6673684c70079b1f09f.gif Fancy nanoframes and swaying trees! The nanoframes are highlighted near 99.9% to make abandoned construction harder to overlook. {STEAM_CLAN_IMAGE}/32557867/5efaa0c09d44732d1810d5ece4833728a11b5beb.gif Units start getting wrecked before they die! {STEAM_CLAN_IMAGE}/32557867/511fe3bd15c1dcbf768e7bd3e10d64ff2323f66d.gif Trails for pew-pew lasers (thanks Thorneel)! {STEAM_CLAN_IMAGE}/32557867/0ce18363b64697e8865c23e6f2e9618d89c1707c.gif New cloak effects! {STEAM_CLAN_IMAGE}/32557867/84ea9d44b505a2b986973e403adede71d9081fbc.png Relatively modern physically based rendering to expand the artistic palette! Also:

• Units cast shade on each other.
• Boosted contrast adaptive sharpen slightly.
• Toned down bloom.
• Disabled screen space ambient occlusion by default as it is not worth the performance cost.
• Adjusted the textures of many units and the lighting on many maps, but there is still more to do.

Features

• Improved the radar shadow preview widget and enabled it by default. It is now more accurate (thanks Helwor) and takes structure terraform into account.
• Units stop and wait when a nearby friendly transport tries to pick them up.
• Constructors in friendly transports are considered idle when the transport is idle, and pressing the idle constructor button selects the transport (thanks strategineer).
• Constructors in enemy transports are no longer considered idle (thanks strategineer).
• The idle constructor button flashes briefly when a new constructor becomes idle, configurable under "Settings/HUD Panels/Quick Selection Bar" (thanks strategineer).
• Added tooltips for endgame awards (thanks strategineer).
• Factories no longer inherit the retreat state of their builder by default.
• Added maximum zoom option to the COFC camera (thanks therxyy and kcin).
• Added clickthrough settings for the command panel and quick selection bar, found in "Settings/HUD Panels" (thanks strategineer).
• Added an option to show unit icon on the command panel, found in "Settings/HUD Panels/Command Panel" (thanks strategineer).
• Added Workman keyboard layout preset, found in "Hotkeys/Grid Hotkeys" (thanks strategineer).
• Tidal generator placement no longer uses the wind icon to denote income (thanks strategineer).
• Made it harder to unwittingly disable shaders in lobby settings.

Mapping and Modding

• Units and map features can be given normal maps by setting customParams.normaltex. Eg normaltex = "unittextures/bomberheavy_normals.dds".
• Model tex2 is now interpreted as a PBR texture. Red is emissivity (for lights and engines), green is metalicness, and blue is roughness.
• Unit textures can now be overridden with customParams.override_tex1 and customParams.override_tex2. Eg override_tex2 = "unittextures/m1r0.dds".
• Shielded units can set customParams.shield_fxs_type = "chicken" to render a chicken shield (thanks XNTEABDSC).
• Added a toggle for the metal spot placer mapping tool to Settings/Toolbox.
• The startbox editor now has a tooltip that tells you where it the startbox file.
• Added a tickbox under "Settings/Graphics/Sun, Fog & Water" to set a default sun angle and pitch.
• Developer mode detection also looks for devmode.txt.txt.

Fixes

• Hacksaw no longer wiggles around while under construction.
• Non-line jump commands to groups of units now only spread units to passable terrain.
• Fixed slightly misapplied Ronin texture (thanks garfild888).
• Fixed Gnat gun being slightly detatched from its body. (thanks garfild888).
• Fixed unit information window crash on Funnelweb space click.
• Fixed Mace sometimes having trouble leaving the factory.
• Fixed Duck range not resetting properly when exiting deep water (thanks strategineer).
• Removed excess technical details from unit spotter markers on AI units (thanks strategineer).
• Fixed resource bar text truncation with large font sizes (thanks strategineer).
• Shifted the default garbage collection rate more towards stability.
• Removed leftover terraform points on planet Ungtaint.

Shield generators are a mainstay of sci-fi across mediums, and RTS is no exception. Games tend to use shields as an extra type of hitpoints, one that tends to have some advantage or is at least easier to replenish. They also make for great eye candy. So it is weird that Total Annihilation lacks shields, and understandable that almost every game it spawned includes them. Even TA modders got in on the action, although reportedly the shields were quite laggy as they reused the nuke interception system. Zero-K uses shields both in close quarters combat and as defence against long ranged artillery. Very long-time players, or just those with some knowledge of BAR, may be wondering why Zero-K shields are hard shells, when instead they could be bouncing projectiles all over the place. This is a weirdly specific question to everyone else, but it makes sense in light of the history of Spring, the underlying engine. The default shields were repulsion shields, and while they are unlikely to make a comeback, their removal was a great test-bed for a slew of principles that came to define Zero-K design. {STEAM_CLAN_IMAGE}/32557867/86c785d6fbebce1e924bee0f8f54c44ca74ccd8b.gif Shield support was added to Spring in 2005 by SJ, back when the engine was the experimental playground, as Lua scripting was yet to be added. Not to be outdone by the future wackiness of Complete Annihilation, these shields repelled projectiles, with the Zero-K hard-shell version only being added later. Repulsion shields were taken up by the TA-derived mods, primarily as a defence against late-game Big Bertha spam, and 20 years later this is still their role in BAR. But Complete Annihilation, and later Zero-K, was very much about pushing mechanics as far as they can go, and damage mitigation opens up too many possibilities to be left to languish in a corner of the game. Besides, the narrow late-game linchpin role was superbly filled by nuke and antinuke, so we set out to integrate shields into the rest of the game. We succeeded, but had to drop repulsion as a result. Repulsion shields were fun, and it was sad to lose them, but ultimately they were unworkable. To start with, blocking plasma cannons while allowing everything else through felt too arbitrary. Consider Glaive and Bandit: both are light raiders, but one shoots plasma while the other has a laser blaster. This caused plasma repulsion to theoretically counter Glaive and not Bandit, but this was fine in prior games since raiders were obsolete by the time shields showed up. We could have designed around this counter relationship, and the missile defence lasers in C&C: Generals are an example of this, but doing so imposes a lot of design constraints. By this point we had plenty of constraints, and a diverse set of weapons designed with them in mind, so adding a hard counter would have destroyed much of what we had built. The result is that our new shields had to interact with all types of weapon. {STEAM_CLAN_IMAGE}/32557867/4b0fc4eb6a736989f263545759d877d4517b1ace.gif The engine supports repulsion for non-plasma weapons, but the behaviour is inconsistent. Lasers bounce right off while rockets and missiles are turned away using their usual turn radius. Homing missiles even resume homing after they leave a shield, which looks a bit ridiculous and can make shields a liability. But the more general issue is that of cost: repulsion shields push projectiles away over time, which drains shield charge for as long as the projectile is within the shield. This is cool in that it lets an overwhelmed shield fail gradually, but it plays havoc with any attempt to balance drain rates. The speed of the projectile matters quite a bit, as does the angle at which it hits the shield, since glancing blows take less force to deflect. Particularly fast projectiles, such as riot cannons or tactical missiles, can penetrate quite deep into the shield before being significantly deflected. The charge drain of lasers was sensible, since they are reflected instantaneously, but attackers could still line up shots to drain charge from multiple shields at once. Perhaps these issues were solvable and, with enough tweaking, we could find a way to balance the cost of repelling all types of projectile. But the nail in the coffin for repulsion is that it offers units far too many ways to be stupid. It is undeniably cool to see shots flying around, but they mostly fly back at the army that shot them. One solution might be to have units aim slightly upwards, so the shots return over their heads, but this has two issues. Firstly, it is not a foolproof default, since the best way to drain a shield is often to shoot directly at it, so whether to risk friendly fire becomes an extra strategic decision. Secondly, we have gone to great lengths to avoid having units shoot into the sky, and allowing it opens up a whole new can of worms. {STEAM_CLAN_IMAGE}/32557867/a62098c303c4f29cdfe21b8bc7f7e101b1e8aadb.gif In the end, the fun physics had to be put aside, and shields became hard shells that block enemy projectiles. The projectiles are blocked by detonating them mid-air, and doing so costs shield charge equal to the damage of the projectile. If a shield has insufficient charge at the moment of impact, then the projectile is allowed through. Shields regenerate charge over time, and share charge around to try to equalise nearby shields. This is a fairly simple system, but there is enough to it to dial in some satisfying interactions. One important technicality is that projectiles explode on shields, and this can even damage units behind the shield. It has to be this way since blocking the area-of-effect (AoE) damage of explosions damage would be a nightmare, both computationally and intuitively. A shield that blocked explosion damage would also have to block damage from shots that hit the ground just outside the shield, otherwise units would be incentivised to fire at the ground rather than into the shield, which would look silly. But damage should not be blocked for free, which implies that nearby explosions should consume shield charge. How much charge? Well, explosion damage is reduced by distance, but there is the potential for shields to be stacked behind each other, so shields would have to be able to protect each other. This is further complicated by the fact that units can straddle shield boundaries, making it unclear what is being protected. So rather than block area of effect damage, we embrace the fact that AoE is effective against shields, especially smaller personal shields. {STEAM_CLAN_IMAGE}/32557867/3cac596c65741761ccd72f40a91cf34aad1e1156.gif Another notable part of the shield mechanics is that the interception threshold is per-projectile. So a shield at 599 charge lets through a 600 damage projectile, but would block half the damage of two shots that deal 300 damage each. Bursty units are balanced around this fact, with an extreme example being the 3000 damage Lance that deals damage in chunks of 150 over the course of a second. Phantom, with a single 1500-damage bullet, is generally better against shields for this reason. We have even used burst to buff units against shields, such as when the double-barrel shot of the Firewalker was split into ten projectiles, each with reduced AoE and more total direct damage. The interaction of burst damage and shields is one of the better kinds of emergent behaviour: one that players could reasonably puzzle out intuitively, rather than requiring the kind of deep dive that would be required to figure out how to optimally drain a repulsion shield. The most unusual feature of Zero-K shields is something called shield link, which causes clusters of shields to gradually equalise their charge. It was most likely added to deal with the problem of wasted regeneration, since shields only regenerate when not fully charged. Minimising mid-combat regeneration is important when fighting shields, which can be achieved via focus fire. However, mobile shield generators can negate focus fire by dancing around so that each shield gets a turn at the front. This is a case of skipping the unit AI arms race by implementing the final result, so charge from high-charge shields flows to nearby shields of lower charge, leaving more space for regeneration. Shield link turned out to be a buff to burst damage because it caused clumps of shields to lose charge together, rather than individually. The best demonstration of this is the way tacnukes counter shields. A tacnuke deals 3500 damage, while large shields have 3600 charge, so without shield link you would need to spend one tacnuke per shield to drain a cluster enough to start penetrating it. With shield link, a single tacnuke can disable any reasonably sized cluster. All you need to do is fire the first tacnuke, wait a few seconds, then fire the followup. Charge rushes into the newly depleted shield after the first tacnuke hits, so by the time the second volley arrives there are no shields capable of stopping a tacnuke. {STEAM_CLAN_IMAGE}/32557867/d673a7c72dc6ee2e18a71fc148746f5d98772ea6.png Shields would rather not be exploitable by tacnukes, but as we saw 25 posts ago, shield link is not optional. The downside of shield link gives shields space to be powerful in small numbers without becoming that much more powerful when spammed. This is the sweet spot we aim for across Zero-K as it encourages people to use a mix of tools, and it is especially important for mechanics that can slow down the game by preventing damage. The goal is to see a bit of shielding in many battles, rather than a lot in a few. This goes all the way back to the decision to make mobile shields and cloakers available to all factories by being available as a morph from their static versions. On the technical side, shield link has been through two iterations. It was originally a deterministic algorithm that would have each shield poll its neighbours and move closer to the average, adjusting each neighbour by the same amount. This had performance issues and edge cases, so was replaced by a random sampling approach. Now shield link works by having each shield select a random neighbour to exchange charge with, 15 times a second. This is fast enough for random variations to average out, and it is much simpler than the previous approach. {STEAM_CLAN_IMAGE}/32557867/50f538209f750e792f9715c50cc9d1a880363159.png The last issue for today concerns status effects. Weapons should generally interact with shields, and thematically it would be weird for a lightning bolt to ignore shields or to be harmlessly dissipated. But letting shields take EMP, disarm or slow damage as if they were fully independent units would be too complicated. So to keep things simple, status effects deal damage to shield charge, just like ordinary damage, with caveats. The damage numbers of status effects are quite a bit higher than those of ordinary damage, since status effect damage has to hit health thresholds to take effect. Their raw damage would completely annihilate shields, so status effects only deal a third of their damage to shields. This is one of the rare instances of damage multipliers in Zero-K, and it is still enough damage to make lightning and slow damage some of the most effective ways to drain a shield. Shields eventually ended up in a good spot, after being nerfed over the years, and are now a powerful-but-optional tool. They play a lesser role in cross-map artillery battles than they used to, but this is mostly due to terraform offering alternate ways to hunker down and the advent of the shield-overwhelming Odin bomber. Shields are stable, although throughout this post I have tried, and failed, to convince myself to revisit repulsion shields. Perhaps that is what modding is for, and there is surely an entirely new game to be made about bouncing projectiles around. As a final note, the Funnelweb shield does not behave like other shields, but details will have to wait for another post. This is the last Cold Take of 2025. We are taking a break over December and expect to return in January. Index of Cold Takes {STEAM_CLAN_IMAGE}/32557867/5a1865aa12a0bbedce11412412adc387007cebcb.png

This is a guest post by Aquanim, who led the 2016 sea rework. Over two thirds of our own planet is covered by oceans. Therefore, strategy games which are played on planetary landscapes have some reason to consider how to handle bodies of water. The simplest approach is to treat water bodies as an impassable barrier to land units and leave it at that. In games where units can interact with water, often this is reserved for a special class of ship-type units, but beyond this distinction “water” is just another terrain type. The physics-driven mechanics of Zero-K require us to give some deeper thought to how units ought to behave on and around water. This goes all the way down to fundamentals like “where is the water”, “where can units go”, “when can units see each other”, and “how do units fight each other”. We can dispose of the first point quickly: the sea level is defined by the engine to be altitude zero, so unfortunately we can’t have fancy waterfalls or scenic mountain lakes. {STEAM_CLAN_IMAGE}/32557867/e2f3eece41812150502315b7aea5c344aa7d4141.png On land, all units (which are not flying, jumping or thrown) are standing on the ground. That ground might be flat, precipitous or anything in between. In water, on the other hand, there are four places a unit might plausibly be:

• Hovering above the water surface
• On the water surface
• Floating beneath the surface
• On the seafloor

This is already getting rather complicated, so Zero-K immediately cuts down on this list by drawing no distinction between the first two states. The main consequence of this choice is that Hovercraft are vulnerable to torpedoes and similar weapons. Hovercrafts, surface ships, and surfaced amphbots behave similarly to units on land - with the significant difference that all water bodies are flat. This limits the potential range of unit interactions and map design, and gives an edge to direct-fire units like Lance since there is no terrain to hide behind. In principle, a submarine-type unit which floats underwater could move in three dimensions, ascending to the surface or descending to its depth limit. Again, that sounds rather complicated, and we do not want the player to be fighting a two-dimensional interface to unambiguously order three-dimensional movement. Therefore, we assume that submarines travel at a fixed depth beneath the surface, unless forced to surface in shallow water. At the time of writing this is the rarest mode of movement in Zero-K, shared only by the Seawolf and Scylla. A wider range of units (broadly termed amphibious) can walk on the seabed: Commanders, all of the Amphbots, a few utility units, and a couple of Striders. Depending on the size of the unit and the water depth, an amphibious unit may be partially above water. In fact, some amph units are capable of floating to the surface on their own. This enables their surface-only weapons to be used, but prevents further (voluntary) horizontal movement until they return to the sea floor. We tolerate this complication since a large variety of underwater-combat-only units would pose greater design problems, which we'll discuss a little later. In general these units want to float if and only if they are attacking, so the interface-battling is not too bad. All amphibious units are bots, not vehicles or spiders, so they can climb moderate slopes but not cliffs. Managing where units are allowed to travel underwater sounds rather annoying, so again we simplify the situation by avoiding the vehicle movement type and playing on maps without underwater cliffs. This is still the most troublesome of our three water-based movement types since water depth can have a significant effect on combat - in particular, it determines the time which an amphibious unit requires to float to the surface and start shooting back. {STEAM_CLAN_IMAGE}/32557867/2ec6ae3df71221386d883fc8455c229639621cda.png Verisimilitude demands that units under the water are more difficult to see than those on the surface. However, just like the ordinary fog-of-war mechanics deviate from `realistic’ line-of-sight for the purposes of gameplay, we simplify seeing underwater to a single mechanic, sonar. An enemy underwater unit is visible to us if and only if it is within the sonar radius of a friendly unit. To make things even simpler, in modern Zero-K all ‘sea units’ have sonar radius equal to their vision radius, while most other units do not (notably the Owl scout plane has limited sonar capability). Underwater units are still stealthier than surface units, since they don’t show up on long-range radar and cannot be detected by non-combat buildings like metal extractors. They are not as hidden as cloaked units, which seems reasonable since cloaked units are less common and normally pay a cost in terms of energy or immobility. As previously mentioned, units underwater cannot be cloaked, since the decloak radius mechanic would not play nicely with variable water depths. Besides the gameplay mechanics associated with vision, sea maps also pose a visual clarity problem to the player. Between the tint of the sea, surface ripples and reflections, units operating at several different depths, and typically less informative terrain textures, it is often more difficult to tell exactly what is going on underwater. This is part of the reason why underwater combat in Zero-K has few weapon types, and those that exist do not strongly reward quick reactions and micromanagement. {STEAM_CLAN_IMAGE}/32557867/ee33cb756a30d59fceb5b175500ff01f53af3c86.png A second constraint on the weapons which are usable by and against underwater units is that the game mechanics must remain reasonable for a fairly wide range of water depths. Imagine, for example, a surface unit with an unguided torpedo with similar mechanics to the Ronin’s missile, firing at a group of Ducks on the sea floor. In shallow water the path of the torpedo traces a straight line lengthways through the Ducks, and is likely to hit one. In deep water the torpedo will instead have only a brief window where it is at an appropriate depth to hit the Ducks before it impacts the ground. This all sounds rather messy, so we have given all underwater-capable weapons tracking or other projectile properties which avoid this discrepancy. From the perspective of balance rather than design, there is yet another constraint on underwater-capable weapons: if the longest-range conventional underwater-targeting weapon is itself attached to an underwater unit, then there is a lot of danger that these units will become dominant in the sea meta, since if they can be protected against swarms there is little else which can outscale them. Addressing this by expanding the surface-vs-underwater game with a wide range of units and capabilities is a superficially interesting idea, but has two big drawbacks. First, as we have already discussed, the potential variety in sensible underwater-capable weapons is rather limited. Second, while surface units can directly interact with land units and vice versa in interesting ways, it seems much more difficult to have land units and underwater units interact well. Therefore, in Zero-K we have gone in the direction of reducing underwater interactions to the minimum feasible set - of the units below strider class, only the light submarine and a few Amphbots can fight underwater, and all of their weapons have short ranges. The old Serpent long-range sniper submarine is one of the very few units to have been outright removed from Zero-K in the last decade (we’ll get to the second one later), and Scallop’s skirmisher-range torpedoes were reduced to riot range (though this was by no means the end of Scallop’s career as a game-warping balance headache…) Since very few land-based assets can interact with submerged units, it would be quite unfair for underwater units to engage land units freely without fear of retaliation. Therefore, the only unit with a weapon designed for underwater-to-land combat is the Scylla tactical missile submarine, which pays a metal cost for each missile and hence does not engage ‘freely’. {STEAM_CLAN_IMAGE}/32557867/898b2eb1c284d78058b9076931e737f4277d0cfb.png We conclude with a lightning round covering other interesting aspects of Zero-K’s sea design. Economy: The core principles of Zero-K’s economy remain the same on water maps, but there are some differences which alter the typical play patterns (adding some desirable variety). Arguably the most important is an indirect consequence of where units can move. The wrecks of destroyed units fall to the seafloor, where they are much less prone to being trampled or reduced by stray weapon fire. Therefore, metal reclaim is often a major factor in prolonged sea battles. Since wind generators perform poorly at sea level they are replaced with tidal generators, which combine the efficiency of wind generators with the reliability and robustness of solar collectors. Singularity Reactors cannot be built underwater, though one can terraform a land platform on which to place them. This is motivated by similar reasons as the decision to prevent cloaking of structures in general, and gives Fusion Reactors a point of difference. Factory balance: Across the land-based factories there is a (tenuous) principle that each factory should be similarly powerful and competitive with each other in a 1v1 on a suitable map. We don’t hold to the same rule in sea battles for two reasons. First, it would be boring to do the same thing twice. Second, since they are unable to travel on land, Ships have less freedom of movement than the hybrid Hover and Amph factories, which makes a difference even on maps which only have small islands. Therefore, our (tenuous) goal is for the Ship units to be a bit overtuned, but the Hover, Amphbot and air factories should still provide useful tools. Landships: Okay, I lied. Ships can go on land… sort of. Lobsters, air transports, or terraforming can put a ship on land, and while the ship can’t move around without assistance it can still fight. The Envoy and Shogun artillery ships make the best use of this, since their long range mitigates mobility problems and their ballistic weapons benefit from higher elevation. Transports: Unlike almost every other game with a dedicated class of “ship” units, Zero-K does not have a conventional transport for land units across bodies of water. The Surfboard used to fill this role, but it did not have much purpose when compared with the Djinn teleporter and Charon air transport, and was eventually consigned to the ship graveyard alongside the Serpent. Spicy water: Some maps replace water with acid, lava, or void. On these maps Zero-K behaves much more like the “water is an impassable barrier” games we mentioned at the start, although some acid is weak enough that units can survive in it for a while. These maps are not affected by most of the issues described in this post, but they do offer some novel tactical opportunities of their own… Come back in a few weeks for Cold Take #35, in which we will stop building a navy. Index of Cold Takes

Slow damage is the more prolific, yet less dramatic, cousin of EMP and disarm. It is weaker than EMP in that it never fully disables a unit, but the effect gradually ramps up from the very first instance of damage, making it useful in more situations. This gradual but persistent effect let us spread slow across more weapon types and roles, to the point it became a meme. But whereas EMP was inherited from pre-Complete Annihilation modding, slow was created from scratch, and upon reviewing the history it is somewhat surprising that it came to exist at all. Last time we covered the development of EMP, and how it became synonymous with lightning. But I did not mention that both stun and lightning were exclusive to Arm in Total Annihilation, and this focus was mostly carried through by TA modders. Complete Annihilation pushed faction differentiation hard, so when we merged lightning with stun, the smattering of Core stuns were moved to Arm. This gave Arm a monopoly on disabling status effects, which proved to be a bit too one-sided. Even though Core had a few more damaging options, such as a tacnuke missile to mirror the Arm tactical EMP missile, we eventually looked for a way to break the monopoly. {STEAM_CLAN_IMAGE}/32557867/18b0a002bf876372fbc1f40bc7bd9abcec803ccd.png Slow damage was the solution to the Arm monopoly on status effects: a new status effect just for Core. I recall MidKnight adding it as an alternative to moving the main Core stun unit, the Gnat-equivalent, to Arm. Gnat ultimately gained lightning and was transferred, but slow stuck around. Numerous Core units gained slow damage over the years, until the mechanic found its home as a core aspect of the Amphbot factory. This factory was added after we merged the factions, yet in many ways maintains the old Core aesthetic of raw power and toughness. The underlying mechanics of slow damage have been quite stable over the last 16 years. Slow damage accumulates on units and is shown on a bar under their main health bar, the same as EMP. Units with slow damage are slowed immediately by an amount equal to the accumulated slow damage as a fraction of current health. For example, a unit with 1000 health and 150 slow damage is slowed by 15%. Slow damage is capped at 50% of current health (with a few exceptions) and decays over time at a rate of 4% per second, although decay is halted for half a second after taking slow damage. Some slow weapons (Moderator, Limpet, and Disco Rave Party) can push units to 58% slow damage, but still only slow them by 50%. Slow decays at 4% per second, so this corresponds to two extra seconds at full slow. But this is not the only way to extend a lingering slow, since regular damage reduces health, which increases slow as a fraction of current health. This interaction between status effect percentage and current health was a huge problem for EMP, but slow decays so quickly that it rarely matters. {STEAM_CLAN_IMAGE}/32557867/8ed1224e9280e93e1b3e666377e610f11a693cab.png Slow has driven and benefited from the development of increasingly powerful gadgetry. There is no stated limit on what can be slowed, so we have gradually expanded its scope by making more and more things slowable. Almost everything is covered at this point, including movement speeds, reload times, and economic rates, with the main exception being jump speed. This is great for modding, and shows off the power of the engine, since slow would be harder to implement in an engine that updated less than 30 times a second. The high tick rate lets us treat time as continuous without too many issues, even though actions only happen every 33 milliseconds. There are some caveats to be aware of when slowing rapid-fire weapons. For example, the Light Laser Tower seems to shoot a continuous laser, but it actually fires a 0.1 second burst every 0.1 seconds. This corresponds to one shot per 3 frames, which increases to one shot per 6 frames when slowed by 50%, as expected. However, when slowed by 45%, it shoots once every 4 frames, for 40% reduction in damage output instead of 45%. This barely matters for how Zero-K uses slow, but would matter for a mod that, say, implements global fire rate upgrades and expects the increase in damage output to be absolutely consistent across units. {STEAM_CLAN_IMAGE}/32557867/9b5d3426e758ee14f6bc505ad21c9511b3e83d8a.png The first recipients of slow damage were Outlaw and Moderator. The Outlaw used to be a standard riot armed with a Bandit blaster in one hand and a Ripper gun (then Leveler) in the other, which is where we get the phrase "Leveler sidearm". It gained the disruptor pulse while the rest of Core T1 bots were undergoing a shield makeover, since friendly-fire-less area of effect damage works great in a shield ball. The disruptor pulse is unique in that it does not damage allied units, and was conceptualised as some sort of control system attack. Moderator gained slow because the old Moderator was too generic. This left it prone to being monospammed, and it was hemmed in by similar units on all sides. Imagine a long-range skirmisher like Rogue, with a Sling-like plasma cannon, and the weight of a Recluse. Range is particularly hard to balance in RTS, especially for units that can fire while moving, so in Zero-K it comes with severe drawbacks; Recluse and Sling are flimsy, Bulkhead and Fencer deploy to fire, and Rogue has a very slow projectile. The design space around Moderator was too full or troublesome to find it a healthy place, so we gave it slow. {STEAM_CLAN_IMAGE}/32557867/f23d0fcbdb92f7e365cacadfee6fd8268bcfc5a6.png A few units gained slow for similar reasons to Moderator, to the point that "give it slow" became a meme. This was done to units that were underwhelming or lacking a distinct role. The skirmisher gunship Harpy was in an awkward spot between the faster Locust and tougher Revenant, while Dart lacked a clear purpose within Rover. Cyclops used to have a flamethrower sidearm, but this made it hard to counter with swarms, so it was switched out for a slow beam to give it utility over Minotaur. Seawolf gained a slowing torpedo as part of a sea rework. Slow damage was also a popular choice for brand new units. The Amphbot factory was created after factories replaced factions, so it could have contained anything, but we decided to make slow one of its main mechanics. To some extent, Buoy deals slow damage because little room remained for an ordinary skirmisher of its class, and Limpet explodes with slow damage because the other bomb types were taken. But we had better reasons to give the factory slow. Part of the plan was to make a particularly slow moving factory which could use slow damage to bring the enemy down to its own speed. The idea behind the large disruptor pulse of the Limpet was to let it reach the surface of the water from the ocean floor. The strongest reason for Buoy to deal slow damage is that slow is good against heavy units, and ships tend to be heavy. Heavy units are weak to slow because they tend to live longer, which gives the effect more time to have an impact. Slow also makes it harder to retreat for repairs, which is a big part of using heavy units. Bolas, the disruptor beam hovercraft raider, was added to Hovercraft for a similar reason, although admittedly it also deals slow because no other proper raider does so. {STEAM_CLAN_IMAGE}/32557867/474a866b430e17a47527d9677818418fdc6babc5.png We avoided adding too much slow, but it has still accumulated over the years without really considering what it is in the game world. Is it time dilation, or perhaps a virus, as implied by Outlaw? Are units being mechanically gummed up by some sort of purple goo? Slow damage is dealt by various types of missile, beam and arcing projectile, with the only unifying characteristic being the colour purple. Compared to the consistency of lightning and EMP it is a bit of a mess. This may be a minor problem, but systems generally feel better when presented in a consistent way. Of the twelve sources of slow damage, only one, the tactical missile, deals pure slow. This is not for want of trying, since the original slow Moderator was a slow-only unit. However, we failed to find a place for it where it was not either too niche, or too obnoxious. Part of this issue is that status effect-only weapons risk cluttering the screen and soundscape without progressing the game. Racketeer, the disarming artillery, suffers from this exact issue, but the greater utility of disarm over slow lets it feel powerful without spamming projectiles. Pure status effects also give units more ways to be stupid, since spreading the effect around becomes more central to the usefulness of the unit. {STEAM_CLAN_IMAGE}/32557867/162969180044f5fc10b9a20d0e87f95fc29c1357.png These days most slow damage weapons deal slow as a bonus, rather than as their primary purpose. Outlaw, Moderator, Buoy and Constable would be much worse without slow, but with a corresponding cost decrease, would probably still find use. It would be interesting to experiment with more pure slow, but for now, slow provides a much-needed counters for heavy units and mitigates a bit of damage. The more dedicated sources of slow, such as those with large area of effect, are fairly niche, but this is probably preferable to permanently playing the game at half speed. Index of Cold Takes

This update has tweaks and fixes for the update from two weeks ago. Detriment now responds to status effects while winding up its jump, and being transported cancels the jump entirely. Racketeer is also better at keeping large units disabled.

Tweaks

Status effects and transportation interact with the jump windup of Jugglenaut and Detriment.

• Stun and disarm pause windup progress. Jump cannot be cancelled or re-targeted this way.
• Slow makes the windup take longer.
• Picking up a winding up unit in a transport cancels the jump and wastes the reload.

Racketeer overkill prevention works better against Detriment and Paladin. Previously its goal was just to keep units above the threshold, which worked fine for most units since one shot is enough to fully disarm a disarmed unit of 16,000 health. But for huge units it would end up hovering around 1s of disarm, which sometimes dropped below the threshold. Now Racketeer tries to keep even the largest units closer to its full disarm timer.

Fixes

• Opening the menu no longer pauses games that started with more than one player.
• Fixed Cerberus not firing when built at exactly the wrong elevation.
• Fixed planet Harsar Lief (Shipyard unlock).
• Fixed metal extractor tooltip bug on metal maps.
• Fixed reset hotkeys button bug on pages with multiple default hotkeys.
• Fixed build ETA and overhead icon height to match healthbar offset height.
• Fixed missing stockpile command texture in the command menu.

Strategy games present players with an evolving set of problems and a selection of tools with which to solve them. The problems in RTS tend to boil down to the fact that the enemy has units, so a lot of the tools offer ways to damage and destroy units. But using the same type of tool over and over can feel repetitive, so many games also give players ways to weaken enemy units without killing them. These non-lethal tools are known as status effects, or debuffs, and they add variety by letting players weave non-destructive actions into their battle plans. Some games do without status effects, but the goals of Zero-K demand a large toolbox, so ignoring status effects was not an option. The first status effect, known as either paralysis or stun, was present in our earlier ancestor, Total Annihilation, although it made little use of it. In fact TA had two sources of stun: the Spider and a global-range EMP missile. The Spider could disable a single target by continually firing at it, while the EMP missile disabled Core units in an area. This faction specificity was due to Core being a faction of robots, while Arm units are piloted, which made them immune to EMP. Core struck back though with the Arm-killing Neutron missile. {STEAM_CLAN_IMAGE}/32557867/951834528d9ec95c79a32a58ec1fb29a9f2d0331.png Modders went to town on TA and added a few more stun units - but haphazardly. I suspect paralysis was a niche mechanic since TA barely told players how the mechanic worked, it did not even indicate whether a unit was stunned or not. Spring (the engine behind Zero-K) did a lot better in this regard, but there was still not much more by the time Complete Annihilation entered the scene. Arm had gained a few EMP death explosions and some stun sidearms, while Core had a Gnat-like cheap stun drone. The faction-specific effect of the EMP and Neutron missiles were also removed at some point. From here we expanded the arsenal and fixed issues with the underlying systems. One of the early goals of Complete Annihilation was to overhaul the weapon visuals, and part of this involved consistency between the visuals and the underlying mechanics. This means that dissimilar weapons should look different, and also that similar weapons should avoid implying a mechanical difference by arbitrarily varying their visuals. This was bad news for the plain-looking paralysis lasers, but the new idea also highlighted the fancy lightning weapons as a problem, since they were little more than pulse lasers mechanically. These problems solved each other when we gave all lightning weapons the ability to stun and reskinned the existing stun effects to shoot lightning. Giving EMP damage a unique weapon type was a start, but we also had to balance EMP around the removal of armour classes. Several units were resistant or immune to EMP damage, including commanders, units that deal EMP damage, and striders. Strider EMP immunity was perhaps the most egregious, since disabling a single huge unit is a great application of EMP. Players should be rewarded for playing around their tools to come up with something powerful, not butt up against arbitrary constraints. Most things can be balanced around, so removing something for being "too OP" is a last resort, as hidden restrictions punish unaware players and make them distrust the tools the game gave them in the process. {STEAM_CLAN_IMAGE}/32557867/6b3a372d698e55fc10914ad7dfbf5b62898fbc5f.png Lightning weapons stun units by dealing EMP damage that accumulates on their target. This alternate damage type sits alongside health and is displayed under the main health bar. A unit becomes stunned when the EMP damage it has taken exceeds its current health. Being stunned completely disables the unit, but the effect is temporary since EMP damage decays over time. The decay rate is Health/40 per second, which is why it takes 40 seconds for a unit to drop from 100% EMP to 0%. Fractions of current health are unwieldy though, so it is time to stun some Jacks. A Jack has 6000 health, which means it heals 150 EMP damage per second. A Jack with 6600 EMP damage takes four seconds to decay down to 6000, so 6600 EMP damage corresponds to four seconds of stun. Note that most of the EMP damage required to stun a unit is spent reaching the stun threashold, with only a small amount needed to push the stun duration higher. If EMP damage could rise indefinitely then most units would end up with very long stuns, which is why each weapon has a limit on how much EMP damage it can deal over the health of its target, called the stun timer. Knight has a stun timer of 1 second, so cannot send a full health Jack beyond 6150 EMP damage. In fact, Knights cannot deal EMP damage to anything on full health, simply because they deal both regular and EMP damage, and the regular damage is applied first. The old lightning weapons retained some of their regular damage when they gained EMP. The difference is shown by colour, with blue lightning dealing both damage types, while yellow lightning is pure EMP. Venom, the descendant of the TA spider tank, eventually gained a small amount of regular damage, so has some blue lightning mixed in. The order in which the damages are applied is important due to the interaction between EMP and health. {STEAM_CLAN_IMAGE}/32557867/908da11861813f9d380850ed40f34f015807c0bf.png The inbuilt EMP systems offered by Spring have issues. The default stun threshold is based on maximum health, not current health. This works fine, but making EMP and regular damage completely independent wastes the potential of the system. There is a sweet spot where the disparate systems of a game exist in a loose web of interaction, not so tightly bound that the synergies become obvious, but just enough for people to find creative combinations. So in 2009 the CA developer SirMaverick added a way to use current health as the stun threshold. Using current health as the stun threshold works well until you consider what happens when stunned units lose health. Say we have a healthy Jack on 6600 EMP damage, which corresponds to a four second stun. Then some Glaives come in to kill the Jack before it recovered, but they need not worry, since damaging the Jack would cause it to be stunned for longer. Indeed, if the Jack goes down to 4500 health in those four seconds, then it would still have at least 6000 EMP damage, giving it a stun of at least 13 seconds. This was a problem: we wanted some synergy between EMP and regular damage, not for EMP to become redundant after the first shot. The escalating stun duration problem was solved by scaling EMP damage to changes in health. Consider a full health Jack with a four second stun. If the Jack suddenly dropped to 4500 health, then its EMP damage would be rescaled from 6600 to 4950. Stun decays at 112.5 per second at 4500, so the Jack retains its four second stun. This is why mixed regular and EMP damage weapons deal their regular damage first: to avoid instantly scaling down their EMP damage. The result is a nice push-your-luck interaction between EMP and regular damage. Do you spend your stun at the start of the battle to gain an early advantage, or risk waiting for some damage to be dealt first to go for a longer stun? {STEAM_CLAN_IMAGE}/32557867/98ab1f18bb7d0af3ff1096b3378f6847f3c36fc2.png Technically Zero-K uses maximum health as the stun threshold and applies a multiplier to incoming EMP damage, but the result is mathematically equivalent, and a shifting threshold is easier to think about than a dynamic multiplier. I only realised this after writing a gadget to re-implement EMP damage from scratch, but the work was not wasted since the gadget was later used to implement disarm. This was a new status effect that worked like EMP, except it allowed units to move and self-destruct. Disarm was added in 2013 after the switch to one faction loosened the Arm monopoly on lightning. The intent was to create a weaker version of stun for use in cases where a full stun was too powerful. It was initially used by Thunderbird and Racketeer to prevent them being otherwise nerfed into the ground. Disarm allows movement because we specifically wanted to nerf these two units against mobile targets, and movement is ubiquitous enough for disarm to be meaningfully distinct from EMP. Disarm also allows units to self-destruct, which requires a more complex explanation. Consider a version of disarm that disallows self-destruction, and imagine a crawling bomb under its effect. To deal damage, this bomb needs to run into the middle of the enemy force and collide with a fatal projectile, supplied either by the enemy or a nearby ally. This is fiddly, but it is even worse for the other side. Units would rather not explode, all else being equal, so need to avoid shooting at the bomb. However, if there is something even more valuable deeper in the army, then the bomb should be shot to protect it. Whether to shoot at a disarmed bomb can be a strategically important decision, but its implementation involves rapidly flicking state toggles or clicking on small, fast, units. This would entail a terrible fight with the UI, so we removed the choice by letting bombs blow themselves up. Now destroying a bomb only ever deprives it of options, so killing one is hardly counterproductive. This extra allowance is only required for disarmed bombs, since stunned bombs are much easier to avoid. {STEAM_CLAN_IMAGE}/32557867/b3d324b7f755c2cf0bdfe5e1ebd1a607a8111ea9.png Disarm fleshes out our roster of status effects but risks being redundant with EMP damage. This is always a risk for self-reinforcing mechanics when investment in one trades off against investment in the other. To solve this we made the two damage types interact by having disarm damage "float" on top of EMP damage. With this system, a unit is disarmed if the sum of its EMP and disarm damage exceeds its health. So a Jack with 4000 EMP and 2600 disarm damage would be disarmed for four seconds. Disarm also only decays when no EMP is present. Technically this system is equivalent to giving disarm to all sources of EMP damage, and making the two damage types independent otherwise. The disarm and EMP weapons of Zero-K can be sorted into two types: one-shot abilities and sustained fire. The former include exploding bombs, one-shot missiles, and the lightning bomb, and last anywhere from 16 to 45 seconds. These are used to disable antinukes and to kick off short games of protect the stunned unit. I quite like how stunning something expensive creates a mini-game around a temporary objective, with the outcome determining whether the metal spent to stun the unit pays off. Some one-shot stuns can be reused, but with a long cooldown, and the units that wield such stuns often take fatal risks to apply them. {STEAM_CLAN_IMAGE}/32557867/642a96bc290bfd786c2ca5d21cea98a0454933fa.png Sustained fire stuns and disarms are wielded by more ordinary units, and often deal regular damage as well. These stuns last for one or two seconds so tend to act more as hindrances than full disables. Focusing fire for a full disable is often possible, but at the cost of taking more damage from other sources. The low stun time and high reload time of sustained fire weapons means that locking down a target depends on avoiding overlapping stuns. Consider three Knights with a 1s stun timer and 2.2s reload time. If one of them fires every 0.73s, then the target will be stunned forever. However, if they all fire at once, it will enjoy 1.2s of freedom every reload cycle. The latter situation feels like fighting the UI, since it would not take much for the Knights to pause momentarily to stagger their shots. Wasting stun time is a longstanding unit AI issue. Overkill prevention does a great job for Racketeer, but we only just started experimenting with more general solutions in the 1.13.9.0 update released just last week. Instead of adding more unit AI, the current approach is to design the stupidity out of the system by reducing the cost of overlapping stuns. The new mechanic, called overstun, allows units to deal slightly more damage than their stun timer would allow, but only if the target is already close to the stun timer. For example, Knight has a one second stun and one second of overstun, so it can add a full second of stun to anything with at most a second of stun duration. For example, a Knight shooting at a 6100 EMP damage Jack would be able to push the Jack to 6250 EMP damage. This is a buff to sustained fire stun weapons, but should take us to a better place than balancing around the stupidity or trying to resolve it with unit AI. {STEAM_CLAN_IMAGE}/32557867/1df60748842bfa6951ae409ad29018902efc8076.png Full stuns run the risk of frustrating players by removing control of their units. This is mitigated by making most stuns brief, precise, or partial. Slow damage plays a part in reducing the lockdown load of our status effects because it can never fully disable a unit. In fact, there are 12 sources of slow damage, not including commanders, compared to 11 sources of EMP and 4 sources of disarm. However, an exploration of slow will have to wait as this post is already bursting at the seams. I only just managed to squeeze in disarm because it works the same way as EMP. Slow damage is like EMP damage, except different in almost every way. Index of Cold Takes

This update is packed with unusual buffs. For starters, Detriment can now jump three times in a row, but every factory technically has some unit that was buffed. Most of the buffs are via a change to the stun and disarm system that will help units avoid wasting the duration of stacked stuns. We have even increased the starting resources slightly, and added more of an incentive for teammates to capture metal spots. There are also many features, such as greatly improved Zenith meteors and better looking Jugglenaut jump. The interface has a few improvements that make morph commands and burst damages easier to handle, and a few terraform edge cases were fixed. There was also an engine update last week to test the engine as it inches towards a stable release.

Overstun

Weapons that stun or disarm now do so for an extra second when the target is already almost fully stunned. This helps low stun duration units avoid overlapping their stuns. Consider the following situation:

• A Knight fires, dealing enough damage to reach its maximum stun of 1s.
• A second Knight fires 0.3s later, when the stun is at 0.7s remaining.
• Previously, the second Knight would reach the same maximum stun of 1s, wasting 0.7s
• With this change, the second Knight is allowed to go 1s beyond the current stun on the unit, so the enemy ends up with a 1.7s stun.

The goal here is to design away stupidity (Cold Take #10). An alternative to overstun would be to add unit AI that lets the second Knight delay its shot to waste less stun time, then alternate shots from there. This AI would have tricky edge cases, make units feel unresponsive, and sometimes work against player intentions, so we are trying a mechanical approach instead.

Balance

Added one second of overstun to all sources of EMP and Disarm damage. This will be felt most by spammy units with low stun duration: Venom, Blitz, Knight, Scorpion, Cutter, Gnat, Thunderbird and Faraday. Increased starting metal and energy from 325 to 350. Detriment can now store jump charges and is a bit cheaper, at the cost of health and jump range.

• Cost 24k -> 21k
• Health 86k -> 76k
• Jump reload 120s -> 100s
• Jump charges 1 -> 3
• Jump range 960 -> 840 elmos

Paladin is slightly harder to repair.

• Health regeneration 20 -> 10 health/s

Knight deals more EMP damage as well as benefiting from overstun.

• EMP damage 600 -> 720

Pyro jumps faster.

• Jump speed 180 -> 198 elmo/s

Placeholder synergises better with slow projectiles.

• Wiggly Black Hole -> Not So Wiggly Black Hole

Conch is even tougher.

• Health 850 -> 1000

Bolas sonar now works properly.

• Sonar range matches sight range, like all sea units.

Scalpel is more manoeuvrable.

• Speed 63 -> 66 elmo/s
• Turn rate improved by 2.5%

Crasher is more responsive.

• Speed 111 -> 114 elmo/s
• Missile speed 700 -> 800 elmo/s
• Fixed overly trigger-happy overkill prevention.

Raven is faster and needs to turn faster to compensate.

• Speed 234 -> 246 elmo/s
• Improved rudder by 3.8%

Phoenix is slower, effectively swapping its speed with Raven, then overshooting.

• Speed 243 -> 231 elmo/s

Nimbus is more dangerous.

• Damage per shot 19.3 -> 20

Desolator is slightly more buildable.

• Cost 1600 -> 1500
• Reload time 3 -> 2.8
• Damage 1201 -> 1200

Fusion Reactor is thinner to prevent units hiding in it.

• Flattened hit volume by 12.5% along its short axis.

{STEAM_CLAN_IMAGE}/32557867/e39efe39a82839b00849e8da2bacac320d9c1376.png

Features

Metal Extractors now preferentially return 125 extra metal to their creator, up from 51. Remember, this metal is shared between the players (Cold Take #20) that helped build the extractor. It is notable that metal extractors only cost 85 metal, but rewarding teammates for grabbing metal extractors quickly seems worth the expense. Detriment jump charges are visible in the canisters on its back (thanks garfild888 for the model support). This lets the enemy see whether a Detriment can jump, and this information is important enough to put on the UI. Enemy Detriment jump change is visible on the unit icon in the mouseover tooltip, and a jump bar can be enabled under Settings/Interface/Healthbars. A visible bar by default was felt to be a bit too noisy. Other features:

• Significantly improved the visuals and effect efficiency of Zenith meteors (thanks Thorneel).
• Improved Jugglenaut jump animation.
• Cancel Morph commands are now drawn with a stop image on top. This the command panel show the morph state of selected units. Technically Morph and Cancel Morph were always distinct commands, but at some point the visual difference was lost.
• Burst damages for many more units are now shown by the aggregate unit stats (next to the minimap). This includes Scythe, Merlin, Detriment, and most assault units.

{STEAM_CLAN_IMAGE}/32557867/4a79d434118b2a51679cd23a2d719351c1d888df.png

Fixes

• Fixed the spinny thing on the Geothermal Generator (thanks garfild888).
• Fixed large jumping units sometimes walking in place after jumping.
• Dead Claws (Badger mines) no longer sometimes leave a radar dot for a few seconds.
• Fixed Advanced Geothermal morph sometimes interacting weirdly with ongoing terraform.
• Fixed much rarer edge cases of the above that could occur with any structure.
• Fixed terraform build points sometimes being visible to the enemy.
• Fixed the accidental removal of the parallel missile burst reload indicator on the health bar (eg the "2/3" for units such as Picket, Ogre, Trident).
• Fixed incorrect descriptions for overkill prevention in the Unit Behaviour menu.
• Fixed the missing ~ in front of unreliable burst on the aggregate unit stats.
• Fixed the crazy numbers in the EMP award. Eg hitting a unit at 5% health would be worth 20x the damage.
• Moved some sounds that were erroneously on the ambient channel to the battle channel.
• Fix Hercules script error when modded with extra weapons.
• Fixed hotkey labels disappearing from the command menu after viewing unconstructable units (eg if a ship factory ends up on dry land).
• Fix an Antinuke UI crash.
• Fix ingame menu crash with Turkish locale.

I am a huge fan of terrain manipulation, even in real time strategy games. At its best, terraform is a supercharged form of map modification which belongs to nobody when built, allowing both sides to adapt to the new terrain. A wall to shelter from artillery might be a great idea for the moment, but it becomes a liability when the enemy uses its shadow to send spiders swarming over the top. The creative problem solving and strategising encouraged by terraform are perfect for Zero-K, and as a result the construction of walls, ditches and ramps has become a core part of the game. Reaching this point took over a decade though since terraform is fraught with issues. When I try to be unbiased about it, terraform in RTS tends to suck. A number of games experimented with it in the 90s, and it mostly served as a barely functional gimmick. Base building is already enough to let players stamp their presence on the map, and base building is a much safer prospect than full free terraform. To start with, the shape of the terrain has to actually matter for modifying it to be important. Few games satisfy this requirement, and with good reason, because making the terrain matter too much is a far greater risk. Too much detail is overwhelming, and the ability to manipulate that detail exacerbates the problem. {STEAM_CLAN_IMAGE}/32557867/d0d8d2dda791d4106c6d24f03f663d9602ba5b4e.png Freely manipulating the terrain is a UI nightmare. Drawing 3D shapes on a 2D screen is not easy, and players tend to jump right in with no preparation. This, plus the immense number of manipulations available, can easily result in a fiddly UI. The inherent freedom of terraform is also at great risk of being used in boring ways. A fortress complete with crenellations and moat might look cool, but it is surely cheaper to scatter thin spikes all over the battlefield to utterly confuse enemy pathfinding. Singleplayer and slower paced games have an easier time, as players are willing to learn more complex UIs, and there are no opponents to call foul on cheap tricks. But for a multiplayer RTS, terraform is at great risk of being unfun to use and even less fun to play against. The issues above are solvable, but we only did so after years of iteration. The very first terraform replaced the Dragon's Tooth with a buildable block of terrain, and it dates back to 2008 - the height of Complete Annihilation. The Dragon's Tooth was a wall section that worked by turning into a crush-resistant wreck when built, and the new system worked the same way except with terrain modification. There were two block types, to raise or lower terrain, and both had a 2x2 footprint, which is the smallest footprint in the game. Building a wall involved dragging a line of blocks, and building a tall wall required players to place blocks on previously built blocks. This is where things started to get fiddly. {STEAM_CLAN_IMAGE}/32557867/1385b9bb5a232038b963db1f6717cc3f9e0c8331.png The terraform gadget was probably added on a whim, as was the norm, although in this case it happened to be added by the lead developer, Quantum. The terraform block was an unusually conservative feature, but this was soon remedied by his next addition: the jankiest form of level terraform imaginable. Quantum made a new type of block, still with a 2x2 footprint, but which levelled something like an 8x8 area around itself when built. The new height was based on the centre of the block, so it was usually used in conjunction with a deep hole or tall spire. This was very powerful, and personally very fun, but also very broken. The modern limitations that allow for sustainable terraform fun were yet to come. At this point terraform was free in the sense that it only cost worker time. It could also move structures, so the standard play was to build something like a Singularity Reactor, dig a deep hole with trench blocks, then make level terraform at the bottom, moving the structure deep underground. The process was even repeatable, which let Antinukes dodge up and down in response to threats. This was not as common as you might expect though, as busted terraform was not even the roughest part of Complete Annihilation. Why terraform your nukes when you can just cloak them? {STEAM_CLAN_IMAGE}/32557867/20bbeed471376c0181cc3b777b51b4a7999d36e4.png I was a big supporter of terraform and wanted more, so I added a block that created a small ramp, much like the level block. The ramp was enough to inspire the first Pyro launcher, on the North side of Victoria Crater if I recall correctly, but it was far too limited, being fixed at 45 degrees and only able to point in cardinal directions. So by late 2009 I decided to rewrite terraform from scratch. The goal was to make proper versatile ramps, fix the fiddliness of wall creation, and to add lasso UI as a more sensible form of the level block. The bones of the rewrite survive to this day and, unfortunately, so does most of the old code. The system endures due to a strict division of labour. The first half of the terraform system is packed with command modes and rules about what terraform is allowed to do. The player has access to ramp, level, raise, smooth, and restore commands, and these commands are modifiable and limited in certain ways. The entire purpose of the first half of the system is to specify generic terraform segments, which are just lists of "move position (X,Z) to height Y". The second half of the system then handles the creation and progress of these segments, without any knowledge about where each segment came from. So behind the scenes, all terraform types are built and priced the same way. The new system served as a good foundation, but there were still many problems to solve. Some were solved by the choice to match the resolution and implied limitations of the 2x2 block system, which cut out a chunk of excess freedom. The remaining issues came in three flavours, although the solutions often attacked all three at once. The issues were:

• Units being stupid, especially about targeting.
• Encouraging interesting uses over uninteresting ones.
• Nobody will bother with terraform if the UI is terrible.

{STEAM_CLAN_IMAGE}/32557867/f071b4b106f79dbbd70a6cf38c1eff17d22cc11a.png One of the first tweaks was the addition of the Shraka pyramid, named after the player who suggested it after I put a Razorback (a Dante-sized Reaver) on a very tall spire during a FFA on Desert Triad. Tall terraform was too powerful for its cost, and my extreme application amounted to going to space. One potential fix was to make terraform more expensive further it reaches from the original map, but this reference to old terrain felt too arbitrary and opaque. Instead, we added the requirement that terraform shore itself up by constructing a sort of skirt around itself. The extra dirt costs resources, which naturally makes tall terraform more expensive, as well as take up more space. The limited slope was also great for unit AIs that did not take kindly to being asked to aim directly up or down. Plus, the sheer cliffs suffered from extreme texture stretching, and tended to make spiders freak out. The Shraka pyramid ruined the prospect of computing a precise cost estimate, but that drawback pales in comparison to all the issues it solved. There were other unit AI issues, and some surely remain today, but they are often solved by aim position tweaks so that, for example, units can return fire against walled defenses. Resolving these issues also has the neat side effect of jank-proofing maps, since if units can handle adversarial player-driven terraform, then they should be able to handle anything a reasonable mapper might throw at them. {STEAM_CLAN_IMAGE}/32557867/b1a2aac2e3779a96f5dc2a5b6fb54726f7a944b0.png Buffing fun terraform and nerfing degenerate uses has mostly been a matter of cost. The first cost adjustment was quite easy: if terraform is going to be easy to use and powerful enough to bother with, then it should cost metal and energy to reflect that, and the rest of the design demands that these costs be in equal ratio. But from there it quickly degraded into formulas that resist anything more than a vibe-based understanding. It would be nice if terraform cost was directly related to the volume displaced, but this is one of the least viable approaches. Ruining the map is inherently easier than opening it up, which is bad news for anything with fewer than four legs. Vehicles suffer the most, so the terraform cost formula contains hefty penalties for terraform that specifically targets them. We want to see strategically placed walls and ramps that open up the map, not cheap fields of impassable tank traps. The protection of vehicles focuses on one particularly harmful case: the knee-high vehicle-blocking wall. Such a wall is high on perimeter and low on volume, so terraform is penalised for having a large perimeter. There used to be an area cost penalty too, but thankfully it was removed for being redundant. {STEAM_CLAN_IMAGE}/32557867/a8ed8f6162d64ab8937285ea88d4165a35dad084.png Behind the scenes, the map terrain consists of a grid of points, each spaced 8 elmos apart (where elmo is the elementary unit of distance). The smallest terraform block is 32x32 elmos (2x2 in footprint units), which corresponds to 25 individual points. This 5x5 grid of points has four corners, twelve points along edges, and nine internal points. So if we want to raise such a block by 100 elmos, that will cost:

• 25 x 0.0064 x 100 = 16 metal for the volume cost of each of the points.
• 12 x 0.75 = 9 metal for the twelve edge points.
• 4 x 1.05 = 4.2 metal for the four corner points.
• A base cost of 6 metal.

For a total of 35.2 metal, plus whatever pyramid is created during construction, paid for at the volume rate of 0.0064 metal per elmo. For a 100-elmo high block the pyramid would cost 24.6 metal on flat ground, but if cliffs are involved, then all bets are off. {STEAM_CLAN_IMAGE}/32557867/0c8097b94d112be33540af645f114a7e2f01f798.png The terraform cost calculation is a bit complicated, but it does the job. Take a look at the image above, each wall costs 250 metal, yet the flattest one has by far the least volume, and 250 metal is comparable to covering the same distance with turrets. The cost factors of 0.75 and 1.05 for edges and corners are not static either, but are reduced for points on the edge that modify the terrain by less than 10 elmos. This buffs terraform that sits flush with existing terrain, which mostly means smooth and restore. The perimeter cost is reduced below changes of 10 elmos because this is the height required to block vehicles. The vehicle-blocking threshold has actually changed a few times, which is surprising for a game that can run maps from two decades ago and still play as the mapper intended. The first threshold change was the result of fixing some edge cases in pathfinding. Commanders could walk up chest-high walls back in 2009, while vehicles could phase up cliffs that modern bots struggle with. This was only a problem for sudden terrain changes; smooth ramps were fine. This was solved by engine developer and lua wizard jK, who incidentally also let units walk along the top of terraformed walls. The added consistency was great, but it meant a cliff as low as 6 elmos could block vehicles. The vehicle blocking threshold was increased to 10 as part of a larger change to the Shraka pyramid. The original pyramid was not great at letting units shoot into holes, especially long flat vehicles like the Scorcher and Dagger. This became a problem as UI improvements increased the popularity of burying mexes, which made it very tough for vehicles to raid effectively. The solution was to add a sort of flange, or reduced slope, around the outermost edge of the pyramid. Vehicles could mount this slope to peer into the hole and shoot at whatever is inside, and as a side effect, they could climb higher terraformed walls. A flange was also added to the inside edge of trench-type terraform to give attackers a better angle of fire. Not only did this make it easier to shoot at mexes in holes, but it also gave defenders more space to shoot at Sky Jacks. {STEAM_CLAN_IMAGE}/32557867/39e1a91b66ed4b49caa43e0ff2a36a4c74ecc45f.png Terraform could not be improved without improving the UI. Not only does the UI have to be good for the feature to be good, but terraform was only tested and abused once the UI was good enough for it to be worth the effort. By now we have hotkeys and presets for all kinds of terraform. Alt+Mouse Wheel lets structures be placed at any height and they can even be queued on currently unsuitable terrain. The height selection UI is a bit fiddly, so the Alt+V/B/N/M/H presets create terraform of a variety of convenient heights, with the first two blocking vehicles and bots respectively. Alt+J digs a hole while Alt+G matches the height of wherever you first click. The default behaviour of the ramp UI has been through a few reworks, and there is even an area mex mode that buries or walls mexes. Constant playtesting was vital to the development of terraform. Players need time to adapt to UI improvements and explore the possibilities they open up, which fed back into the mechanics and drove further UI improvements. Mechanics were changed in response to unfun discoveries, while UI changes were built to support fun ones. We also support the powerful and unavoidable uses, even if they are not fun, because terraform should not involve fighting the UI. The required years of iteration might be why RTS mostly gave up on terraform. A designer with only a few years of mostly closed development is at a significant disadvantage. The design work is only half the story, as terraform would not even be possible without a lot of work on the engine side. Map deformation itself is no easy feat, since units have to update their pathfinding data to navigate any new terrain, so it is impressive that the paths update fast enough to take large-scale terraform into account. Another amazing project is kloot's vision-restricted heightmap, which means that you have to actually scout the enemy base to see their changes to the map. Terraform would still be possible without this, but it would always feel bad to globally reveal your Antinuke when you put them in a hole or behind a wall. He also added the ability to modify the map texture which, in conjunction with jK's slope fix, made it possible to texture terraform based on what can walk there. {STEAM_CLAN_IMAGE}/32557867/cbcb144eb83f15b2b947968a15de887b5d41d627.png By now the terraform system is rock solid and I have yet to see any game do better, at least under the constraints of fast-paced competitive fairness. Populous: The Beginning might come close, but it is a very different game, although it did inspire the Zero-K ramp. The last major tweaks were in 2020 with the addition of pyramid flanges and the prohibition of terraforming near enemy units. The enemy terraform prohibition is interesting in that it took so long to become necessary. There used to be a game of reverse whack-a-mole, with Caretakers or swarms of constructors trying to trap encroaching tanks. This was partially addressed by giving terraform a high base cost, but not fully, so we bit the bullet and added the somewhat arbitrary restriction on terraform with enemies nearby. For all my misgivings, blocking terraform with enemies nearby turned out great. It ended up reinforcing my favourite part of terraform: that nobody owns it. Previously a defender had plenty of time to tear down a wall once it became a liability, but now that is impossible if the enemy is already in your midst. Players have to plan out and commit to terraform before the battle, which gives your opponent time to consider how to exploit it to their advantage. It is simply amazing that Zero-K players regularly spend resources on something that they fundamentally do not own, and that may even be turned against them in the future. These kinds of choices are a real test of strategic thinking, which is why it's such a shame that so few games experiment with terraform, or even with any form of ownerless map modification, despite the challenges. Index of Cold Takes

Base building seems to be a mandatory part of the RTS genre and there are a lot of ways to go about it. Some games keep most structures confined to the main base while others encourage players to spread them all over the map. Many games use the base as an embodied tech tree that unlocks more powerful units, or at least use base building as some form of escalation. But the most interesting part of base building, at least to me, is the embodiment. Structures exist physically on the map, which in turn changes how maps play out from battle to battle. {STEAM_CLAN_IMAGE}/32557867/c2b99903e8efc4a350615564e614d7f89e04412d.png Placing a structure is essentially a form of terrain manipulation. At a bare minimum structures block unit movement. This makes it take longer to move through an area, and can bunch, split or protect units to create tactical advantages. Many games go further and prevent units from squeezing between structures, opening up the ability to create impenetrable walls. Walling plays a central role in some of the most popular competitive RTS, such as Starcraft 2 and Age of Empires 2, but it also features prominently in singleplayer games such as They Are Billions. Walling has an interesting relationship with the build grid. Around the turn of the millennium we, as a civilisation, developed the technology to place structures anywhere, without snapping to a grid, and it was the bee's knees. Many games went gridless, but the build grid hung around and thrives to this day. Here is why: small integers are your friends. A coarse build grid places significant limits on structure placement, and this limit engenders clarity. Players can quickly learn to tell the difference between a few gap sizes, and the smallest gap is easily distinguishable from no gap at all. Paths around a newly scouted base can be understood at a glance; just imagine trying to navigate a gridless base where it is unclear whether a gap is 99% or 101% the width of your units. Coarse grids also make it easier to optimally pack structures into limited space, and that is even before considering how some games let you freely rotate structures. {STEAM_CLAN_IMAGE}/32557867/fca9e751f3e430bd0a983b702a1b03cb417d0941.png If precisely placing structures is important, then it is too important to be done freehand. But there are plenty of reasons why a game might want to go gridless, and many of the downsides can be mitigated by letting units squeeze between zero-gap structures. Gridless placement lets players eke out small efficiencies, for game that want to be about fiddling with packing, and can lead to a more free flowing feeling. The look of a grid can also clash with more realistic settings or tones, since perfectly spaced structures tend to look artificial. Planetary Annihilation is notable for being forced off-grid by the impossibility of wrapping a square grid around a spherical planet. Populous: The Beginning, another game set on planets, manages to have a grid because its planets are toroidal. So where does Zero-K stand on all this? As you might have guessed, we love the terrain manipulation aspect of walling, so we use a grid to allow for walling without too much fighting the UI. More generally, Zero-K bases are spread all over the map, as the resources are spread out, and include plenty of wall-like structures and turrets. A turret can be thought of as a distinct type of terrain manipulation in that it only weakly inhibits movement, via the application of danger, and only for the enemy. Building a defensible base is a bit like an asynchronous puzzle, where the defender sets a challenge and the attacker tries to solve it. The interplay of past and present decisions is a neat way to add player interaction without furious micromanagement, although the defender will often bring mobile units to bear as well. The physical projectiles of Zero-K add another level of depth to the puzzle, since friendly fire is not friendly. Your own structures create blind spots for turrets and defending armies, which tends to favour the attacker over the defender. {STEAM_CLAN_IMAGE}/32557867/eb6468c3284595d77c65a47a980796d77ee33f63.png A great way to get players into terrain manipulation is to give them a bit of it for free. Consider the houses of Age of Empires or the Supply Depots of Starcraft. These are what I call forced assets, because players are forced to build them, but they also have secondary uses. Supply structures make great forced assets, and Blizzard in particular has used them to house quite a few interesting abilities. But over here in the Total Annihilation subgenre we love to shower players with options, so Zero-K only has a weakly forced asset in the Solar Collector. A Solar is tough enough to serve as a viable wall, but it is not entirely free due to the existence of other, more efficient, energy generators. Nevertheless, the efficiency gap is effectively a large discount on walling. The counterpart of the Solar Collector is the Wind Generator: one of the flimsiest structures in the game. It exemplifies the vulnerability of physically putting your assets on the map, and players will always have some vulnerable structures. This vulnerability is the driving force behind RTS, since if everyone is strong everywhere, there is no reason to prefer attacking any particular location over any other. Vulnerable structures act as location-based goals for your opponent, which is in some sense a modification of the terrain. Other map-based genres, such as DotA-likes and team shooters, have elaborate objectives baked into the map, whereas this is rarer in RTS since player bases are so good at generating dynamically shifting objectives. Thinking of structure placement as terrain modification lets us take a more general view of how players interact with the map. Whenever a player invests resources to deliberately change the map, in any way, they are making a claim about the importance of the affected location. Fortifications have a long-term impact on how armies move around and interact with the map, and further modify the importance of other areas. Games are won and lost on the basis of disagreements about what matters, and expressing such disagreement via structure placement is a big part of the long term decision making that is at the heart of strategy. {STEAM_CLAN_IMAGE}/32557867/8e07c2386a7f3b19505db719d978719e327aba2e.png Zero-K has a flashier form of terrain manipulation: the mountain-moving and river-gouging set of mechanics that we call terraform. The seed of this post was on terraforming, but it would have been wrong to give it all the credit for the terrain-manipulation-y feeling of expanding across the map and bending it to your will. It would also be wrong to claim that Zero-K (and a handful of other games with terraforming) invented this feeling, when so much can be done without literally picking up the ground and putting it somewhere else. Terraforming is interesting, particularly when contrasted with more traditional map manipulation, so covering the basics here leaves us plenty of room to look at the challenges involved in making a terraform system that actually works. So stay tuned for Cold Take #31, in three weeks time. Index of Cold Takes {STEAM_CLAN_IMAGE}/32557867/bed2fcd618d0f14c8bc620d6761f9257c6f6066b.gif

Serious Strategy Games tend to spread their scope across the three standard theatres of war: air, land, and sea. Zero-K follows suit, despite being markedly more gamey and fun-loving. Nowhere is this clearer than in the interesting application of realism to planes and gunships. The real world has some influence over aircraft behaviour, and very loosely informs their support role, but it is just a starting point. Our priority is for air to be fun and useful throughout the game, as too often it can end up being a bit one-dimensional, or just be relegated to gambits. First things first, how should air units behave? We were guided by rough intuition, so if it looks about right, then it is right. Real planes exist, but tend to be too high and fast to see, so the average experience of flight probably comes from birds and insects, with a bit of influence from helicopters and drones. These things are fast, so air in Zero-K is fast. Common experience also motivates two types of aircraft movement which, as with ground, we use to sort aircraft into their two factories: Gunships and Planes. {STEAM_CLAN_IMAGE}/32557867/65657cc73638557fefd7571f1ec0a2d878705d77.png Gunships are akin to helicopters and drones; they fly around, some are quite nimble, and they can all hover in place. This is the standard RTS treatment, and it is sometimes criticised for being unrealistic or for making air and ground combat play out in much the same way. That said, ground combat is solid, and gunship-style air units across many games distinguish themselves by being faster than land units, at least on average. Gunships are also great at attacking from any direction, and avoiding obstacles when trying to retreat. Planes fly like real aeroplanes and come in three flavours: bombers, fighters, and scouts. They only stop when they land, and have wings, ailerons, and rudders. There is an underlying flight model with the aforementioned parameters, and more, which we use to dial in the realistically uncontrollable feel of planes. Complete Annihilation tweaked these parameters to make planes more controllable than in its predecessors, yet plane-on-plane combat is still quite hard to control, to the point where we avoid expecting people to click on individual fighters, as they are just too fast. Fast units are troublesome, since they inherently dominate the early game. Speed is just an amazing attribute, especially when there is plenty of free space to move around. Aircraft have it worst, being by far the fastest units, so a lot of air design is focused on how to make them unusually bad early on. Without skewing air away from the early game, we would see it early, then never again. {STEAM_CLAN_IMAGE}/32557867/29db4f63a29b37cce00838d119c7ed75041d2995.gif Planes were nerfed early by requiring bombers to reload after each run. Prior to the change bombers could fly circles over the enemy base, continually bombing it, provided there was no anti-air (AA) in place to shoot them down. This would only realistically happen early in the game, most likely after a surprise attack. Reloading also drains energy, which makes it even more costly early compared to later on. There is no clean solution to the early game for Gunships, but they are not quite as fast as Planes, so the problem is lessened. Part of their solution is their terrible stats: a gunship will often cost twice as much to move twice as fast, but perform the same, or worse, than land units. Many of them are also awful against raiders, and a bit too expensive to comfortably rush, which adds to their early vulnerability. The light gunships are still in an awkward spot though, and it is made more awkward by AA. Anti-air is a necessary, yet slightly unfortunate, part of air design. Flying units benefit greatly from Physically simulated projectiles since it lets them avoid most of the damage from a lot of weapons. Even beam weapons, which hit instantly and precisely, either deal constant low damage, or have a sustained burst that only hits fast units for a fraction of their damage. Plus, beams have spherical range, so are bad at shooting up. So Zero-K has units that can only shoot at aircraft, called AA or dedicated AA. This is the largest exception to the idea that units can shoot in any direction they like, but it is a tradeoff that we made to free up the design space for aircraft. {STEAM_CLAN_IMAGE}/32557867/341a23829cbbab54ae3bcb32160689bc5999d164.png In addition to dedicated AA, Zero-K has flex-AA. This is not a well-defined set of units, rather it is the idea that many units are decent against aircraft, especially if they fly directly overhead. Flex-AA is particularly good against gunships, since they are slower than planes, to the point of making dedicated AA redundant in some cases. In fact, we buffed gunships against dedicated AA on a few occasions. Back in 2010 we reduced plane health and anti-air damage by 25%, which is equivalent to making planes weaker to flex-AA, and gunships stronger against dedicated AA. This was repeated in 2014 with a reduction of 1/11th, since Raven had 1100 health at the time. There is a limit to this approach though, because at some point the most effective flex-AA starts destroying planes. Dedicated AA poses a potential problem: it is monospammable if you are only facing air. We solve this by declaring the problem to not exist. Planes and Gunship are deliberately designed as support factories, they are not meant to hold a front on their own, and should be unploppable in 1v1. Of course they technically can be plopped, as to block a plop based on player count would be too arbitrary, so all we can do is discourage them. Gunships were a particular problem for 1v1, since forcing out a bit of AA then quickly switching to land confers a massive advantage. In addition to making their units terrible early, we also had to make their constructor too slow and expensive for early expansion. Air factories are not like other factories. While land factories are a somewhat self-contained and flexible set of units, air factories only make up one side of a counter triangle. Air beats ground armies, which beats AA, which in turn beats air. So if the enemy makes a lot of AA, then the air player might need to switch to ground to kill the AA. This turns air into a force that escalates the game, as it adds an extra layer of interaction, similar to the relationship between nukes and antinukes. This makes air a bit less of a faction, and more of a tech choice, at least in 1v1. {STEAM_CLAN_IMAGE}/32557867/39e8ba143aeff8fda308debb978f98e8d9bc9a17.png Even as a secondary factory, built later on to escalate the game, Gunships have had a problem with viability. This is understandable when you realise that Planes offer the fastest units, the best scouts, and can execute devastating surprise bombing runs. Gunships are just a bit faster than ground units, can attack from anywhere, and have terrible stats. The scouting issue in particular motivated the addition of Sparrow: a light scout that can be produced by morphing a radar tower. This gives all factories access to scouting, so adding another land factory is more viable as well, which is a neat way to see cross-factory synergies. In the end, air is not the primary domain of Zero-K, but it is constantly trying to break out and become the whole game, rather than just be a fleshed-out corner of a counter triangle. This is a lot to put on only twenty or so units, and as a result they are some of the most tweaked and reworked in the game, with Raven out in the lead. Specifics may come in future posts, as they would make this one three times as long. Index of Cold Takes

This is a hotfix for a new desync bug and an issue with commander range modules. Other fixes that we were working on made it in too, as well as a form of AI integration for Tech-K.

Features

• AIs now have their structures upgraded automatically in Tech-K. This cheats a little, since structures are upgraded instantly, but the upgrades are paid for by skimming the top off their metal income. The proportion that goes to tech depends on scouted enemy tech levels. This behaviour can be disabled in battle options.
• Commanders can now be tech-upgraded in Tech-K via the Strider Hub upgrade command.
• Resurrection in Tech-K now creates level 1 units, to match the size of individual wrecks.
• Added more Tech-K prefixes. These ones might even last beyond the point that the game crashes.
• Added High Trajectory default to the ingame Unit Behaviour menu, for the units that can toggle it.

Fixes

• Worked around a new desync bug that was likely due to the recent engine update. Behind the scenes we switched the default pathfinder to QTPFS and (temporarily) stopped using Lua path requests. This mainly affected battles with zombies or legacy AI, but could show up in other modes.
• Fixed status effect damage removing commander range upgrades, as well as a few related minor issues. For example, Duck would have a momentary leash range glitch upon taking slow damage, due to differing torpedo and missile ranges.
• Fixed a few Tech-K range-related issues for units with context dependant range (eg Duck and Claymore).
• Fixed Tech-K gauss damage failing to scale.
• Drones are also invisible to radar when under construction.
• Units are no longer pushed sideways by the next nanoframe when they leave a factory.
• Blastwings now leave the factory by flying up, rather than down.
• Fixed missing cloak information in the unit information menu (Space+Click).
• Fixed a rare vertical line indicator error.
• Fixed "(default)" being written next to the wrong music album.