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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Index of Cold Takes[zero-k.info]

This week's cold take is early, unusual, and short because Ludum Dare[ldjam.com] is this weekend. Ludum Dare is a game jam: an event where individuals or teams of people make games in a short period of time. They tend to run for a few days to a whole week, depending on the jam, and teams are given a short prompt or "theme" to incorporate into the game. There are many game jams these days, I just do Ludum Dare for the schedule and because I like rating other peoples' at the end.

Everyone with an interest in making games should give game jams a go. The actual event only takes a weekend, although a bit of upfront investment to find an appropriate engine goes a long way. The barrier to entry is fairly low, and I even think game jams are a great way to learn certain aspects of programming and design. A jam is a microcosm of project management, where choices made at the start of a project tend to come back to bite you at the end. This process is particularly instructive when there are only three days between the choices and their consequences. And by the end, you get a game out of it.

I especially recommend game jams to anyone working on a long-term game, such as Zero-K, because speedrunning the whole process can clarify your progress on the longer game. It also lets you experiment with new ideas and flex your creativity, which probably helps prevent feature creep. Besides, making games is a matter of practise, and as the Go master said to the game designer: "make your first fifty games quickly".

I got involved in game jams through the Spring Cabal, a group of Spring developers that used Spring in several Ludum Dares between 2015 and 2018. The release pages for most of them were lost in the LD site rework, but builds can still be found in the organisation's GitHub repositories[github.com]. Dominic (aka Shadowfury333) was also kind enough to document most of them on his YouTube channel.

• LD 32 - Gravitas
  
• LD 33 Warmup - Hunted
  
• LD 33 - Area 17
  
• LD 34 - FLove
  
• LD 35 - Parts Needed
  
• LD 43 - To The Last Drop

The only video missing is LD 42, My Cube[github.com], which I recall being a tower/unit defense style game about defending an iceberg. I only made it to a few of these weekends, so only worked on Hunted, Area 17, and To The Last Drop. The main organiser was gajop, and with the gradual disintegration of the Spring developer community, plus the difficulty of organising team across multiple timezones, we were less able to get teams together.

I am really pleased with To The Last Drop. The theme was "Sacrifices Must Be Made", so we thought up the idea of defending a town using magic powered by the lives of the townsfolk. It turned out to be a game, with a beginning, middle, and end, which kills idle players, but otherwise let you play around with different approaches. The success of To The Last Drop is possibly why I went on to make ten more games with people I knew locally, solving the timezone problem and making the event more social. For these games, we used the 2D Lua game engine LÖVE[love2d.org], since I have a lot of Lua experience, and because 2D art is easier to produce.

You can check out the games on my games page[ldjam.com]. We tend to make games that sit somewhere between puzzle and sandbox, which might be called problem-solving or "strategy" games. But we are also careful to give the games goals, and make the basic actions of the game inherently fun. You can see bits of Zero-K in many of them, in the way they are about mastering simple systems with emergent complexity. I think they are all quite solid, at least the "Post Jam" versions (make sure to click the right download), so my recommendations would depend on what you are looking for. Here are a few:

• Seeds of Civilisation[ldjam.com] is a bit like asteroids, but with planets and space police.
  
• Vivere Computatrum[ldjam.com] is a take on simple colony management, and even has a goal.
  
• Regular Railway[ldjam.com] is the most puzzle-like: Pipe Dream but Trains.
  
• Warp Trash Flotilla[ldjam.com] is absolute mayhem.
  
• Crocodial[ldjam.com] is about spinning a wheel of spells as fast as possible, but you are the wheel.
  
• Compact Domain[ldjam.com] is another puzzle game, this time pretending to be a city builder.
  
• Euclid's Elementals[ldjam.com] can be hard to get into, but the payoff is you get to feel like a wizard.
  
• To The Last Drop[ldjam.com] lets you be an "evil" wizard, and shows off what you can do with Spring.

