Zero-K maps set surprisingly few hard restrictions on unit movement. Instead, many of them mainly use terrain to influence the value of locations, as well as how easy they are to reach and defend. There is also plenty of space for huge cliffs and vast seas, but what really sets our terrain apart is the subtle effect of each hill and valley. This is before even considering how explosions and terraforming change the terrain during the game. Terraforming elevates terrain, but it requires a strong foundation of important and nuanced terrain to make any sense. So for now it is time to look at how Zero-K uses terrain.

Maps can be decomposed into three main parts.

• Shape: How high the terrain is at each point on the map.
  
• Texture: The colour, reflectivity, and graphical roughness painted onto the terrain.
  
• Resources: The metal spots, geothermal vents, and reclaimable rocks and trees.

The shape defines how units interact with the map, while the resources provide overall strategic goals. Well-designed terrain also gives players instrumental goals, such as to hold an important hilltop. The texture is purely visual, but vital for making the map look good and be easy to understand.

One of the more striking features of Zero-K terrain is how solid it is. Very little can pass through a wall of solid rock, but in most strategy games units are able to shoot through cliffs with ease. But beyond physical projectiles, there is also the sense that the three-dimensional shape of terrain really matters. Terrain in the average strategy game amounts to little more than a binary mask that neatly splits the map into walkable and non-walkable. A sense of height is often limited to layers of plateaus, with ramps between them, which may block sight or impose a penalty for shooting up to a higher level. Zero-K terrain is not divided into levels, it varies smoothly, and the penalties flow from natural features of terrain, such as hills being opaque and difficult to climb.

Weapons being blocked by terrain is so important that many are designed around whether they fire in an arc or need a direct line of fire. Lasers travel in straight lines, so are blocked by small hills, while a large mountain might block all but the highest-trajectory plasma cannons and missiles. This effectively gives us a dynamic and directional cover system, one which depends on understanding the shape of the map rather than a more gamey type of bonus. This form of cover gives shorter ranged armies ways to close in on their targets, for example, by walking in a ditch or hugging the lee of a cliff. Cresting hills and ramps is also really impactful, since units climbing a hill can only shoot at the other side once they reach the top. However, everything in the valley below can shoot as soon as a target appears against the horizon. This creates shifting asymmetries all over the map, resulting in a complex system of positional advantages.

Units at the top of a hill are quite exposed, but the upside is that they can see everything around them. Terrain blocks line of sight and radar, which makes high places ideal for scouts and radar towers. Ridges create radar shadows that allow for stealthy army movements until they are crested. Even units that can shoot over terrain will need something to spot targets on the other side. A seemingly empty hill may actually be home to a cloaked scout, spotting for artillery below.

Hills are also a good place to put many units, since a common weapon type, the plasma cannon, has ballistic trajectory. This gives it a range bonus when shooting down and a penalty when shooting up. Lasers do not fare so well, since their spherical 3-dimensional range causes them to lose range while shooting up or down, while missile range is unaffected by height. This is important for deciding which units to use where. When attacking up a ramp you might want to use missiles, while attacking downwards is best done with plasma cannons, all else being equal.

Units suffer a speed penalty when climbing terrain, which makes hills even more attractive. This can be a doubled-edged sword, as retreating back up a hill after a downhill assault is also more difficult. In addition to the tactical uses, bumpy terrain also slows units down while moving around the map. Terrain can also form hard boundaries by having slopes that are too steep for units to climb. This depends on the slope tolerance of the unit: vehicles have low slope tolerance, bots (walking robots) have moderate slope tolerance, and spiders are able to climb everything.

Slope tolerance is a hard threshold in an otherwise smooth system, which is a dangerous thing to expect players to handle. We only use two thresholds, one for bots and one for vehicles, to keep things simple. As far as I am aware these values are unchanged since Total Annihilation. Maintaining compatibility across maps is too important and any change would break a lot of maps. Mappers need to be careful to stay away from the slope tolerance thresholds, lest we end up with frustrating pathfinding on spotty or ambiguous ramps. These thresholds can cause trouble for highly realistic terrain, since walkability can be quite hard to parse. Ideally the map texture helps players understand the terrain, and avoid misleading them. Many maps navigate the pitfalls without issue, and they tend to use slope rockiness to delineate the slope thresholds.

One of my favourite things about our terrain is that it makes the whole map playable. Every minor bump is potentially relevant to how units behave, there are no purely aesthetic set pieces off in the distance, away from the game. For example, a craggy cliff has more surface area than a smooth cliff, so it takes longer for a spider to climb. If terrain looks different, it plays different. This lack of "pure asethetics" may be seen as limiting artistic freedom, but I see it as tying art and mechanics together in a way that benefits both. The precise cragginess of a cliff rarely matters, but when it does, it emphasizes the mapper's stylistic choices. It makes the map feel like a distinct landscape, rather than a mere picture of a landscape. The mountains in Zero-K are not just eye candy that units have to walk around; their shapes really matter when the artillery starts flying.

The result of all this is that two maps can have a similar resource layout, be fully walkable by bots, and play completely differently. Many 1v1 maps fit this description, with the differences coming from how hills slow movement and block weapons as well as line of sight. The natural battle lines and strong points created by hills and valleys give each map a distinct feel. We have even considered a mapping contest based on a single resource layout, and with the restriction that bots must be able to walk everywhere. Vehicles are rarely able to drive everywhere on maps, since their slope tolerance is so low, but this in itself is an important part of giving the factories different roles.

