Zero-K - GoogleFrog
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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
Share: 