Another common feature of our games is hard mode, since otherwise we risk subconsciously adjusting the difficulty upwards as we get better at the game. It also lets me play the game after the jam, just to push the systems to their limits and see what is possible. This approach is probably why we end up with open-ended problem-solving games rather than discrete single-solution puzzles: you can't really play your own puzzle games. Anyway, I hope this makes up for the lack of a more Zero-K-focused topic, and perhaps you end up having fun with a few games, or even have a go at game jamming.

Index of Cold Takes[zero-k.info]

The diversification of bombers over the past year has been great, but it also highlighted some problems with a few mobile anti-air units. This patch tries to carefully resolve these deficiencies, and to shift things slightly away from Phoenix and towards Magpie. The two bombers finally agree on rearm time.

This update coincides with an AI update and the addition of around two dozen new maps. Try them out, perhaps against the new AI, and give feedback on your favourites. If instead you prefer 1v1, check out Fight Club[zero-k.info] later today (Saturday) at 1900 UTC, and on every first and third Saturday for the rest of the year.


Gremlin creeps back towards its old low price.

• Cost 130 -> 120

Tarantula contributes more to mixed anti-air defenses.

• Damage 260 -> 270

Flail hits sooner.

• Range 800 -> 820
  
• Missile spends 16.7% less time flying straight up.

Magpie is a bit cheaper to support.

• Rearm time 15s -> 13s

Phoenix takes noticeably longer to shoot twice.

• Rearm time 10s -> 13s

These maps have been added.

• Wanderlust 2.1[zero-k.info]
  
• Rustcrown Canyon 1.3[zero-k.info]
  
• The Rock Jungle 2.1[zero-k.info]
  
• Crystallized Plains 1.1[zero-k.info]
  
• Hide and Seek 2.2.3[zero-k.info]
  
• Hellas Basin v1.4[zero-k.info]
  
• Flats and Forests v2.2[zero-k.info]
  
• Aurelia v4[zero-k.info]
  
• Moonshine Run v1.0.1[zero-k.info]
  
• The Tartar Steppe v1.1[zero-k.info]
  
• Pinch Point 1.03[zero-k.info]
  
• Canis River v1.4[zero-k.info]
  
• Salt Reef 1.1[zero-k.info]
  
• Ancient Bastion Remake 0.5[zero-k.info]
  
• World In Flames v1.8[zero-k.info]
  
• Kings Assault v1.3[zero-k.info]
  
• Great Divide V1[zero-k.info]
  
• Sinkhole Network v1.1[zero-k.info]
  
• Scylla and Charybdis 1.1[zero-k.info]
  
• Tau12[zero-k.info]
  
• Crescent_Bay_V2[zero-k.info]
  
• Jade Empress 1.41[zero-k.info]
  
• Esker Creek 1.3[zero-k.info]
  
• Hades Ponds 1.1[zero-k.info]
  
• Isidis crack 1.1[zero-k.info]
  
• Feast of Hades 1.0.1[zero-k.info]
  
• Hera Planum 0.91[zero-k.info]
  
• The Ditch Remake 0.5[zero-k.info]

• Updated the skirmish AI.
  
• Experiment with new lighting on some energy structures.
  
• Added focal depth hotkeys for the depth of field widget.
  
• Added team selection to the cheat sheet (top left with cheats enabled).
  
• The startbox editor can now apply box transforms and save them directly to files.

• The skirmish AI no longer crashes if it somehow gains and then loses a factory plate.
  
• Minor fixes for French translations.
  
• Fixed some tips for planet Blackmire.
  
• Fix tiny movement stutter when line-moving over wreckage.
  
• Fix a graphs bug that would sometimes overcount army losses.
  
• Fix spec team change when selecting unseen enemies.
  
• Fix a rare teleport bug
  
• Fix (ie remove) fog effect on a few maps.
  
• Fixed structures with move commands giving up on them before finishing their morph.

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]