Working through the implications of solid and nuanced terrain was a long process, with blocking weapon fire alone introducing many broken interactions. Not the fun type of "broken", such as putting Outlaws in holes, but uninteresting exploits such as making turrets effectively invulnerable from certain angles. It took a lot of attention to detail to sort out all the edge cases, and I have not heard of any for years, so perhaps we got them all. The process was greatly accelerated by terraforming, as a player with the ability to freely manipulate the map is nowhere near as benevolent as the original mapper. We get a lot more out of terrain manipulation, but that topic needs its own article.

Index of Cold Takes[zero-k.info]

Cloaking is awesome. At least, some types of cloaking. Depending on who you ask. Let me start again.

Cloaking is polarising. Some love it, some hate it, and being on the receiving end of an invisible strike can feel pretty terrible. To complicate things further, the specific mechanics of cloaking vary wildly between games. Sometimes cloaked units are near-immune to damage and can fight with impunity, while cloaking in another game might be dispelled by the slightest touch. But where it gets really interesting is how a single set of cloaking mechanics can be used in different ways, within the same game.

Zero-K has a lot of cloaking, which equates to a lot of ways for it to go wrong. In addition to personal cloak, cloaking fields were added early in Complete Annihilation as a way to differentiate Arm from Core, and we have been nerfing them ever since. Over time, we started thinking about cloaking in terms of two distinct use cases.

• Tactical Cloak: The enemy knows where your units are, but has trouble engaging them.
  
• Strategic Cloak: The sneaky sort of cloak, where the enemy is unaware that you have units in the area.

Dark Templars from Starcraft are quintessential tactical cloakers. It is abundantly clear when a base is full of Dark Templars, from all the dead workers and sci-fi noises, but they cannot be fought without being revealed by a special detector-type unit. This example relies on Starcraft having very few ways to damage cloaked units (they even remain cloaked while fighting), but the concept of tactical cloaking applies across all games. Tactical cloaking in Zero-K, and many other games, depends on uncertainty in the precise location of a cloaked unit. Sure, units should shoot at "empty space" if they know a cloaked unit is there, but it does not take much uncertainty to make such a shot highly questionable.

It could even be argued that Starcraft lacks "true cloak" (if not for the fact that arguments about the "true" anything tend to be pointless), since units reveal themselves to the enemy with a faint shimmer (except for burrowed units), which probably helps cloak feel fair. Mechanics like these are unavailable to Zero-K though, since such a disconnect between player- and unit-knowledge is against the rest of the design.

Fighting the UI thrives on situations where the player knows something, but is unable to convey this knowledge to their units. Cloak is relatively easy to dispel in Zero-K for this very reason, with the goal being that a unit should only stay cloaked when there is real uncertainty about its position. To start with, structures cannot cloak, since nobody wants to walk their units through how to shoot at a cloaked turret. Units also decloak when they fire, since the sudden appearance of a projectile is a dead giveaway, and when they take damage, since a projectile disappearing mid-air is also quite suspicious. There are non-suspicious ways to take damage, such as walking through fire, but they also decloak for consistency and to provide cloak with more counters.

Cloak is also pierced by straying too close to the enemy, with "close" being defined by the decloak range of the cloaked unit. This range is an important balance factor for personal cloak, with some personal decloak ranges being quite large. Other units have a consistent size-based decloak range, for when they enter a cloaking field, and cloak fields also apply this range to personal cloakers, if it is an improvement. Cloak field projectors cannot have their decloak range reduced, and mobile projectors have large decloak ranges to keep tactical cloaking in check.

Proximity-based decloaking allows Zero-K to completely avoid passive long-ranged detection abilities. Active detection abilities exist, such as napalm missiles and Sparrow's reveal-on-death ability, but cloaked units are usually countered by a combination of base design and patrols of light units. We like the nuance involved in this system, it has more play in it than having units that passively negate all cloaking in an area.

A lack of widespread detectors allows strategic cloaking to be more viable late into the game. This is surely the dream of everyone who hears about cloaking, they want to be James Bond; sneaking into the enemy base to blow it up. This is great, but Zero-K also wants to be a fun multiplayer game, and having your base blow up out of the blue is not great. So strategic cloaking is tuned mostly for hiding army movements within your base, and in no-mans-land. Still, infiltration is the dream, so it is always on the table. Our goal is just to make letting a cloaked army into your base feel like an avoidable mistake, and besides, Antinukes still provide sneaky infiltrators a way to blow up an entire base.

As with most definitions, there are edge case that fuzz the distinction between tactical and strategic cloaking. A cloaked army might start out with strategic cloak, turn tactical when they strike a target, then shift slowly back to strategic after the survivors disengage. Particularly popular uses of strategic cloaking can even take tactical aspects when become standard enough to anticipate. DotA's Smoke of Deceit is a great example of this, since it has a massive decloak radius, so is clearly meant as a strategic cloaking tool, yet skilled opponents will anticipate smokes and respond when they feel they are a strong possibility.

Edge cases aside, what is the point of these categories? The point is that player feedback tends to revolve around adverse events, and events involving cloaking tend to cleanly fall into one of the two categories. Sorting feedback is great, but where categorisation really pay off is in how it informs the sort of balance change that might be required. A problem with strategic cloak suggests nerfs to speed or detection range, as with Conjurer after it gained a cloaking field. Problems with tactical cloak suggest nerfs to recloak time and the area that a cloaking field can cover.

