Genre: Real Time Strategy (RTS), Simulator, Strategy, Indie
Zero-K
Cold Take #13 - Pro-Simplicity, Anti-Nuke
Zero-K has nukes. This should come as no surprise, since otherwise the genre police would revoke our sci-fi license. Even a few fantasy games have nukes, but wherever they are found, they all work basically the same way:
Climb to the upper reaches of the tech tree.
Build a nuclear missile silo.
Build a nuclear missile.
Launch it at the enemy base.
The enemy is now down one base.
Total Annihilation, a game not known for keeping things simple, spiced things up with anti-nuke missiles that shoot down incoming nukes. This means a well-prepared enemy might not lose their base. The same system can be found in every single descendant of TA, with many of them building on it and making it more complex. As you might expect by now, Zero-K went the other way, paring anti-nukes down to their simplest form. We still have recognisably TA-style nukes and anti-nukes, but they are no more complicated than is is required to produce great stategic nuke gameplay.
Strategically, anti-nukes have one purpose: to be a weak point that the enemy can hit for massive damage. At least, this is what we decided back in Complete Annihilation, when we were looking for ways to encourage surgical strikes into the enemy base. Anti-nukes are the ultimate weak point, indeed, bases tend to blow up shortly after their anti-nuke is destroyed. The closest contender is the violently explosive Singularity Reactor, but it can often be built to the side to minimise friendly fire, and there is relatively little profit in destroying one, once reclaim is taken into account. Anti-nukes are also particularly vulnerable to Widows and tactical EMP missiles, since a temporarily stunned anti-nuke can be just as bad as a dead one. Without nukes and anti-nukes, armies would have to slog through bases to destroy them, which would drag out won games, and give underdogs little opportunity to make a comeback.
Strategy aside, anti-nukes are also great for the Rule of Cool. Ironically, giving nukes a hardcounter lets them be much more powerful, and more common. This is great, since players seem to love nukes, but not so much when they bring games to an abrupt end. Zero-K might even have the largest nuke, since it has only grown since TA, but it is hard to compare across games with different scales. Our nukes are certainly large enough to destroy a whole base or front, and drastically alter the course of a battle.
An unblockable and highly devastating nuke would essentially be a Wonder from Age of Empires; something that puts the game on a strict time limit, then declares a winner. This is fine, and the fireworks display is a nice addition, but it becomes unsatisfying if too many games end like this. Wonders and other unblockable superweapons are insufficiently interactive, so it feels unfair to lose to one, whereas nukes with a clear counter give the defender more agency. Many games with unblockable nukes, such as Starcraft and C&C, avoid the issue by making their nukes relatively unimpressive.
Zero-K even provides a direct comparison of blockable and unblockable nukes, since its three "true" superweapons cannot be blocked. The cheapest of them costs 4x more than a nuclear silo, so they are reasonably rare, and can only ever appear late in the game. Still, the true superweapons are more controversial in the community and have been harder to balance, even though nukes appear much more frequently. The fairness inherent in being able to block nukes seems to be important.
As previously mentioned, Zero-K anti-nukes are just about as simple as possible. This is no great feat, since anti-nukes are fundamentally just a missile that shoots at another missile. The complexity of anti-nukes in other games tends to come from:
Multiple types of nukes and anti-nuke, possibly varying slightly between factions.
Mobile anti-nukes, commonly found on capital ships or as vulnerable utility vehicles.
Stockpileable anti-nuke missiles that must be produced before the anti-nuke can fire.
Zero-K has none of this paraphernalia. We used to have all of it, but it was steadily removed for acting counter to the design goals, or just for adding complexity for little benefit. Mobile anti-nukes are near-impossible to disable, when properly defended, so had to be removed. Stockpiling anti-nuke missiles prevents boosting, which is a valid purpose (see Artemis), but it has severe downsides. There is nothing worse than thinking you have an anti-nuke, only to discover that you forgot to stock enough missiles. Getting nuked is already not the best experience, so the least we can do is make it feel as fair as possible.
Zero-K has a single anti-nuke, and it takes the form of a dedicated structure. It is extremely atomic, and relatively expensive, tipping the balance in favour of offense over defense. A nuclear silo costs 8000, each missile costs 3240, and an anti-nuke costs 3000. Two anti-nukes only provide bare minimum coverage on large maps, so reliable coverage can cost more than the nuke it is meant to block. This is intentional, since offense should grow in power as the game progresses, and nukes need to be common to give bases weak points. At least anti-nukes block missiles flying through their coverage, because otherwise using circles to cover the backs of a rectangular map would cost far too much.
The simplicity of anti-nukes extends to their physics, which is on the gamey end of the spectrum. Anti-nuke missiles pierce absolutely everything; allies, enemies, terrain, because the stakes are so high. A system has to be reasonably predictable to feel fair, and the importance of fairness increases with the cost of failure. So if terrain blocked anti-nukes, then the game would have to make it absolutely clear when this can happen. But such a UI sounds hard and pointless, so instead we gave anti-nukes a flight path that will very rarely clip into terrain, and called it a day. But a more unusual aspect of anti-nukes is to do with what they can fire at.
Anti-nukes cover a simple circular area, with the guarantee being that no nuke will land in or pass through this area. But the "attack range" of an anti-nuke, i.e. how close a nuke needs to be for the anti-nuke to fire, extends beyond this circle, so that it can shoot at nukes before they land. This is weird when you think about it in terms of unit physics, since surely an anti-nuke could technically offer protection to targets on its flanks. Indeed, a more physicy anti-nuke could fire at all reachable nukes, but this would give it a weird effective coverage area that depend on the direction and pitch of incoming missiles, and even on the shape of nearby terrain. Communicating such coverage would be a UI nightmare, and inevitably be misunderstood, making interception feel like a roll of the dice.
If you want to get really pedantic, then, technically, blocking nukes in Zero-K is far from simple. This is because every unit can do it, and I have even seen the following used to intercept nukes:
Dirtbag
Jack
Raven
Athena
Funnelweb
Nukes collide with bodies, so anything with a body can block them. However, they do not collide with allies, since blowing up your own base due to an errant bomber is infuriating, while blowing up the enemy base with a jumping Dirtbag is hilarious. Most units intercept nukes by jumping or flying over the silo right as it launches a missile. Funnelweb is a notable exception, since its shield has enough charge to block a nuke. At least, if by "block" you mean "blow up at a slightly different location". Shields only halt projectiles, they still explode, so area of effect damage is unaffected. This means that a Funnelweb can only ever block one nuke. Still, it is a desperate technique that can mitigate some damage, especially if the Funnelweb is high up or flung into the air.
But enough about anti-nukes, what about the nuke itself? There is much less to say here since they follow the basic nuke formula, and refinements were mostly implemented via the anti-nuke. Check out the Core nuke in BAR, it has the same damage and area of effect, so the common ancestor dates back to at least 2007. There have been a few changes though.
The nuclear silo opening animation was changed in the mid 2010s to nerf Athena nuke interception. Previously, nuclear silos would open only when told to fire, which let a watchful enemy fly a cloaked Athena over the top to intercept it. This decloaked the Athena, so timing was important. Players countered this by manually priming their silos with the Wait command. So silos were changed to open as soon as they have a missile stockpiled, making them ready to fire immediately, which is just a case of removing a way for unit AI to be stupid.
The flashing "Nuke Launched" indicator is another somewhat recent addition. This was more of an accessibility thing than anything else, because we had always balanced nukes around a globally audible launch sound. But not all sounds are heard, and it became a source of unfairness. The alternative was to remove the global aspect of the sound, but this would have removed my favourite part of nukes; the mind games. Nukes take a while to land, so armies can just about dodge them if they guess the impact site correctly. This creates a whole guessing game of large scale army movements, which can even be exploited or corralled by the team that launched the nuke.
But why would people even launch nukes at armies? Because anti-nuke coverage is easier to pierce around the edges of enemy territory, so sometimes an army is the only available target. All the mechanics support each other.
By far the funniest, and possibly oldest, nuke change happened back in CA. Have you ever wondered why nukes look like a rocket, but launch at full speed with no acceleration? This is thanks to a developer called det, the namesake of the Detriment, who launched a nuke at his neighbour in a free-for-all on Azure Rampart. His neighbour had an anti-nuke which was, unfortunately, within attack range of det's nuke. This caused the anti-nuke to fire immediately, so it promptly flew over an blew up the nuke right on top of det's base. Nuke gained more launch speed as a result, although these days the "new" anti-nuke opening animation might have made the increased speed redundant.
More units and mechanics were changed as a result of things that happened to det on Azure Rampart, but they will have to wait for future articles.
Players coming from other strategy games often find classic conventions broken and common systems missing. The three focused on improving units - morphing, veterancy, and research - are largely absent from ZK. Today is the first of a series of guest articles by Sprung that will talk about them.
First, let's talk about the unit improvement system that still exists vestigially in ZK: morphing. Morphing is often called upgrading, but I won't use that term to avoid confusion since it can also mean research. Very generally, morphing lets you improve or modify a single unit, as opposed to upgrading all existing and future units of that type, like research does. This can be as little as paying three seconds of time to deploy a Terran siege tank; or as drastic as changing two Protoss Templar into an Archon. Of course you can have morphing as a major part of faction identity and aesthetics, but let's talk gameplay. When to have morph instead of just letting players build things normally?
An easy answer is that sometimes you already decided not to let players build more of the unit. In ZK you only get one commander, and there's a limited number of geothermal spots. Accordingly, they are the only two cases where morphing is just a straightforward upgrade. The astute reader may have noticed that metal spots are also a limited resource, and indeed mexes used to morph into Moho mines for a short period before overdrive was instated. Here morphing lets you decide to get more mileage while working within the limit.
A nice example from another game would be the Chinese Overlord tank from C&C Generals. It has a soft limit by virtue of simply being too expensive to field many of them, but you can add extra weaponry on top for even more firepower. Allocating skill points for WC3 heroes can also be thought of as a form of morphing, and it's no accident that allocating modules for ZK commanders looks so similar.
The flip side of a unit limit is flexibility. RTS is, among other things, about making the correct units to adjust to a quickly changing battlefield. The flexibility of morphing lets players continue making choices about their unit composition in face of a limit. Warcraft heroes, Generals Overlords, and ZK Commanders all present multiple morph choices for this reason. Similarly, in Dawn of War earlygame, forcing the player to choose between Flamers or Bolters for their first tactical marine squad, blindly, would not be good design. Morphing some marines to equip weapons lets players make that choice later, while still having a squad on the field to capture points, scout, and do other tasks that don't yet involve picking a specific unit composition. Then, when you scout Orks? Brother, get the Flamer. The Heavy Flamer.
Back to ZK though, since we don't really put any pressure on the player in the form of unit limits, there is barely any need for the flexibility. Ramping economy means that even the most expensive units can become somewhat affordable over time, and by that point you have all the flexibility in the world anyway. Would it hurt to have a little extra?
The problem with flexibility is that it creates a sort of Schrödinger's unit that occupies multiple spots in design space at once, to be resolved into one of them when observing the enemy. The danger ZK sees here is that a monospammed unit could become a composition thanks to its own flexible morphs. Everything becomes much simpler when you can do Just-In-Time reinforcements of the correct type without having to do lame nerd stuff like "logistics" or "foresight". No travel time from the factory. Less risk of overbuilding a variant. Of course these can be adjusted via other stats, but that would all come with a reduction in flexibility.
What about "inflexible" morphs, where there isn't really a composition to talk about and you just want to add more stats? Say, why doesn't a factory have a +10 Buildpower upgrade? It would be more atomic than a Caretaker, who can also do other tasks such as repair! Or, if I want to upgrade Felon battery recharge rate, I have to either get Convicts and have to pay for buildpower I didn't sign up for, or Thugs with inefficient guns thrown in. Meanwhile, a +15 shield regeneration morph would be atomic while remaining a choice! Part of the answer is that units are physical entities in the world and thus there is more interaction between them. In particular, Convict buildpower and Thug guns nudge the player into using them, which then cascades into the usual complexity of the game when the enemy has to respond in turn. The other part is emergence. Felon wasn't initially designed to work as a standalone unit and get "batteries" added; rather, it was designed to itself be added to a shieldball as a way to spend charge. Batteries are a player discovery, if an extremely obvious one.
An interesting feature of morph is that it provides its own buildpower and can have different tech requirements, which then can be used to adjust the appeal of different options. If you require a unit to be built "normally" then it competes for infrastructure (buildpower, logistics) with other units that you may rather be building. Morphing is a way to avoid this, which makes the unit more attractive, or the usual infrastructure less attractive. To put this in concrete terms: say you want to encourage mobile cloakers, because cloaking is cool. If you require people to build them from a cloaky factory, then sometimes they'd rather build a different factory as a secondary, or if they already have a cloaky factory, they'd rather build a different cloakybot. Morph lets a unit be its own little temporary factory, and the elegance of this is that much like energy requirements, it touches just the infrastructure and not the unit itself. The morphs for mobile cloaker and shield, while originally created just as a way to let them redeploy, fall under this category. We try to avoid this type of morph outside of utility units since infrastructure exists for a reason, and while it is easy to manage it should not be obsoleted.
At the beginning I mentioned Siege Mode as an example of morph. In ZK, a handful of units - for example Crab, Fencer and Emissary - have a soft siege mode where standing still gives them some sort of benefit. They deploy so fast that not doing so would mostly be a matter of not having the APM, so rather than make the players fight the UI by spamming Deploy every time they want to move, the units deploy on their own. To let this happen, there is a deliberate large gap in unit design space where nothing has a deployment mode that would be long enough not to automate, yet short enough to make you miss the automation by being commonly desirable. On the other side of this gap we have Desolator, which can deploy into an armoured form, but it takes long enough to make it a rare decision that can afford to be manual. Thus, unit intelligence, or rather avoiding situations that would create unit stupidity, is what prevents sufficiently cheap morphs from existing.
A final way morph can be used is to randomly change a unit into a completely different unit, apparently for no good reason. Why does Lurker morph from Hydralisk? The answer seems less to do with any explicit unit design, and more with how it just had to be crammed somewhere given there were no empty slots on Larva build GUI. Hydra was the least awkward place to put it. Surely ZK would not do something as silly as, say, let Knight morph into Crab without an extraordinarily good reason, right?
This is a small patch that was released to fix the settings deployment bug. A few other things we were working on made it in too.
Fixed a recently introduced issue that caused particular settings to be overridden on launch.
Units far from the epicentre of a Shockley impact are now stunned sooner, to match the explosion visual. Which units end up stunned is unchanged.
Added a cracked ground impact scar for Quake.
Fixed inverted track stretching for, eg, Paladin.
Moving a block in a factory production queue no longer re-applies the multiplicative key modifiers.
Fixed the commander selector ending up off the edge of the screen on particular scaling settings when shifting from windowed mode.
Simplified window resolution switching code to try to make it more reliable.
Fixed sun and water settings overrides being too persistent between maps.
Fixed the sun on Tempest.
Fix thumbnail and minimap images for maps containing unusual characters.
Fixed a bug caused by map searches finding no maps.
Fixed the player name tags widget possibly being assigned incorrectly.
Tweaked the draw order of name tags, health bars, and overhead icons.
Cold Take #11 - The Atomic Solution to Monospam
Zero-K units are generally quite simple, with many of them designed around a single weapon or ability. The idea is that the complexity of an army should come from how it combines unit types, rather than having any individual unit be particularly complicated. I call this the principle of atomic unit design, because it characterises units as the building blocks of armies, and simple units are, in a sense, indivisible. Simplicity is a good enough goal on its own, but atomic unit design also has an important role in fighting monospam.
Monospam, i.e. spamming a single unit type, can be a contentious issue in RTS. Many players consider such a strategy "unfair" or "cheap", and games are often designed to discourage it, including Zero-K. This makes Zero-K a bit unusual within the Total Annihilation lineage, since TA had a bit of a reputation for monospam, and many successors dealt with it by culling the "excess" units. Zero-K went the other way, and found ways to balance a large unit roster without the resulting monospam. But before we get to that, we need to pin down what makes monospam powerful in the first place.
Monospam derives a lot of its power from being easy to manage. The logistics are simple. Just set your factory to repeat-build Scorchers, spam Ctrl+Z to keep them all selected, then repeatedly hit your opponent with them. The Scorchers move at the same speed and want to fight the same types of battles. But mix in more unit types, and it becomes much more complicated. Even maintaining the right mix is a challenge, since different units often die at different rates, and reinforcements take time to reach the fight. A mixed army that loses most of one type has to wait for the build ratios to be adjusted, while monospam can rely on a constant stream of appropriate reinforcements.
To skew things further, mixed armies are as bad as their weakest unit across many attributes. For example, mixed armies move at the speed of their slowest unit, and are as vulnerable to attrition as their most fragile. Consider an army of tanky Minotaurs and glass cannon Ogres. Such an army is either going to lose a lot of Ogres, or it is going to avoid taking fights that Minotaurs would weather without hesitation. In many situations, half an army wants to fight while the other half wants to run away. None of this is an issue for an army of a single unit type, with uniform strengths and weaknesses. Essentially, most units synergise best with themselves.
So, why do we want to discourage monospam? In short, because there is no crunch in easy decisions, and Zero-K is largely about deciding what to build and how to use it. This is much more involved when dealing with multiple unit types, both on your side and in the enemy army. And, as mentioned previously, the goal is mixed armies of combat units. Mixing battle tanks and anti-air is fine, but the tactical goals for such an army are often quite simple, depending on the type of enemy that is coming at you.
Now that we know what makes monospam powerful, how can we avoid it? The first principle is that mixed armies are 'allowed' be much more powerful than monospam. My gut says 1.5-2x as powerful, but there is no definite value. The principle is great for guiding balance discussion though. For example, say we are thinking about how Rover might counter Fencer. Scorcher is a decent suggestion, but then some theorycrafter objects that Scorcher is solved by mixing in a few Ripper. At this point, we can invoke the principle, and say that Scorcher losing to a mix of units is fine. Forcing your opponent into a mixed army is half the battle, with the other half being to wait for them to succumb to the extra complexity. So we are free to focus on whether pure Scorcher beats pure Fencer.
Likewise, the second principle for avoiding monospam is that everything needs a hardcounter. It is not enough for a unit to have bad matchups, it needs some absolutely terrible ones. This because straight-up cost-for-cost fights fail to take logistic and self-synergistic advantages into account, and such fights in a vacuum are an important part of judging counter relationships. So any unit that manages to not lose too badly against anything is a prime candidate for monospam. This is not to say that hardcounters have to feature prominently in how the game plays, they just have to be lurking in the background, threatening players with annihilation if they invest too much into one unit type.
This is where atomic unit design comes into play. A unit that does one thing well tends to have weaknesses everywhere else, so must rely on other units to cover those weaknesses. Atomic unit design is not a strict rule though, as it often fights the Rule of Cool. This is a hard fight, especially when big units are concerned, but we still try to keep the abilities of complicated units pointed towards the same purpose. Sea has struggled the most with the Rule of Cool, since ships want to have multiple weapons, and the disparate weapons or Siren are a remaining nod in that direction. The worst offender was Envoy, which use to have a depth charge that acted as inbuilt riot support against anything on or below the water.
Factory abilities further dilute the idea of atomic unit design. If you count things like personal shields, jumpjets, and spider legs as abilities, then a lot of units have two abilities; one weapon and one utility ability appropriate to their factory. However, this extra complexity is well worth it, as having an ability in common strengthens the feel of factories as cohesive factions. The same could be said of, say, Zerg Burrow. Besides, a "faction ability", one shared by many units, has a much lower complexity penalty than an ability that arbitrarily exists for a single unit.
Atomic unit design also applies to structures. For example, Complete Annihilation had a few types of metal extractor, including an armed metal extractor. This structure was not atomic since it had two distinct abilities, metal extraction and a laser turret, so it was removed in favour of the more interesting method of defending a metal extractor: just make a Lotus. This confers all the subtlety inherent in atomic units, A turret might be built forwards to better protect the mex, or in a more defensive position and use the mex as cover. A weak raiding party might have to choose between killing the turret or the extractor. Armed metal extractor provide none of these decisions, approaching one is the same every time, and a fight with one only has two possible outcomes.
Commanders, being the opposite of simple, are a constant thorn in the side of atomic unit design. They are upgraded a bit like a composition of units, with each module adding a single weapon or ability, but fight like a single unit. A high level commander is akin to a one-unit monospam, with all the logistic simplicity and self-synergy, so it needs strong counters. This is hard to square with the feel of commanders, but that deserves its own whole article.
By now you might be wondering, is this all just Quant's Rule? Yes and no, I would say that the ideas are complementary. Atomic unit design is more of a goal than a method, while Quant's Rule is not so strict about how many strengths a unit can have. Quant's Rule guides us through day-to-day balance changes, while atomic unit design is more holistic. Waffling aside, it is mostly just useful to look at things from multiple directions, and it should not be surprising that many of the principles behind Zero-K lead to the same place. So stay tuned for the third I can't believe it's not Quant's Rule article, where I expect to cover Moonwells and the nature of greed.
Most player actions in real time strategy boil down to giving commands. After all, these are games about telling units what to do. But there is a subtle difference between RTS and most other genres, in that players tend to act indirectly, by assigning goals to units. The game world itself is only ever affected by units as they try to achieve their goals. This takes a certain level of unit intelligence, and the stakes are high. The fantasy of commanding an army can be shattered by a single unit wandering off in a weird direction.
Issuing commands also has to feel good, since it is your primary way of interacting with the game. This implies that common commands should be small and simple, like short words. In fact, commands can be thought of as the language used by players to tell their units what to do. This analogy turns unit control into a communication problem; how can the player communicate their grand plans to the fragile bundles of code that stand-in for the brains of their units?
The units of Zero-K are relatively smart. Here are some examples.
Units in almost all games know how to close range with the enemy, but Zero-K units also know how to step backwards when the enemy gets uncomfortably close.
They can be told to hold their fire against cheap targets, and know how to stop short of firing enough missiles to kill something twice over.
They can be told to repair or reclaim everything in an area, rather than requiring that the player point out each target individually.
Some can be told to avoid wasting their precious reload time on wobbly radar dots, while others can be told to fire in the general direction of distant targets.
Units even know how to spread themselves out along a line.
The examples above hardly seem earth-shattering, but that is by design. Zero-K units are only much smarter than average because they understand a wider range of commands. The more complicated behaviours, such as the ability to move away from enemies, are optional. Set a unit to hold position and avoid telling it to Attack Move, and it will stay put. This is vital because the principle fight your opponent, not over-automated ingrained unit behaviours is just as important as fight your opponent, not the UI.
In short, Zero-K units are smart by virtue of their expanded their command vocabulary, rather than by making decisions themselves. Units should not be making significant decisions, those are for the player to make, because otherwise we start diluting the "Strategy" in RTS. To this end, the complexity of each command has to be quite limited. Notice how the examples above were explained in about half a sentence? You have to be able to to describe your intention when giving commands, otherwise unit control becomes a process of clicking random buttons while hoping for a good result. So unit behaviours need to be predictable. For example, the "keep enemies at a distance" aspect of Attack Move only considers the closest enemy, since a whole-battle view would be too chaotic.
Commands are great, but how do they relate to the smartest unit in Zero-K? Well, players assign goals to units, which the units then try to execute. Achieving goals seems like a good measure of intelligence, so we can think of the smartest unit as the one that is the best at using its abilities to achieve goals. This includes goals that the player has trouble communicating due to a limited command vocabulary, so as to not give a free pass to abilities that are trapped behind poor UI. Also, since we are talking about game AI, it is more useful to think in terms of "least stupid", where stupidity is the misuse of an ability in pursuit of some goal.
The stupidity formulation of smartness turns abilities into liabilities. For example, if you tell a unit to move East and it ends up walking West, then we would say it uses its movement stupidly. But if the unit has no legs, so fails to move at all, we can hardly blame its failure to achieve the goal on its inbuilt AI. Thus, the only units with "perfect" pathfinding are those with the inability to move. And being incapable of failing is almost like intelligence.
So there you have it. The smartest unit in Zero-K is the humble Storage. It has a single ability - to blow itself up - and it is very rarely a good idea. Consider some alternative candidates. Most energy structures have impressive explosions, so it is more conceivable that a player would want to give them some sort of Fire At Will stance. Solar Collectors are out due to the wealth of agency bestowed upon them by the ability to armour up. But perhaps you have a more normal, less technical, definition of unit. One that involves the ability to move. In that case, I might have to argue for Aspis, the mobile shield generator, for the title of smartest unit. But if you have alternative candidates, be sure to post them.
So let's take stock of Aspis's abilities. Being unarmed is a good start, since deciding where and when to fire is a whole can of worms. Then there is the issue of pathfinding, which I could have avoided by nominating a plane or gunship. However, with great mobility comes great responsibility, so even Owls need to be pretty smart to not fly into an untimely end. No, a slow ground unit is safer, as its low speed makes it less responsible for its fate. And besides, the pathfinding in Zero-K is pretty good.
Aspis can also charge its shield, float, morph, and self-destruct. Floating and morphing are niche options for Aspis, and self-destructing is very rarely good. That leaves charging, which can be toggled on or off, and is integrated into the priority system. So Aspis has a pretty good command vocabulary in this area. Remember, it is not on Aspis to optimise its energy drain for the overall economy, it just needs to have a rich set of ways for the player to tell it what to do. So Aspis is very good at using its abilities. Now, those of you with some shield experience might be wondering, what about shield link? Aspis can share its shield charge with nearby shields, and there are some well known ways to exploit this ability.
Aspis' bid for the title of smartest unit hinges on the fact that shield link is a passive ability. Think back to Storage, is it "smart" or "stupid" for blocking projectiles? No, being hit by projectiles is part of being a Storage, it is a passive rather than an active ability. So too with shield link. If two allied shields touch, they share charge. Nobody can control it, and this sort of thing is a powerful technique for making units seem smart. Simply avoid giving units opportunities to be stupid.
Imagine if Aspis could control when to link, it would be an absolute AI nightmare. Linking is great when you need to pump charge into a Felon, but it can send a shield cluster below the threshold required to block tacnukes. The decision to link or not would take global information into account, and the best course of action would change too fast for players to manually control. A configurable linking stance would be unwieldy and riddled with edge cases, making it unpredictable. So it is better to keep linking innate, and let both sides of a battle work its straightforward behaviour into their plans.
Shield link is the highest-profile case of making an ability passive to avoid tricky optimisations, but we have many other more subtle ones. For example, Snitch and Imp have the ability to hide themselves by burrowing when stationary. If they took a significant amount of time to unburrow, then whether to burrow would be a decision with many strategic factors. Rather than make this decision, or make players manually press the burrow button, we made unburrowing near-instantaneous. Here are a few more examples.
Bulkhead and Fencer pack up quickly for similar reasons.
Units cannot hurt themselves with area of effect damage, as firing safely has tradeoffs.
Vehicles are very bad at moving in reverse, so that they do not seriously consider doing it.
To sum up, unit intelligence has three parts; vocabulary, competence, and not expecting too much. Think about what is going on next time you encounter a stupid unit. Does it lack the command language to understand what you are trying to tell it, does it lack the competence to achieve the goal, or do its abilities mean it has to solve complex optimisation problems which lack a satisfactory answer?
Zero-K v1.12.4.0 - Combat Engineer
The most experimental change of this patch gives Engineer Commanders the ability to build units out in the field. The goal is to make it more than the base building chassis. A much more normal change accentuates the speed of Strike Commanders by reducing the speed of the competing Recon Commander. Planes have been tweaked slightly, with the most notable change being Sparrow stealing Owl's radar jammer. Disco Rave Party has some ludicrous buffs since the newish spin-up requirement had a greater than expected impact on its power relative to Zenith.
For all its weird experiments, this patch is more about tech than balance. The engine has been updated with a new decal rendering system that performs better and will let us do more with explosion scars. Unit selections are drawn much faster and many of their edge cases have been solved. A new ambient occlusion shader gives the everything a bit more sense of depth. This is on top of a bunch of fixes and polish that built up over the last few months.
No Cold Take this week, because there was a lot to do for the patch.
Balance
Engineer Commander can now pick a unit to build out in the field.
Use the Copy Factory Blueprint command on a friendly functional factory to select a unit.
The unit can be switched during the game.
A unit is automatically selected from the plopped factory.
Set your plop selection under Settings/Unit Behaviour/Default States/Misc/Blueprint.
Recon Commander is slower to let Strike have an identity as the speediest commander.
Aircraft can no longer fly so far outside the map.
The external map border starts 400 elmos away, down from 800 elmos.
The border is softer, so brushing it is less drastic.
Graphics
Added new explosion crater scars to use the engine's new decal system. The new scars have better performance, stick to the ground properly, and have new features such as glow and variation by weapon type.
Added a screen space ambient occlusion widget. Basically, it adds subtle shading to put shadows in every nook and cranny. The widget is enabled for hardware that supports deferred rendering, which is most hardware.
Improved the walk animations of the Engineer and Recon Commanders.
Disco Rave Party has firing dust and complains every time it tries to turn.
Improved the look of Ogre missile explosions.
Fixed jittery Detriment launch smoke.
Improved Detriment and Jugglenaut stomp effects.
Made a few effects that were simulation-limited run at >30Hz if able.
Reaver aims more smoothly.
Interface
Updated selection circle rendering (thanks moreginger, and Beherith for the original shader). Selections look similar, but render much faster and resolve a few graphical edge cases suffered by the previous widget. Selection visuals can be configured under Settings/Interface/Selection/Default Selections.
Jumpleg units retain jump commands while midair so they can jump as soon as they find the ground.
Hermit auto skirmishes from slightly further away, making it better at dealing with Redback (thanks Mach565).
Improved replay controls (thanks moreginger).
Improved Athena and Newton selection volumes.
Control groups now obey selection rank.
Added an option for control groups to ignore some ranks.
Autogroups can now be used for buildings.
Autogroups no longer override manual groups set during production.
Added incomplete French and Ukrainian translations.
Maps
Added lava to Stronghold because it looks like it wants it.
Added boxes for Ravaged Remake v1.2
Awards
Some awards show up almost every game in nonsensical ways. To address this, the minimum threshold for a few awards has been raised.
Spoils of War requires 3.3x more reclaim.
Slow King requires 2x more slow damage.
Peacemaker requires 4x more disarm damage.
Modding
Add customParams.turn_accel_factor to control the angular inertia of units.
Add Spring.Utilities.ConcatArrays to concatenate arrays.
Fixes
Fixed split switching spectators to players in the split room.
Fixed load order of replays so the most recent replays show up first.
Fixed Bellicose Islands boxes (edge gap east).
Fixed a rare issue with the external map grid (thanks AntlerForce).
Fixed Newton launcher auto-jump sometimes causing jumps on the launch pad.
Fixed Envoy overkill prevention.
Fixed command insert not working with line formations.
Fixed jumping units sometimes using their walk animation mid-air.
Fixed shields sometimes not activating when rapidly thrown out of the water.
Units no longer move to clear the "entrance" of plane factories when a plane is built.
Units that start retreating are no longer automatically deselected for spectators.
Fixed the select damaged/healthy hotkey presets.
Fixed Fire Once leaving Set Target applied.
Fixed Restore not working correctly on random maps and maps with changed water level.
Fixed Sparrow's wingtip ribbons.
Fixed teleportation sometimes leaving tracks.
Fixed slow and Stardust heat rounding.
Fixed missing ghosts for some campaign-only structures.
Fixed orbital drops of ships trying to land ships on the sea floor.
Cold Take #9 - Energy as Supply
Why does Zero-K have energy? The previous article stopped just short of asking this question, but it is well worth asking. Continuing on, everything costs equal amounts of metal and energy, so it would seem simple enough to drop energy from the equation. Doing so would certainly make the economy smoother. Look at the Command and Conquer franchise, it seems to do just fine with one resource. But hold on, that is not quite right, since C&C has another resource, power, which plays much the same role as energy in Zero-K. Both resources are used to control the pace of escalation in their respective games.
Energy in Zero-K is like houses in Age of Empires, or Supply Depots in Starcraft. Fundamentally, these resources act as an expandable limit on some other aspect of the game, while being fairly unlimited themselves. The big difference is that houses limit the size of your army, while energy limits your rate of production. But we can call them both supply resources, and the effect of such a reason is to make it more expensive to build something for the first time, since infrastructure is needed to support it. Or to give it a more positive spin, supply provides a discount for rebuilding something up to its previous size. Many resources fit the supply mould once you see the pattern.
Consuming supply is generally a good thing, as units would prefer to do so than cost an equivalent amount of resources. Consider the Supply Depots in Starcraft, which cost 100 minerals and produce 8 supply. Now consider two variations on the Marine, if we ignore things like build times and hard supply caps, which is more powerful?
The original Marine that costs 50 minerals and 1 supply.
A modified Marine that costs 25 minerals and 3 supply.
A point of supply costs 12.5 minerals, so the converted cost of each Marine is 62.5 minerals. Notably, the full price only has to be paid to expand your army beyond its previous size. If your army dies, then you only need to pay the base minerals cost to rebuild. The modified Marine much cheaper in this case, so it would usually be considered more powerful. Of course, factors such as the army cap and the build time of Supply Depots would make the original Marine better in some cases, but the general point holds. This is what it means for supply to act as a discount on rebuilding.
The same supply dynamic happens Zero-K, just with production and energy, rather than armies and houses. Consider a bare bones economy, with just solar collectors and metal extractors (mexes). A mex makes +2 metal while a solar makes +2 energy. All construction costs the same amount of metal as energy, so every single bit of metal has to eventually be paired with the same amount of energy, if it is to be spent. This makes solar collectors act as a supply structure for mexes. Increasing your total metal income, for the first time, is more expensive than rebuilding after a raid.
Supply, in any game, exists to slow players down as they try to blast through the early stages of the game. It stops aggressive Starcraft players executing unbeatable all-in rushes with unreasonably large armies, and it stops Zero-K players greedily grabbing every single metal spot in an expanding cloud of constructors. This is vital for a game with income so strongly tied to territory, since the openings of such games can devolve into an all-out land grab. Overly explosive expansion runs the risk of determining the winner via early economic superiority, which feels bad and makes it hard to reach the midgame. Mexes have had their cost adjusted over the years with this balance in mind.
Metal extractors were quite cheap in Complete Annihilation, costing as little as 50 metal, but their cost rose to 75 fairly early on. Mex cost peaked at 90 metal in Zero-K and it has since dropped to 85. It takes approximately one solar, costing 70, to support a mex, so taking a new metal spot costs 155 in total, and 85 to rebuild, provided the solar is sitting safe in your base. It can be even cheaper though, as dead mexes leave 40% of their cost in wreckage, so rebuilding can only cost 51 metal. This might not seem like much, but a 100 metal discount on rebuilding adds up and stabilises the early game. Recovering from a raid would be much harder without this discount, however, reducing the cost of mexes to compensate would lead to explosive expansion. The game could probably be rebalanced with the discount removed, probably involving weaker raiders, but it would be a game of less back and forth, since losing a mex would be inherently more impactful.
There are many ways to make a supply system. The most common implementation has you try to build a unit, hear a voice yell "Construct additional Pylons", and then has you sit on your hands until a pylon is built. Many people find this frustrating, and it looks a lot like fighting the UI, so Zero-K opts for a more forgiving approach. The main differences are:
Energy and metal can be stockpiled.
Energy is supply for the rate of production, not for the total amount you can produce.
Stockpiling lets you build up an energy buffer, and even if you run out, excess metal will be stored until the lack of energy is resolved. This would be like stunning units in Starcraft that exceed your current housing capacity, but still allowing them to be built. The basic properties of supply are still present, but overextending is not an immediate concern, which gives players more leeway. This is a bit of a double-edged sword though, since a blunt system is much easier to teach. Players are highly motivated to make a house when their entire production is being held for ransom. Storage makes it harder to correlate problems with their solutions, and people might even use their metal storage for long term storage, rather than as a temporary buffer. So there are legibility downsides to flexibility. C&C games may have found a good middle ground, since a lack of power shuts down your entire base, but it does not block structure production and can be mitigated immediately by selling a structure.
But wait, there's more! Energy powers cloak, charges shields, and lets constructors repair, just to name a few uses. This makes things a bit more complicated as, for example, cloaked units drain more energy while moving. But it still all adds up to some fuzzy concept of supply. A cloaked unit still has two costs; the price of the unit and the energy generators to cloak it. When it dies, you can rebuild it at a discount, or even use the freed up energy for something else.
It is easy to get caught up in the theme, in how much sense it makes for cloaking and shields to require energy. But forget the theme for a moment and just consider how arbitrary this is. Costing supply is a good thing, it makes rebuilding the unit cheaper, and it seems weird to bestow this benefit on only a handful of units. To understand this, I must now reveal the full power of energy. the thing that supercharges its control of pacing and escalation; energy is expensive at the start of the game and becomes progressively cheaper.
Do not be alarmed, the price of energy structures do not arbitrarily tick down over time. That sort of thing is so inelegant as to be near-nonexistent in RTS. Instead, energy becomes cheaper simply because more efficient structures are available later in the game. Players progress from solar panels to fusion generators, and sometimes even singularity reactors. Many games do this kind of thing; Total Annihilation did it with tech levels, but even that is insufficiently elegant. Zero-K just lets players build anything they want, and lets maths do the rest.
The trick is as follows: a 91% built fusion reactor produces zero energy, while the same value in solar collectors produces 26 energy, so the efficiency of fusion is balanced out by the time it takes to start generating energy. Solar production can outperform fusions for quite a while, with the duration depending on how rapidly they are built. This creates a breakpoint where you switch from solars to fusions based on how much income you can dedicate to energy production, and how much time you have for the efficiency to pay off. It is a fuzzier system than tech levels, which is how we like it, since it leaves more room for strategic judgement.
Energy becoming cheaper flows onto everything that drains energy, effectively making them cheaper too. We use this deliberately to push units and mechanics away from the early game. Mostly this means allowing something to be so powerful that it would warp the early game, then adding energy drain to balance things out. Here are some examples:
Cloak is best early on, when there is space to move around.
Tough expensive units rely on repair, but can be hard to answer without a large enough force.
Personal shields do not drain energy because Shieldbots do not need to be worse early.
Reclaim sort of fits the pattern since energy is required to spend the windfall, but this is forced by the rest of the economy rather than being a deliberate decision. Overdrive does not really fit, since it lets energy structures general metal, rather than using their energy as supply. In fact, the diminishing returns of overdrive counteract the cheapening of energy.
I want to avoid the impression that energy is complicated. Many mechanics look complicated when analysed in detail, and while a lot of thought has gone into it, the goal is something that is intuitive and easy to use. Energy is basically supply, primarily for spending metal. Adding one solar per mex works quite well, and another good rule of thumb is to make 20% more energy than metal. Later on it is worth ramping up production to run overdrive, reclaim, and repair. Fusions are good at around 30 income, and singularity reactors are for when you feel extravagant. Energy can be managed quite easily.
Except...
Recall how construction costs three resources, with the third resource being buildpower. It might warrant its own article, but in brief, buildpower is another form of supply. It just happens to be generated locally, rather than globally, and it cannot be stored. So it can be more complicated, but luckily it is also dead cheap. Increasing your metal income costs about 40 metal/income, and energy starts at 35 and can drop all the way to 18 with singularity reactors. Buildpower starts at 18 metal/buildpower, in the form of the static Caretaker, and mobile constructors cost around 24 metal/BP. This is on top of the fact that your commander and factory provide about 3x more buildpower than your base metal and energy income. So play loose with it, having far more buildpower than your income is fine. Just err on the side of mobile buildpower, so it can be sent out to expand, repair, and reclaim.
The idea of supply can be taken even further. What is metal, if not a supply resource for the ability to construct in the first place? Every RTS can be boiled down a single "resource", time, however I am not going to go down that particular path to madness today. For those interested in doing so, ponder this: since constructors cannot build and move at the same time, does moving cost buildpower? If you would rather just spam singularity reactors, here is a bonus graph.
Zero-K uses a flow expenditure system, which is the system of choice for games of the Total Annihilation and Command and Conquer lineages. However, we break from the rest of the TA-like games by paying particular attention to making the economy flow smoothly, in stark contrast to the unforgiving economies that tend to define the subgenre. This is because Zero-K is about fighting the enemy, not about micromanaging your base, and it also demonstrates how flow economies are not necessarily daunting.
A flow expenditure system works as follows:
The player issues a construction order, and the construction begins.
Resources are spent over the course of construction, such that a task which is XX% complete has consumed XX% of its cost.
If you run out of resources, then construction rates are reduced to balance your income with your expenditure.
When construction progress hits 100%, the construction is complete.
For example, if you produce 16 metal/s (metal per second) but your total demand is 20 metal/s, then the each of your constructions builds at 80% (16/20) its maximum rate. Think of it like pouring water into a bucket. When the bucket is full, the construction is complete.
Many games use an upfront payment system as it is the main alternative to flow expenditure. Examining it will reveal why Zero-K uses flow instead, so here is how upfront payment works:
The player issues a construction order.
The order is blocked if the player has insufficient resources to pay the full cost of the unit or building.
Otherwise, the cost is deducted from storage, and a timer starts.
When the timer finishes, the construction is complete.
Upfront payment is a very simple system, and there is strength in that, but using it well can be difficult and time consuming. As we saw in Making Metal, systems of simple discrete actions often end up being more complicated than systems that work more continuously.
Mastering an economy is fundamentally about reducing downtime as any time your factories are not running is wasted time. Upfront payment gives players very few tools to do this, which leads to fights with the UI, and these fights can take over entire games. More specifically, to master an economy you want to keep your money low, and to do that without breaking your keyboard, you probably need command queues.
The saying "keep your money low" is good general RTS advice. The return on investment is so high in RTS, relative to the utility of waiting for more information, that stockpiling is rarely worthwhile. Investment could take the form of expanding your economy, defending it from attack, or attacking the enemy economy, it all helps. Sometimes stockpiling 100 metal to boost out a turret is warranted, but generally, to not spend resources is to fall behind. So how do the two expenditure systems compare? Well, flow expenditure makes having zero money easy, just make sure your demand exceeds your income. Upfront payment makes keeping your money low much more difficult. Approaching the ideal with upfront payment means watching your resources like a hawk, ready to pounce as soon as they hit the threshold required to buy something. This eats up a lot of attention and can even require training to truly master.
Many games have production queues that let players queue up a list of things to be built, regardless of the spending system. Unfortunately, upfront payment queues leave a lot to be desired, as the standard implementation has you pay the full price just to queue a unit. A queued unit is making no progress towards being built, so this is just as bad as having the resources sit idle in storage. These queues are useful for freeing up attention, but they always come at the cost of efficiency, and long queues are terrible. Other upfront payment queues only spend the resources when the task hits the head of the queue, delaying it if there are insufficient resources. This is much more like a UI feature than an Ability, in the language of UI vs. Game World, since it simulates the player clicking the buy button when the threshold is reached. It also allows for infinitely looping queues, which removes a lot of busy work, but has some pretty dire side effects.
The issue with paying when a task hits the front of the queue is with low-money situations. Suppose you want to make an army of cheap infantry and expensive tanks. You queue a bunch of tanks and infantry, then go do something else, only to return to an army of only infantry. The tanks spent all their time blocked at the front of the queue, never reaching their cost threshold, since the cheap infantry would consume those resources first. Even worse, to build anything you now have to cancel all your queued infantry and let your resources stockpile. This is not entirely realistic though, since the only game I know of with this system Warlords Battlecry, and as a fantasy game it lacks tanks. Anyway, flow expenditure is great for queuing since construction rates fall uniformly in low-money situations, guaranteeing a mixed army of infantry and tanks. Flow also allows for infinitely looping queues, so your factories run themselves until you decide to change your army composition.
This all begs the question, if flow spending is so great, why do so many games use upfront payment? Here is what I think.
Flow is a bit more complicated than upfront payment, especially when it is not the expected default.
Flow has a reputation for being a lot more complicated than upfront payment.
Putting anything approaching optimality beyond the reach of most players is often the point.
Upfront payment is a quintessential "easy to learn, hard to master" system, since it makes you do everything manually. This is great for pro players pushing the limits of what is possible, and it also lets newer players slowly build their base without being overwhelmed. Contrast this to flow, which has momentum that keeps going when you stop clicking on it. Upfront payment is like stacking boxes, while flow is like driving a truck. The average player can get a lot more done with flow, but can end up in trouble if they push down too hard on the accelerator.
To be fair, the reputation for complexity is more for the TA-style economies rather than Command and Conquer. C&C only has one money resource and its build rates are high. TA economies effectively have three resources that must be kept in balance. Two money resources; metal, energy, and a third, build power, which is the rate that a constructor or factory progresses production. Construction rates are limited by the most in-demand resource, so stalling (running out of) energy means stockpiling metal until the problem is resolved. However, using up the stored metal requires extra energy, which puts you in danger of wasting energy. Managing these fluctuations can take up a lot of attention, potentially even more than an upfront payment system (depending on the game), and feel quite unwieldy. However, unforgiving fluctuations can be dampened. They are a design decision, not inherent to flow, and one that Zero-K aims to avoid. For starters, overdrive makes it very hard to actually waste energy.
The most complicated part of many TA-like games is their love of seemingly arbitrary metal:energy:time ratios. One unit might cost 109 metal, 911 energy and take 19.6 seconds to build, while another might cost 150 metal, 2100 energy, and take 34.2 second to build. The former drains 5.6 metal/s and 46.5 energy/s while under construction, while the latter drains 4.4 metal/s and 61.4 energy/s. Those are some weird numbers, but what do they mean? They mean you might be happily building the first unit, switch production to the second, then crash your economy right into an energy stall. In many games the stall could even completely disable your metal extractors, adding to the chaos.
Zero-K avoids these economy-crashing traps by setting all costs in a 1:1:1 ratio. A unit that costs 200 metal must also cost 200 energy and 200 work. Build power, which is a constructors' ability to progress construction, is set to nice friendly numbers, such as 5 or 10. Since costs are 1:1:1, a constructors' build power is also its demand for metal and energy. Factories have 10 build power, which means they drain 10 metal/s and energy/s regardless of what it builds, and so any factory would take 20 seconds to build a 200 cost unit. This was one of the very first changes made in Complete Annihilation, and costs were rounded at the same time as well, because balancing the cost of units down to three significant figures is folly.
Flow expenditure with 1:1:1 ratios gives us powerful queues and avoids unforgiving economic complexity, but this was all still a design trade-off. Variable cost ratios can be interesting since they feed back into which resources you focus on collecting. This creates strategic momentum and scouting opportunities, especially in games with extreme ratios such as Starcraft and Age of Empires. TA tends to use ratios for a few special cases in the economy, as well as for general thematic trends, such as hulking ships being metal-heavy, while lightweight aircraft cost mostly energy. I am not sure whether varying ratios and flow is a good combination though, since the complexity ramps up quickly. Also, varying ratios tend to need puzzling out, which leads to long inflexible openings (build orders), which is something else Zero-K tries to avoid.
Parallel production poses a few problems for flow expenditure. Recall how production slows down when your demand exceeds your income. Well, if your demand far exceeds your income, then it can be hard to build anything new. This is like the Warlords Battlecry queue problem, but much more palatable since everything is still built, and it takes an extreme deficit to get into real trouble. There is a subtle issue underneath though, which is that incomplete construction ties up resources, so building many things slowly can be as bad as a leaving the resources unused in storage.
Zero-K, along with many other TA-style games, addresses the parallel production issue by emphasising assisting, which lets multiple constructors pool their build power on a shared task. They can even assist factories, saving you from having ten 90% complete tanks. The extreme deficit problem persists though, and in many games you have to go through your whole base shuffling around or pausing constructors to prioritise anything. This is a clear case of fighting the UI, so Zero-K has construction priorities, which were added all the way back in CA.
Construction priority is a state toggle that let you set what gets first dibs on resources. High priority constructions are satisfied first, so they only slow down if too much is set to high priority. There are three levels of priority, and they can be set on constructors to control how they spend resources, or on construction projects to control how resources are spent on them. Priorities can even be given default values, so you can make metal extractors always be built with high priority. Once we added priorities it only seemed natural to add a reserve system, which lets you set aside resources for high priority use. Just Alt+Click on the resource bar. This is how you might set aside 100 metal to boost out some turrets.
Flow has worked very well for Zero-K. It lets players use proper production queues, and much of its reputed complexity is a decision designers make, not a fundamental part of the idea. Most of the magic is in the 1:1:1 cost ratios, with not-insignificant contributions from round numbers and construction priorities. It is harder to destabilise your opponents' economy, but on the upside, learning how to make a stable economy is much easier. The upside is worth it in our view, because it lets players get on with playing the rest of the game, and very few real in-the-moment decisions (as opposed to preset build orders) about how to grow your economy were lost.
Jumping is old, going back to the early days of Complete Annihilation, which predates Zero-K. It is also a very stable mechanic, to the point where a player from 15 years ago would not see the difference just from using it. In part this is due to its simplicity: just give a unit which can jump a jump order, and it will jump to the location once it is in range. But it is also because surprisingly little has changed.
So why write an article about jumping? Well, while there have been a few changes, each one reveals a further refinement in the design of Zero-K. Even more revealing are the ways that jumping has deliberately stayed the same, in the face of potential changes. So here are four mini-articles on the how, what, where, and legs(?) of jumping.
Which units jump?
Perhaps the most important aspect of any ability is the types of units that can use it. Jump is one of the many abilities associated with a particular factory, in this case the Jumpbot factory, but in an unusual way. Other factories with a unique movement ability, such as the Hovercraft Platform or Spider Factory, have that ability on all of their units, whereas only about half the Jumpbots jump. This makes Jumpbots more like Cloakbots or Shieldbots, which each only have a few cloaked or shielded units. Furthermore, the Shieldbots' Dirtbag jumps, as well as the Recon Commander, and the largest unit in the game - the Detriment. This smattering of jumping is also similar to cloaking and shields.
To see why Jumpbots ended up like this we have to go back to CA, since only commanders and Detriment have gained jumping since then. Jump was an ability exclusive to the Core faction, to mirror Arm's exclusive access to all-terrain spiders. Each faction had two tiers of bot factories, with a few all-terrain options in the higher tier factory. Placeholder and Firewalker, two non-jumping Jumpbots, did not exist at the time, and Moderator existed in the skirmisher role, but with a different weapon. Technically we could have let Moderator jump, its role stopped us.
Jumping is not just a way to move around the map, it is also a tactical ability that bestows a burst of speed. So a jumping skirmisher violates Quant's Rule, since skirmishers are meant to be weak to fast units that negate their range advantage. Jumping is an excellent escape tool that negates this weakness, so Moderator was not given the ability to jump. Firewalker is non-jumping for the same reason, and also because dislodging artillery from awkward cliffs sounds very annoying. Spiderbots lack true artillery for the same reason.
In addition to violating Quant's Rule, using jumping skirmishers also sounds tedious. Jumping with a short ranged unit is a game of risk, reward, and sudden retreats, while jumping with a skirmisher sounds like game of routinely retreating when enemies get too near. Such a thing feels like it could be automated, which also comes into conflict with the idea of fighting your opponent, not the UI.
We considered creating a combined jump and spider factory while CA was being merged into one faction to create Zero-K. The goal was to create a fleshed-out all-terrain factory, and on paper it worked quite well. The only spiders at the time were Flea, Venom, Recluse and Crab, which fill the scout, riot and skirmisher roles, which leaves the raider, assault and anti-heavy roles to be filled by Pyro, Jack and Skuttle. However, this idea did not make it beyond prototyping, and instead we settled on the Jumpbot and Spiderbot factories we have today. I do not recall the exact process behind the decision, but here are some likely factors.
Jumping is a sudden bursts of speed, while spiders can constantly dance around cliffs. These are distinct styles so should be in different factories to let the distinctiveness flourish.
The combined factory would be too full, and too flexible, with all the units it could contain.
It would be tricky to find new homes for all the non-jumpers and non-spiders that we wanted to keep from the rest of the bot factories.
Having two factions that can play very hilly maps, or areas of maps, seems much better for diversity.
Jugglenaut and Crab would fight over the role of the factory's signature unit.
The solution was to add Hermit and Tarantula to flesh out the spiders, and make Widow all-terrain. Redback was added later to let Venom move more towards a raider role. As for the Jumpbots, they are essentially the old CA tier 2 Core bot factory, with a few new units added later.
As for why there are no new jumping units, that goes back to the Zero-K approach to uniqueness. Many sci-fi strategy games use a weapon-chassis approach to unit design, where units can be boiled down to a combination of weapon and movement types. Sometimes there is even an in-game unit designer to make this breakdown explicit. Zero-K can be viewed through the lens of chassis and weapons, but there are so many holes in the matrix, and extra subtleties on top, that doing so is of limited use. Zero-K units aim to be more distinctive than combinations of weapon and chassis, and adding more jumping units for existing roles would work against that. Besides, jumping is primarilly a Jumpbot feature, and there are plenty of mechanics to build other factories around.
Jump physics
Jumping is surprisingly non-physical for a game with unit launchers and Lobsters. A jumping unit follows a set trajectory until it either dies or lands on a building, so unless that happens, it is guaranteed to end up safely on the ground. Its trajectory is calculated at the start of the jump, although the jump will be blocked if it would pass through terrain. This is all very deliberate, to the point where an impulse-based alternative written by the developer xponen was not adopted. This new system used dynamically scripted physical forces to launch and guide units through the air, then slow them down at the other end to avoid taking fall damage. It was essentially a simplified and automated Kerbal Space Program.
The impulse-based system was rejected for the unreliability inherent in its design. The goal of the system was to give units full physics while jumping, which meant that sufficient incoming fire could knock them off-course. Jumping multiple units was particularly risky since they would bump into each other mid-air, and even a slight course adjustment could lead to a unit bouncing away, down a cliff, and into a puddle. But how is this distinct from Lobster lob, which was added much later? Lobster picks up units and physically throws them in a direction, with the only nod to safety being temporary fall damage immunity.
The difference between Lobster and jumping lies in their centrality. Lobster is a somewhat niche midgame support unit, while many jumping units, particularly Pyro and Constable, are built from the very start of the game. As such, jumping has to be much more reliable. A Lobster causing part of an army to bounce down a cliff is recoverable, and to some extent it is the price of using Lobster. Armies are large enough by that point for things to average out. An early Pyro failing to jump up a cliff, or a constructor becoming stuck, would feel really bad and could be game deciding.
The general principle here is that, if you want to build a faction around a mechanic, it had better be reliable. People have to be able to trust their units' basic abilities, since taking even a slim risk of complete failure into account is too taxing. On the other hand, tactics that appear later in the game can afford to have a bit more risk. There are more options later in the game, so using any particular one is more opt-in, and there are more ways to mitigate risk.
As for the unused impulse-based jump code, there is a happy ending. Amphibious floating was originally implemented in the same way as jumping, with a set trajectory. This leaves a lot to be desired, and I could see xponen trying to get more physics into the game, so I suggested that the impulse jump tech be used for floating. This worked great since units bobbing around and bouncing off each other is a great feature for floating, and it cannot fail in the same ways as jumping. Floating is much better for it, and the impulse jump code still exists in the repository, so a modder could even pick it up for use in a game with a different set of goals.
What are jumplegs?
The lack of interaction between jumping and the rest of physics has a few weird effects. Units can jump from anywhere to anywhere, provided it is in 2D range, which includes while flying through the sky after being launched from a unit cannon. Jumping just follows a calculated trajectory, which causes launched units to turn sharply and float towards the ground when they jump. I remember launching Pyros across Victoria Crater almost as soon as Newton was implemented. However, there have been a few problems.
Skuttle is a cloaking, jumping, bomb, which made it a particularly powerful unit to launch. Imagine the Sky Jacks of today, except they are cloaked and 1-shot their target. The best theoretical counter was positioning Hercules, or any other high-flying gunship, above anything important to decloak the Skuttle, and spamming Pickets. This was far too expensive, arduous, and silly, so we considered ways to nerf the tactic. Removing cloak was not an option since Skuttle needs to cloak while jumping for its mundane uses, so instead we removed its ability to jump mid-air. Thus the distinction between jumplegs and jumpjets was born.
A unit with jumplegs can jump, but not from mid-air. Skuttle was given jumplegs, along with some other units that looked like they use legs to jump. Notably, Pyro and Jack were given jumpjets, so retained their utility in unit launchers. This reflects the broader design philosophy of trying to retain as many of the creative combinations of mechanics as possible. It would have been easy to remove mid-air jumping entirely, but instead we surgically patched out the bits that would clearly break the game. Besides, jumping from anywhere has synergy with Placeholder, and saving units that are knocked off cliffs by enemy fire is cool.
Splitting jets and legs also let us make jet break cloaking. This had to happen eventually, but was blocked by Skuttle needing to cloak, since the smoke and fire emitted by jumpjets ignore cloaking. Effects like these can be seen by players, but not their units, which gives players extra information. This leads to a form of fighting the UI where players want to tell their units to shoot at the mysterious smoke, but cannot. In these cases we either remove the effect while cloaking, or make the effect decloak, to bring player knowledge in line with unit knowledge. The former is applied to damaged-unit smoke, which is suppressed for cloaked units for this very reason, but would look silly when applied to jets. The latter, decloaking the unit, was initially why units decloak when they take damage, since projectiles exploding mid-air is suspicious.
The existing jumpers were split into jets and legs on aesthetic ground. Basically, if a unit already had leg animations, then it was given leg mechanics. This was particularly good for units with a wind-up animation, since the animation caused them to actually stop mid-air to do their animation, which was too cartoony even for Zero-K. Detriment jump, which was added later, has a wind-up animation and a rocket jet, so mechanically it has jets and legs. It decloaks when it jumps and cannot jump mid-air.
Recon Commanders was hit the hardest by the addition of jumpjet decloaking, since it can equip a personal cloak module. I recall this being a desirable change at the time though, as cloak made the commanders a bit too slippery. Jugglenaut and Detriment also decloak when they land, since their impacts create a visible explosion.
Where can units jump?
The question of where units should be able to jump is a tricky one, since both extremes lead to frustration. Highly restrictive jumping will cause units to annoyingly refuse orders that it "should" be able to carry out, while unrestricted jumping results in players unintentionally ordering their units to become stuck on impassible terrain. The current system is as follows.
Units cannot jump onto terrain that is too steep, since they would become stuck.
Units can jump onto structures, however, the jump ends when they hit the structure.
Units can jump into water, provided the terrain under the water is not too steep.
Units cannot jump out of the water, except Detriment and commanders, since they are amphibious.
These rules work surprisingly well, and have been tweaked over the years. Originally units could jump out of water but not onto structures.
Jumping onto structures used to be impossible. The issue with allowing it is that a jump trajectory would let units clip completely into structures, making them impervious to enemy fire. However, this had to be solved, since being unable to jump at structures felt like too much of an arbitrary limitation. Jacks were looking silly milling around the bases of terraformed turrets, and a Singularity Reactor in a hole should be more vulnerable to jumpers, not less. So we let jump target structures, but interrupt it as soon as the unit hits the structure. This lets Jacks jump up to get a few hits on a turret on a spire before bouncing back down, limiting its damage output by its jump recharge.
Interrupting a jump when it hits a structure leaves units at the mercy of physics, so they could bounce off the structure and fall down a cliff, but I do not recall any complaints. Perhaps it is because such a jump is a deliberate decision, and one that rarely has to be taken early in the game. People naturally give jump orders on open terrain, when it is available. The bouncing is also much more restrained than full impulse-based jump, since the jump is always interrupted very close to the destination.
It also used to be possible to jump out of the water, and there was even the idea of making jumping units fully amphibious. Jack could already be used amphibiously since melee weapons fire underwater. However, the idea of giving jump a small amount of underwater utility was dropped because it was too tedious. Babysitting units across the sea by chaining jump was a form of fighting the UI, which we resolved by removing the possibility. The idea of full amphibious movement was dropped because jump already bypasses cliffs, so if it bypassed large bodies of water, then there would be too few ways to make a hard barrier against it.
Units can jump into water because it seems like something they should be able to do, and there are more upsides than downsides. Sometimes it is worth saving a Jack or Jugglenaut by telling it to jump into the sea. Rescuing such units is just a matter of a little terraform, to give them a small platform of dry land to jump from. In theory these units can jump in any direction, so it stands to reason that they should jump into the sea if it is to their advantage to spend some time stuck underwater. Jumping into the water accidentally is bad, but water is visually distinct enough to make this very rare.
There would be times when units would want to jump onto terrain that is too steep, where they would be stuck until they jump out again. However, terrain steepness is harder to make out than water, no matter how clearly it is shown, and there are far fewer advantages, since the main purpose of water is to block projectiles. Ability restrictions are about balancing the feel of units being able to freely use their abilities against the risks of each application. A niche use for an ability that has a high risk of being accidentally misused is not worth allowing.
Distilling some principles
Hopefully that was a useful insight into some aspects of jump design. Most of these articles involve dredging the principles out of my subconscious, which means at the outset I am not entirely sure how the concepts will be carved up. So I would like to take a moment to summarise a few of the new ones we saw.
Jank Escalation - Mechanics that are central to some core set of units need to be reliable, so players can trust them. More niche mechanics, or those that show up later in the game, can have more risk involved. So jumping is reliable while Lobster is not.
Disciplined Physics - Physics is great, but it should not be used at the expense of other considerations. Zero-K does not set out to apply the maximum level of physical simulation so usability often takes precedence, as mentioned in Physics vs. Formulas.
Surgical Excision - Interactions that would break the game should be removed without affecting related mechanics that have not yet been shown to be broken. Doing so would hinder the creative toolbox feel of the systems. So Pyro can still jump mid-air.
Practical Verisimilitude - Units should feel like they are free to use their abilities in ways that make sense within the game world as it is presented. But units with no restrictions can be told to do very stupid things, so applications with low utility and a high risk of misuse are restricted. So units can jump into the sea, but not onto steep terrain.
Of course, we also saw a few ways to use Quant's Rule and Not Fighting The UI, but they are going to show up everywhere and already have their own articles. Perhaps it is time to start a glossary.
Projectiles in Zero-K are physically simulated, meaning that shots fly through the air and collide with anything that gets in the way. This is standard for games inspired by Total Annihilation, but Zero-K leans into the mechanic hard, and embraces the implications. Not content with taking only one thing to the extreme, Zero-K also has a strong aversion to armour classes and damage bonuses. We completely avoid damage formulas of the type that let pikemen deal extra damage to horsemen, or tanks take reduced damage from rifles. The goal is to create a game world that is visceral and intuitive, something that is best engaged with as a physical space, rather than as an abstract collection of numbers.
Complete Annihilation steadily removed the damage formulas inherited from Balanced Annihilation, and it looks like BAR might head the same way too. These were mostly things like commanders taking extra damage from turrets, and various EMP resistances. These things suffer from being confusing and hard to remember, especially in a futuristic setting with no historical precedent or clear notion of infantry to guide intuition. Besides, completely removing damage bonuses is just so elegant, and making it work is a fun challenge. So we saw damage bonuses as a crutch, they solved problems in BA, but we could use physics to come up with better solutions.
To stack hubris on hubris, we also wanted the units of CA to have roles. Roles in the sense of pikemen beating horsemen, which is a bit more detailed than the roles found in Total Annihilation and most of its progeny. TA-style roles tend to be big "theatre of war" style designations, with roles like "bomber", "fighter", "scout" and "artillery". These roles are about dominating air, land or sea, or about projecting force from one domain to another. Artillery even fits if this description if you consider bases and open ground to be different domains. In any case, all this theatre-on-theatre action left little room for diversity within a domain. This limits the options for combat within a domain, and in particular, land armies designed to fight other land armies could end up quite similar. The generic "army unit" would change as the game escalated, but at any given point the unit selection felt slim.
Armies in Zero-K should consist of multiple unit types, and it should be possible to exploit deficiencies of enemy armies, all within the ground vs. ground game. So Zero-K is designed around roles. Fast light raiders beat ranged skirmisher, which beat slow beefy riots, which beat fragile raiders. Whether these are "hard counters" or not mostly depends on how you define "hard", but I think they are mostly soft counters. Units can often beat their counters with a slight numbers advantage and a good engagement. We still have the "theatre of war" style roles, since cross-domain interactions are great too, but these counters tend to be harder. Artillery is very good against static defense, and fighters are very good against bombers.
How does Zero-K have such roles, all without any bonus damages? What makes the hoseman-equivalent particularly bad against the pikeman-equivalent? In many cases, the answer is physics. Game physics, not real world physics, as the goal is depth rather than realism. Physics means the way units move around the world and interact with each other. It is things like unit positions, ranges and speeds, weapon area of effect damage, and how projectiles move. This is not new, every RTS has physics, and without it they would essentially be spreadsheets. Physics is fundamentally what gives players any reason to care where anything is. Every game with time, space, and simple rules linking them together has some sort of physics.
Not only is physics used by every RTS, it is often a large part of their design and balance. Horsemen counter archers because speed physically counters range, and any arrow-resistant armour is just icing on the cake. Zero-K just takes this a step further, eschewing damage modifiers and relying more on physics instead. This is a design constraint, a rule we have set for ourselves, because it means that units need to be physically different to have different roles. Spearmen can be designed to counter horsemen with physics alone, but it becomes tricky when it is time to implement a physically similar swordsmen. There is still plenty of freedom though, since quite a bit can be done with basic stats such as speed, health, damage and range. On top of this, Zero-K uses projectile physics to a much greater extent than the average RTS.
In most games, units shoot projectiles as a form of delayed damage, and to animate the act of shooting. A standard projectile will hit its target, and nothing else, unless the target does something weird (such as dying or, in some cases, teleporting). In Zero-K, each projectile is an independent entity with its own physics. Plasma cannon shots arc through the air, lasers fire in straight lines, and missiles try to track their target. If a projectile hits something, anything, then it explodes and deals its damage. The visuals are used to convey all this, rather than just being an animation to show that a unit shot.
Projectile physics increases the importance of units' speed and model size. Many longer ranged weapons shoot slow or inaccurate projectiles, which gives small fast units a chance to dodge while closing in. The slow rockets of most skirmishers are tuned to hit large assaults and riot units. In turn, the even slower projectiles of assaults and artillery units give most targets a chance to dodge, with the notable exception being turrets. There is space for soft counters here. Skirmishers can still beat fast raiders, but it is more a matter of creating a blizzard of rocket fire than having individual skirmishers fire at and hit individual raiders.
The whole "Physics vs. Formulas" dichotomy is about which parts of the game are more important. It is about whether players should chose units based on how they move and shoot, or by damage formulas that determine what they deal the most damage to. Zero-K is on the side of physics because it is cool, and it seems so intuitive. Players can see whether a projectile hits a unit and extrapolate the results for other projectiles and units of a similar speed. In comparison, formulas can be arbitrarily complex, taking into account armour, unit type, weapon type, and upgrades. Enough of a reliance on formulas can make the physics of a battle irrelevant, which is a shame because it is the part of the game that players can interact with moment-to-moment. Exploiting a formula is more down to unit choice than unit usage.
Great mechanics have more than one purpose, and physics of Zero-K has many. A big one is to fight Lanchester's square law, which essentially says that an army of twice the size is four times as powerful. All games have to grapple with this law, that is, unless they are happy with players just rolling a big ball of units around the map. The trick to fighting Lanchester's square law is that the "square" only applies in ideal situations, so to fight it we just need to move away from the ideal. Most games do this via units of inconveniently short range, to limit what can fire, and area of effect damage, as it deals more damage to dense armies - armies which are dense because everything is trying to get into range. Zero-K makes use of these approaches, but uses projectile physics to add even more.
Unguided projectiles act a bit like area of effect damage, because dense forces take more hits. Consider how a large force of Ronin will fire more rockets than a smaller force, but also run into more rockets. At least, unless the Ronin spread out, but that risks moving some too far away to shoot. This all fights Lanchester's square law, but in a dynamic way where there are tradeoffs between dealing and taking damage. A small force can hold off a large one for a while if the larger army is unwilling to take any damage. It also makes attacking from multiple angles even better, since it reduces your own density. But perhaps the most notable effect of simulating projectiles comes from allied units blocking each other.
Recall that projectiles hit every unit regardless of its allegiance, and this is actually a rare mechanic even among games inspired by TA. It means that a dense blob of units loses most of its damage to blocked lines of fire. This further encourages armies to spread out in a line. Density and facing is very important, since a good flank can leave most of an army unable to return fire, even if they are in range. High density is not all bad though, since it concentrates power and prevent units being surrounded by enemy raiders, so there is a constant tradeoff. Still, Zero-K tends to have lower density armies than the average game, which encourage spread out battles across multiple fronts. The advantages of low density even play a central role in the escalation from cheaper to more expensive units.
Projectiles have a lot of parameters, which in turn allows for a large range of weapon types. To cut down on complexity, most weapons fall into one of three categories.
Plasma cannon that fly through the air in a ballistic arc.
Unguided rockets or homing missiles. Some are fired directly at the target, while others arc.
Lasers and lightning that instantly hit and require a direct line of sight to fire.
These weapon types results in a variety of tactics, since each type has its own relationship with unit density. An arcing projectile allows units to clump and still be able to fire, but still leaves them vulnerable to return fire. An army armed with lasers or homing missiles needs to spread out to fire, but the inability to miss removes an opponent's incentive to spread out. Being unable to miss is quite powerful, but remember we still have non-physics balance tools, so such units tend to pay for their accuracy with poor raw stats. Direct fire weapons are also particularly weak to being blocked by terraformed walls.
This all sounds great, hopefully, but it also sounds fiddly. Luckily, Zero-K is built on fighting your opponent, not the UI, so we are careful to keep the physics manageable. We avoid implementing unnecessarily fiddly weapons, and provide powerful controls to deal with everything else. Line Move lets plays create formations and dial in their density with ease, and becomes their default way of issuing orders. Attack Move lets players tell short ranged units to jink around to avoid projectiles, and longer ranged units to move away from enemies that try to close range. Anti-Bait lets players tell units with big important shots to not waste their time trying to hit a speedy raider. And it almost goes without saying that units have the intelligence not to fire when allies or terrain is in the way.
I have been a bit misleading, and it is time to come clean. Zero-K has a damage formula. To start with, some units have an armoured mode that causes them to take 33% damage. I am not sure whether this counts though, since the multiplier applies uniformly. The most common damage modifier is for anti-air, which deals only 10% of its damage against ground units. But anti-air is not even capable of firing at ground units, which is a fine mechanic provided the target categories are clear. The anti-air damage modifier is mostly just insurance against anyone figuring out how to work around this restriction. Then there are shields, which have to convert status effect damage such as EMP and slow to ordinary damage. This is done at a rate of 33%, which is a bit arbitrary, but it has to be less than 100% because status effects have very high raw damage. Finally, gauss and flamethrowers deal extra damage to shields, because something something piercing something something... there is actually no excuse.
It gets worse though, as some units shoot through allies, or even terrain. And not in a consistent way, like how flamethrowers burn through everything in their path. Nukes and tacnukes pass through allies because having one explode on an errant plane sucks (although when they hit an enemy plane it is hilarious). Anti-nukes pass through everything for similar reasons, but also because they do not know how to try again if an anti-nuke misses its target. A few other weapons here and there pass through allies, although in most of these cases units still avoid shooting at allies. There is a difference between colliding at allies and firing at allies. Some units with fast projectiles avoid the former but not the latter, which makes them behave as if their shots would hit allies. Some edge cases are bad, and the best uses of physics know when to relax and let things feel good. In short, know when to dial back the jank, because sometimes it just sucks.
Speaking of jank, weapons can impart force on units, pushing them around. Clearly this means there should be gravity gun weapons that just push or pull units, and there is no reason not to let it target allies. The result is unit cannons made of Newtons (the gravity gun turret) and terraformed ramps, and it is my favourite incarnation of a unit cannon. Anything can be fired, anything, provided you have the resources and skill at engineering. Such a thing would get repetitive if it were common, but somehow it hits a sweet spot. It is often impractical, but sometimes it is time to fling Jacks into the back of the enemy base.
Gravity guns and edge cases aside, the goal of Zero-K's physics is to evoke a particular feel. The game world should feel like something that should be engaged with as a physical space, rather than an abstract collection of numbers and circles. Games can end up feeling quite abstract. Put more enemy units in your circles (ranges and spell radii) than your opponent manages to put in theirs, and you win. Formulas can vary the effect and suitability of each circle, but this just mixes up which circles are used, rather than change the fact that everything is circles. Zero-K fundamentally disrupts the circles, deforming them into weird and wacky shapes, the consequences of which are too numerous to cover in one article. But it is sure to come up again and again.