As alluded to earlier, cloaking fields have been overwhelmingly nerfed since their debut. In part this will be down to them being figured out, but there was probably also an initial bias towards making them powerful. Units used to decloak for much less time when they took damage, and cloak fields have been steadily getting smaller. Structures used to be cloakable until we realised that cloak is boring or frustrating on most structures. Cloaking your Antinukes and Singularity Reactors is obviously good, but removes the whole point of these structures being juicy weak points.

Tactical cloaking with cloaking fields has caused more problems than all other forms of cloaking. Personal cloaking is fine, since any issues with it are tied to individual units, and balancing units is relatively straightforward. Even the Phantom's ability to fire without decloaking has been balanced. Cloaking fields are a different beast though, since they give cloaking to everything, and our principles prevent us from carving out arbitrary exceptions. Skirmishers and artillery have been an issue, since cloaking them can make it too difficult to retaliate. To solve this we nerfed the recloak time for non-personal cloak to six seconds. This still lets armies make a cloaked surprise attack, but leaves the units decloaked as they fight.

Bombs are the most exciting units to put under a cloaking field, and the trickiest to balance. We have tended to nerf the field projector itself, decreasing field radius and movement speed, while increasing decloak range. The aim is not to remove cloaked bombs, since that would remove the joy of figuring out a cool combo, then realising that it works. Rather, the goal is to give the defender something to do. This is part of making cloak feel fair; the interaction between attacker and defender should not end as soon as the cloaked units are revealed. In the case of bombs, finding and destroying the cloaking field is a consolation prize. This is part of what makes Skuttle so hard to balance compared to Widow: they work alone.

In addition to structures being uncloakable, cloaking is disabled in a few more cases. One is the fact that shield-projecting units cannot cloak. This is a unit intelligence thing; if you can see the shield, then you should be able to pinpoint the unit that is projecting it. Technically the shield could cloak too, but then projectiles would collide mid-air, or shields would have to pop into existence when the unit decloaked, which would look messy. Another exception is cloaking underwater; fully submerged units cannot cloak. This is mainly due to a lack of good ways to detect underwater units by conventional means, and because underwater units already require sonar to detect.

The relationship between cloaking and sonar raises a good point; is cloaking just an extension of line of sight? Vision, radar, cloaking and sonar could be unified under the banner of How Not To Be Seen. In fact, most of what I have said about tactical and strategic cloaking could apply to line of sight and radar. There are times when a lack of vision makes it hard to fight, and other times when a lack of vision hides the fact that there is anything to fight. So there are parallels, but also many differences, the exploration of which will have to wait for a future article.

it is finally time to talk about weapons, starting with how they are fired. The weapon design space is huge, thanks to projectile physics, and we put it to good use. But such freedom is a double-edged sword, since much of the full design space contains frustrating or incomprehensible mechanics. There are interesting games in this space, but Zero-K is first and foremost a strategy game, which means it needs to be stable and predictable enough to reward planning. So, to combat the full freedom of physics, we installed a few guard rails around weapon design; a loose set of rules that, if followed, limit how badly a weapon can break the game.

There are rules for many aspects of weapon design, but those around aiming and firing are some of the most important. The rules consider the following three aspects of our design goals.

• Intelligence - Aiming and firing are just abilities, and units should be good at using their abilities.
  
• Predictability - Players should be able to learn how units aim and what causes them to fire.
  
• Verisimilitude - Weapons should feel like they can be used in ways that make sense within the observable fiction of the game world, rather than just being a bundle of arbitrary mechanics.

As you might have guessed, projectile physics causes most of the conflicts between these goals. This specific set of problems is mostly limited to descendants of Total Annihilation, since projectiles have a minor role in other types of games. The standard RTS projectile is a animation and a short delay between firing and dealing damage, since they are guaranteed to hit their target, and only their target (unless something unusual happens, such as death or teleportation). This limits just how stupidly units might misuse a weapon, and it allows weapon fire to be quite predictable.

Total Annihilation probably used projectile physics to enhance verisimilitude, but I would disagree that this means other games inherently lack it. Every RTS simplifies many aspects of reality, and simplified projectiles are quite popular. How closely a simulation hews to reality is only loosely related to the experience of a reasonably consistent and believable game world. There are, of course, many players that seek out strict realism, but Zero-K does not simulate projectiles to be realistic. We use physics to make intricate, yet fundamentally simple, mechanics that reward intuition and creativity. But I digress, physics generally seems to cause problems for the goals above, rather than solve them.

Physical projectiles are hard to use. You shoot at the enemy, but then the enemy moves and the projectile hits empty ground. So you shoot where the enemy is going to be, but they dodge the other way, or you miss due to innate weapon spread. Units do a decent job at leading their shots, but many still miss. This makes deciding when to shoot of utmost importance, but this decision has to be quick, which risks making it unpredictable.

To make matters worse, the sense of verisimilitude subscribed to by Zero-K says that, ideally, weapons only provide two in-world abilities:

• Change where the weapon is aiming.
  
• Fire the weapon.

In other words, we think of units as having the same basic abilities as a player in a first person shooter. In practice the implementation does not go that far, but we do at least let units blindly fire at the ground, since a cloaked bomb might be there. But even this limited ability means that, in theory, players could manually control every shot, which raises the spectre of fighting the UI. So units have to be smart enough for players to not need to resort to manual control.

We could write some whizz-bang first person shooter-level AI, but then battles would amount to little more than watching units careen around the screen. This brings us back to predictability, so perhaps intelligence and predictability are fundamentally opposed. Worry not, the deadlock can be broken by imposing limitations upon weapons that are designed to make them simpler, so that units can be reasonably smart without breaking the "intelligence budget" of predictability. These limitations tend to be quite gamey, beyond the realm of pure physics, which causes trade-offs with verisimilitude.

Consider the ubiquitous range ring and its implications for homing missiles. A Fencer can only fire missiles at enemies within a circle around itself, but an enemy that dances just out of this circle will still be hit, which is a bit weird. What happens if we let just the goals argue it out?

Verisimilitude: That's ridiculous! The missile can demonstrably hit units beyond its arbitrary "range". Fencer should be firing in more situations, at everything that it can physically hit.Intelligence: Hmm... sounds exploitable, we don't want to fire at things barely within physical range. Borderline targets could (and should) just step back and let the missile run out of fuel before impact.Predictability: We could just only let missiles fire at structures, not units. Those are sure to stay still.Verisimilitude: That's super arbitrary!Intelligence: How about we use the target's max speed, accounting for slow and EMP, hill climbing, facing, angular velocity....Performance: uhh...Predictability: And how is anyone meant to know which combination of factors will or will not result in a Fencer firing a missile?

At this point we might placate verisimilitude with some mumbling about "missile lock range", but background lore is no match for what players can observe ingame. Besides, we have many ballistic weapons that could also shoot a bit beyond their range ring, and this cannot be explained by any sort of "missile lock". So the the fact is that verisimilitude lost this battle, and the best we can do is make these situations as simple and consistent as possible.

The verisimilitude of Zero-K demands that units can do everything that they look like they are capable of, predictability demands whatever is simplest to communicate to players, and intelligence only cares that the resulting ability is hard to screw up. Designing a weapon with these constraints in mind looks a bit like this:

• Imagine the ideal form of the weapon, packed full of verisimilitude. A Glaive holds a gun in its hands. It can actuate its arms in any direction and pull the trigger at any time. It is a real robot.
  
• Next consider the proper use of the weapon. Should Glaives spend their time shooting wildly into the sky? Probably not, unless an enemy is flying overhead.
  
• Then impose as many behavioural or mechanical limitations as you like, provided that you only cull the stupid or pointless ways that the ideal weapon might have been used. These should help the unit avoid being stupid. Shooting into the sky is almost always pointless, so Glaives only do it when there is an enemy flying overhead.
  
• Finally, add a small set of standard limitations, such as range rings. Consistency is key here, since the goal is predictability, and arbitrary limitations hurt verisimilitude the most.

In practise, the process is not as simple as working through four steps. Most limitations affects all three aspects simultaneously, and sometimes you need to revise the ideal version of the weapon to make the downstream implementation workable. It is also possible to start at the implementation, then work backwards to figure out what sort of ideal weapon would result in it.

One of the most important corollaries of the process is that weapon behaviour cannot depend on the existence of a target. This is known as the No Void Ray rule, as it was developed back when Starcraft 2 had a unit that gained damage the longer it fired. The unit was redesigned in the first expansion, probably because shooting your own stuff is allowed in Starcraft, but incentivising players to do it looked a bit silly. In any case, Void Ray would not even make it into Zero-K, since there would be nothing stopping it shooting into the sky when idle. Maintaining its damage bonus is smart, so we could not in good conscience prevent it from doing so. This would make the mechanic pointless, so we would avoid adding it in the first place.

The same rule applies to lock-on mechanics, or mechanics that penalise a unit for switching targets. A weapon shooting down a line of enemies should not care which unit is "aiming at", since it all involves aiming in the same direction. Any mechanical distinction would drag the interface abstraction of "targeting" into the realm of the game world. There should be no "best command" among those that cause the unit to aim and fire in the same direction. Commands are meant to help the player manipulate the game world, not be themselves be something that require optimisation.

There are ways around the No Void Ray rule. For example, the weapon could apply an escalating status effect on the target that causes the target to take more damage from that type of weapon. This would look a bit like a Void Ray, and even solves the problem of charging by shooting at your own stuff. However, this particular mechanic would be discouraged by Physics vs. Formulas, but in general there are often ways to make a design work within the weapon design guidelines.

Perhaps it is best to think of the weapon design rules as a set of guarantees, rather than a set of restrictions. Working within the rules keeps Zero-K consistent and delineates a relatively safe part of design space. These restrictions can aid creativity, and not only via the usual refrain, but because the safety guarantees free up brainpower that would otherwise be spent making sure that an idea does not completely break the game. For example, the rules inherently disallow designs that incentivises players to shoot at their own base. So the rules can be bent, but more care is required, because the rest of the game is built on their assumptions.

Anti-air weapons are the most blatant violators of idea that weapons can be fired in any direction. Being so blatant is great actually, since a large and well-defined exception feels much less arbitrary. Every weapon falls into one of the following categories.

• Weapons that can only shoot at aicraft. Units with these weapons have "Anti-Air" in their two-word role description.
  
• All other weapons. These weapons shoot at aircraft if they have a decent chance of hitting. Melee weapons can and do hit planes, when the wielder is thrown high enough.

We could have avoided creating the special Anti-Air category. One approach would be to make aircraft significantly slower or flimsier, to allow their best counters to be weak enough to hit ground as well. Unfortunately this would make air units more like ground units, or just weaker overall, violating Quant's Rule. We also considered giving anti-air weapons upwards-facing firing arcs, to allow them to shoot into the sky without hitting the ground. This has poor implications for predictability, as an inverted cone would give anti-air variable range depending on terrain and cruise altitude, as well as make for great artillery against cliffs. An inverted cone also just kick the can down the road, as it raises the question of why this amazing weapon cannot be built at an angle.

None of the alternatives to Anti-Air were as good as defining a simple category that gives air the freedom to be powerful and different. That said, most games with air have Anti-Air, so perhaps the more interesting part of Zero-K is the lack of strict Anti-Ground. This choice is a type of design minimalism, we started with projectile physics and then added as few mechanics on top as seemed necessary. We could have widespread Anti-Ground, either as a targeting category, or just by making planes fly so fast and high that nothing but Anti-Air could hit them, but the game works fine as-is.

Truth be told, ground units shooting at planes is a feature, not a bug. The goal is not realism, the goal is the feeling of a fairly consistent world, and we like the extra interactions between different parts of the game. In a sense we picked our flavour of verisimilitude because we like where we end up when taken to its logical conclusion. But now it feels like this article is about to fold back on on itself. Just remember, for future articles or discussion, that Zero-K units are generally allowed to aim their weapons and fire at whatever they want, provided they agree to avoid using this freedom to do anything too pointless or stupid.

This week we're back to Sprung's series on unit improvement mechanics missing from Zero-K. After Mighty Morphing, it's time to tackle veterancy. This one still exists, well, sort of.

Already in Zero-K's oldest ancestor, Total Annihilation, units could gain veterancy via kills. The TA interface was fairly cryptic as to what exactly this meant: it provided no further information beyond adding the single word "Veteran" when mousing over units with at least 5 kills. Those of us who spent days shelling enemy bases with Big Berthas often noticed the improved accuracy. With a lot of effort it was possible to discover a minor increase in health as well. Frontline combat units were out of luck though, with veterancy being quite hard to obtain and having barely noticeable effects.

Zero-K is not constrained by the TA engine though, it runs on Spring (now Recoil), which expanded upon veterancy from early in its development. So by the time Complete Annihilation came around, veterancy did three things:

• Increase the health of the unit.
  
• Reduce the reload time of the unit's weapons.
  
• Reduce the inaccuracy of the unit's weapons.

Spring also moved to a fairer system of doling out experience: damage dealt is counted rather than kills, and the cost of the attacker and defender are taken into account. This means a cheap glass cannon like Glaive can rack up a lot of experience by shooting at a commander, while a Detriment can destroy whole armies without learning much. In a sense, veterancy depends on how well a unit is expected to do, given the resources invested into it. Higher veterancy units also gave out more veterancy when damaged, and the bonuses were applied smoothly with formulas rather than at set thresholds. Veterancy was more attainable and impactful, but this revealed problems.

Consider increased health, at certain health thresholds a unit starts taking extra shots to kill. On its own this is fine: C&C games, where veterancy grants both health and damage, tend to make anti-infantry units such as Tanya deal either 90% or 110% of basic infantry's health in damage per shot, specifically so that it flips between taking 1 or 2 shots depending on the shooter's and/or the target's veterancy. One of the things that prevents such elegance in ZK is that the rock-paper-scissor relationships between units are not as sharply delimited or as closely followed. You can't have simple rules like "basic infantry with 2 chevrons can survive a commando hit" if there is neither basic infantry nor commandos, nor discrete chevrons for that matter. Role counter relationships such as raider (roughly corresponding to basic infantry) and riot (Tanya) exist, but there is massive variety within them. Players would have to learn and memorise a huge relational spreadsheet of how each of Zero-K's dozen raiders fares in a fight against any other raider at any given pair of ranks to stay competitive, not to mention all the other unit types.

Reload time caused even more trouble, since time is actually discrete. In layman's terms, this means that reload times have to be in steps of 0.033 seconds. Again, raiders tend to be affected by this the most, as their fast firing weapons don't have much wiggle room. Glaive has a reload time of 0.1s, which is three steps of 0.033. From there, you can only reduce it to two steps, which represents +50% more fire rate. This is too steep! Another effect is that some units with slow projectiles were designed to land their projectile just before their reload finishes. This is a crude form of overkill protection, since if the target is dead you don't need to shoot it twice. A slight improvement to reload meant the unit would waste the follow-up shot on a unit that was just about to die.

Inaccuracy was usually the least problematic of the three, since most units tend to be perfectly accurate. But some are inaccurate on purpose, and a mandatory increase in accuracy would drastically redesign the unit on the fly, leaving you with something potentially useless for its original role. For example, an accurate Tremor fails to damage most of its usual area of effect, making it useless against cloak or wide terrain deformation. (As an aside, the original CA Tremor was just a tiny Disco Rave Party on wheels.)

Specific issues aside, all veterancy bonuses further reinforce snowballing in an already snowbally genre. Losing units makes your army weaker, but with veterancy it also makes the enemy army stronger. This necessitates some way to avoid even battles snowballing into victory after a few early pickoffs, either by diminishing the advantage or facilitating comebacks. C&C seems to achieve it largely by having units counter each other very hard, such that even elite units cannot hope to stand against their counter; there is also a cap on veterancy level so a unit cannot grow into infinity. Warcraft and DotA heroes give more experience and take longer to respawn when killed at a higher level, and each level is progressively harder to attain. Of course we could come up with a decent system, but is the extra complexity worth it? Besides, ZK already gives you a little extra for killing enemy units; but where other games do that via veterancy, ZK gives you wreckage to reclaim. This may not feel as cool as getting elite units, but it is such a deep and elegant mechanic we are quite happy with it.

Another reason to avoid veterancy bonuses is that simple stat bonuses affect formulas rather than physics. C&C again has a decent approach there: veteran units that reach the highest "elite" rank sometimes get an improvement in behaviour in addition to raw numerical stats. For example, heavy tanks get splash damage, or RA3 infantry gets immunity to dog stun. But at that point you become something more, a different unit in some ways, which should be reflected in its visuals. Rank icons, the way they are used in every other RTS, are way too salient for mere stats, and too un-salient for behaviour differences. The main hurdle here is that ZK artwork is essentially a loose bunch of assets collected from a wide gamut of volunteers over years, and there is simply no manpower for introducing such extras. Historically we actually had some models with a handful of progressively stronger looking variants, but that was just a drop in the ocean with barely any consistency. This is also one of the big reasons why we don't have research - a stronger unit needs to appear stronger visually as well, whether via research, veterancy, or any other mechanic. What you see is what you get.

Soon enough, stat gains from veterancy were removed, and technical capabilities were fairly low at the time so it wasn't really possible to implement things like weapon type changes. But veterancy is cool, we must have it! As hinted in the article on morphing, the solution was to let units with enough veterancy morph into whatever was a bit stronger and looked vaguely appropriate, and then sometimes not even that. Flea morphed into Glaive, sine they both lived in the "cloaky" factory at the time, i.e. Arm T1 KBot. Glaive morphed into Reaver, then Knight. Knight morphed into Crab, since Knight lived in the "spider" factory, Arm T2 KBot. This chain ended at Detriment. Many units could upgrade this way via veterancy, and many upgrade paths stayed well after factions were merged and factories shuffled.

People loved this! The fantasy of a Flea evolving into Detriment seemed really cool. Unfortunately, it remained a fantasy. Sure, people could do it in games vs AI, and there is one known case in PvP where a top 10 player did it as a show-off when toying with a first-timer, but chain-morphing never really happened in competitive games. There were just a handful of viable morphs that people aimed for. But in addition to being slapped onto effectively random units without any prior design, there were all the problems of morphing, and veterancy made it extra bad because it was so reactive. When your Knights get countered by skirmishers, Crab is the perfect answer - but you cannot plan for your Knights to get enough veterancy. You can merely hope one of them randomly happens to survive in combat long enough, and great power swings should not come from such unreliable sources.

Ultimately, these veterancy-based morph options were removed as well. As a fun fact, this revealed a minor factory design problem, which led to the creation of Redback. Spider did not have the "DPS riot" role filled by any spider at the time, but Flea was so cheap that you could reliably get one to high enough rank to morph straight to Reaver by shooting anything for about two seconds. The hole in the lineup became evident after losing access to Reaver, so Redback was quickly thrown together to fill it.

Modern ZK units still gain veterancy, represented by rank icons above them. Mechanically, it does absolutely nothing (beyond inspire modders). But getting icons makes players intuitively feel good and rewarded, so we keep it. Often though, players start to suspect that there isn't actually any benefit to veterancy, and they ask questions. Should I aim to gain veterancy? Should I protect my veterans? To which we say: yes! The effect of getting ranks is that your enemy no longer has the units you had to kill to get those ranks, and this is already something that directly helps your goals. Veterancy is also a nice way to explicitly gauge how well a unit is doing, though there is some bias against categories of units like artillery and superweapons that often shoot into the fog of war, since in order to prevent leaking information, only visible damage is counted.

The final clue to why we avoid rewarding veterancy can be seen by looking at high skill WC3 or DotA gameplay. And after all, what is levelling heroes if not an extreme case of veterancy? In both these games, you often want to kill your own units just to prevent the enemy from getting experience. In DotA the metagame is optimised so that each hero on the team gets the "correct" amount of experience (and gold, which comes from killing enemies as well so can also be considered a soft form of veterancy), with supports sometimes forgoing it in favour of cores.

In ZK we anticipate problems and immediately bite whatever bullets may appear in the future. The powerful UI would allow you to squeeze quite a lot out of veterancy optimisations such as selective self-destruction to prevent enemy veterancy, and holding fire so that units with worse scaling don't "steal last hits" from the better ones. High skill ceiling? Definitely. Mostly obsoleted by automation? Maybe. Do we want to find out, and possibly lead players into the weeds of optimising this kind of engagement minutiae? Rather not.

Index of Cold Takes[zero-k.info]

Revenant was brought back from the dead just over a year ago, but it lurked in the background until the appearance of combat engineers. Killing these newly-popular commanders in two shots let people really explore what Revenant could do, and most of it looked fine, so the Revenant nerfs focus on early game power. One thing that ended up not being fine was Revenant spires, so its missiles now explode after a short time rather than fall to the ground.

With Revenant moving towards a healthy place, it is time to revive another tricky unit. Scallop is the candidate this time and it is a dangerous unit to buff, so the changes are aimed squarely at it being a better riot. It now 2-shots individual Ducks and can stand toe-to-toe with similar riots. On paper it is still worse than Reaver, but knowing Scallop it will break the game anyway, so look forward to it.

The last release was a bit too recent for many features to roll in. A notable fix is for aircraft wing trails, and a notable feature is the random selection of custom music albums, as well as the ability to play mp3s.



Scallop is much better against Duck and can even fight Ripper and Reaver.

• Range 264 -> 285
  
• Aim speed increased by 50%
  
• Reload time 0.8s -> 0.96s
  
• Damage 23*9 -> 28*9
  
• Maximum burst increased by 21.7%, DPS increased by 0.7%
  
• Spray angle increased by 20%
  
• Area of effect 32 -> 64
  
• Reduced area of effect damage falloff

Revenant no longer overshoots and no longer 2-shots Engineer Commanders.

• Speed 135 -> 130.5
  
• Reload 9s -> 10s
  
• Damage 220 -> 210
  
• Missile burn time 5s -> 2.8s
  
• Missiles blow up when they run out of fuel

• Increased Buoy and Bulkhead auto-float depth to match their requirements.
  
• Added overkill prevention for Scallop shotgun.
  
• Renamed Scallop Flechette to Heavy Shotgun to match other shotguns.
  
• Added an option to choose music albums randomly (thanks Helwor).
  
• Custom music tracks now can now be mp3s.
  
• Made Trinity reload time match its animation.
  
• Tweakdef errors now appear in the infolog.
  
• Applied forced 60 fps vsync for ATI compatibility, and renamed the vsync option.

• Fixed giant Tank Foundry model radius, which could disrupt jumping units.
  
• Fixed aircraft wing trail emit points shifting around incorrectly based on unit velocity.
  
• Fixed spectator panel positions when they are loaded while not in full view mode (thanks Helwor).
  
• Fixed set AI start position game options.
  
• Fixed final value alignment in graphs that go negative.
  
• A few campaign fixes (A unit pic, Solar, and Brutal on Old Kam, thanks Mach565).

Every game has to start somehow, and strategy games start with players acting before they know what their opponent is up to. I call this phase the setup, and in it, players tend to build up their base and deploy some forces, all without any outside interference. To be clear, the setup is everything that happens before contact with the enemy, or in other words, before you can make decisions in response to your opponent. Under this definition, giving player a free scout can make the setup relatively short.

Games with more of an economic focus tend to have relatively long buildup periods, but mitigate it with the aforementioned scout. Total Annihilation-style games are on the more economic end of the spectrum, but lack this mitigating factor. They start players with a lone slow commander, which often has to build up some economy before it can afford to make a factory and a scout. This makes for a long setup, which was disliked by the Complete Annihilation developers, so we set out to shorten it.

Before looking at solutions, we should first dig into what we were trying to solve, and ideally tease out the problematic bits. We also need to know how to measure success, which motivates the following question: just how long is the setup in any given game? The answer is a bit fuzzy due to the nature of "outside interference". Consider a 1v1 in modern Zero-K, technically you could plop an Airplane Plant and immediately send a Swift across the map, all in about 20 seconds. Both sides now have a good idea of what the other is up to, so they have left the setup.

But hold up, what about when a Swift doesn't fly over your base 20 seconds into the game? In this case, your opponent did not plop air and yeet a Swift, which is technically information. So, have you left the setup? No, because I want to get more out of this definition than that. The key is that Airplane Plant into Swift reveal is a terrible opening, so almost nothing is learnt by not observing it. In general, negative observations should be treated in terms of degrees of certainty. Seeing nothing for 30 seconds is fairly normal, so reveals essentially nothing. Seeing nothing for three minutes is much more concerning, and might warrant some blind anti-cheese measures. Likewise, if people invariably put a turret in a particular position, then scouting that turret means nothing.

In short, the setup is about as long as it takes to narrow down the other side's behaviour from "they could be doing almost anything". As for what people spend this phase doing, it boils down to the following.

• Deciding what they want to have at the end of the setup.
  
• Executing that decision as optimally as possible.

The execution part raises some red flags in the context of Zero-K design, since in the absence of an opponent, failures of execution are caused by fighting the UI. As an aside, this is why orders can be queued before the game, and why factories automatically play their unpacking animation. The time spent unpacking gives players a chance to click on their factory and tell it to build something, without worrying about wasted time.

This analysis of the setup reveals an aspect that we wanted to retain: the decision making. Ideally these decisions embody strategy, creativity, and customisation, which are important to Zero-K. Being "natural" is also important, and a brief setup phase is much more organic than some sort of pregame force deployment menu. The fuzzy boundary between the setup and the rest of the game is also quite neat. So the goal was to shorten the setup without removing the decisions.

Our first solution was the Boost mechanic. Commanders were given a personal supply of resources that was spent at a high rate, represented as a depleting red ring. This let players quickly boost out a factory, a bit of economy, and a few units. It sped things up, but was too creative. Players would transport allied commander across the map to boost out turrets in the enemy base. Other strategies involved teaming up to boost out a sizeable army from a single factory, which was very effective against teams which had spent most of their boost on other things.

Boost rushes hammered home something we already knew about team games: factories are a waste of resources. What are the chances that an eight-player team needs all eight factories, when there are only two or three natural fronts? Very low, but spending the whole game assisting an ally factory is boring, so very few people did it. It would happen in tournaments, or be "abused" by the occasional clan stack, but people in public games decried it as "cheap", and it got old quickly.

The general principle here is that people will optimise the fun out of games. In response, games need to have fun solutions to their goals, to encourage people to play in fun ways. The goal of competitive RTS is to win, so good strategies should also be fun strategies. The standard TA approach of having each player spend their valuable initial resources on a factory, just to have fun, violates this quite badly, and boost made it worse. So we went back to the drawing board.

The boost rush cemented a new rule for design, that factory ownership is a requirement for fun, so our next experiment was to just give everyone a free factory. This turned out to be enough, and as such the "Facplop" coupon has existed unchanged for something like 16 years. It mostly solved the setup problem, although we also increased innate commander income. A bit over one mex and two solars "moved into" the commander over time, making it easier to use your factory from the very start of the game.

Facplop did not completely kill assist rushes, as they would still crop up from time to time, but now in the form of players reclaiming their free factory. We could not just make factories cheaper, reducing the amount of metal from reclaim, because that would work counter to factories as factions. We were also unwilling to make the free factory unreclaimable, or to give it a reduced reclaim value, as that would be arbitrary.

Thankfully, the new assist rushes tended to be just barely on the edge of viable. Nerfing them was mostly a matter of balance tweaks, and sometimes we could even just wait for a counter to be popularised. The new rushes were so much worse because reclaim costs buildpower, only yields metal. This meant that energy structures had to be built to spend the extra metal in a timely fashion, sapping the rush of most of its power. Only Paladin rush required a notable change, which is how the Strider Hub ended up with a grid requirement.

Looking back at our reasons for shortening the setup, I sometimes wonder whether we made it too short. We may have missed the utility in giving newer players more breathing room, or in enforcing a form of break between matchmaking games. I even find fun in the execution challenge of the first ten minutes of an Age of Empires game, although I would not want to grind it competitively. The overall trend in RTS seems to be agreeing with Zero-K, particularly with the way the buildup phase of Starcraft 2 was shortened over the course of its expansions. Perhaps it all goes back to respecting the players' time. If we assume Zero-K shortened its setup by one minute, which seems like an underestimate, then doing so has personally saved me four whole days. The savings must be immense over the whole community.

Index of Cold Takes[zero-k.info]

Likho has a new model by brunocb, giving it a proper singularity bomb. This update also has many fixes and a few balance changes. Some of the fixes are due to an engine update, such as a decades-old bug that caused reverse-built units to sometimes try to slide off the map. On the balance front, Bulkhead now has a bit more range than Stinger, Duck is a bit better, and Disco Rave Party spins faster.


Duck is no longer the equal-slowest raider.

• Speed 90 -> 93 elmo/s (no longer matches Bandit)
  
• Missile range 235 -> 232 (matches Bandit)
  
• Missile turn rate increased by 16% so it reliably hits Dart.

Bulkhead is more sturdy and can safely shoot at Stinger.

• Stays deployed while mid-air
  
• Range 600 -> 640
  
• Sight range 660 -> 700

Crab and Bulkhead can deploy mid-air.

Kodachi is killed in one fewer shots by Dagger.

• Health 680 -> 660

Disco Rave Party has all its bearings replaced.

• Base turn rate increased by 25%
  
• Maximum fire rate increased by 6.7%
  
• Spin-up rate increased by 18%
  
• Increased minimum turn rate by 25%
  
• Can turn without spinning down so far, as a result of the above.

• Added new Likho model (thanks brunocb).
  
• Added optional radar colour in LOS and fog stripes, under Settings/Interface/Map/Radar Color.
  
• Added animation-stun to most striders. They no longer return to a neutral stance while stunned.
  
• Guarding units can now be automatically set to lower selection rank under Settings/Interface/Selection/Filtering (thanks Amnykon).
  
• Improved overdrive payback tooltip.
  
• Added metal shared, energy excesses, and energy shared graphs.
  
• Mods can now include their own modoptions files.
  
• Reordering factory queues no longer forgets Alt-insert.
  
• Cloaked units no longer try to shoot at unseen mexes.
  
• Free-For-All games are now not counted for ranking immediately, rather than being discounted when the server restarts (thanks Shaman).

• Fixed rally points of factories with structures right in front of them.
  
• Fixed units not deploying when built without a factory (eg Imp burrow and Bulkhead deploy).
  
• Fixed overlob prevention vs. jumpjets.
  
• Fixed a shadow bug caused by UI scaling.
  
• Slowed Detriment can no longer be stolen by transports.
  
• Fixed defense range circles for ballistic projectiles (thanks Helwor).
  
• Fixed Djinn deployment when told to stop while stopping.
  
• Fixed being able to click twice to start a skirmish game.
  
• Fixed reverse-built nanoframes sometimes sliding off the map (thanks marcushutchings).
  
• Fixed queuing dense line moves (recent engine bug, thanks marcushutchings).
  
• Fixed structure ground decals persisting after death (recent engine bug, thanks marcushutchings).
  
• Fixed an issue with action registering (thanks Helwor).
  
• Made UnitLeftRadar more consistent (thanks Helwor).
  
• Terraform construction can no longer catch fire.
  
• East-facing morphs no longer result in West-facing units.
  
• Fixed lingering noammo icon on wreck tooltips.

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 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 these 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 (provided fewer than three nukes are launched simultaneously). 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
  
• Odin (just after this article went live)

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

Index of Cold Takes[zero-k.info]

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?

...right?

But that is a topic for another week.

Index of Cold Takes[zero-k.info]