Zero-K News

Why does Zero-K have energy? The previous article stopped just short of asking this question, but it is well worth asking. Continuing on, everything costs equal amounts of metal and energy, so it would seem simple enough to drop energy from the equation. Doing so would certainly make the economy smoother. Look at the Command and Conquer franchise, it seems to do just fine with one resource. But hold on, that is not quite right, since C&C has another resource, power, which plays much the same role as energy in Zero-K. Both resources are used to control the pace of escalation in their respective games.

Energy in Zero-K is like houses in Age of Empires, or Supply Depots in Starcraft. Fundamentally, these resources act as an expandable limit on some other aspect of the game, while being fairly unlimited themselves. The big difference is that houses limit the size of your army, while energy limits your rate of production. But we can call them both supply resources, and the effect of such a reason is to make it more expensive to build something for the first time, since infrastructure is needed to support it. Or to give it a more positive spin, supply provides a discount for rebuilding something up to its previous size. Many resources fit the supply mould once you see the pattern.

Consuming supply is generally a good thing, as units would prefer to do so than cost an equivalent amount of resources. Consider the Supply Depots in Starcraft, which cost 100 minerals and produce 8 supply. Now consider two variations on the Marine, if we ignore things like build times and hard supply caps, which is more powerful?

• The original Marine that costs 50 minerals and 1 supply.
  
• A modified Marine that costs 25 minerals and 3 supply.
  

A point of supply costs 12.5 minerals, so the converted cost of each Marine is 62.5 minerals. Notably, the full price only has to be paid to expand your army beyond its previous size. If your army dies, then you only need to pay the base minerals cost to rebuild. The modified Marine much cheaper in this case, so it would usually be considered more powerful. Of course, factors such as the army cap and the build time of Supply Depots would make the original Marine better in some cases, but the general point holds. This is what it means for supply to act as a discount on rebuilding.



The same supply dynamic happens Zero-K, just with production and energy, rather than armies and houses. Consider a bare bones economy, with just solar collectors and metal extractors (mexes). A mex makes +2 metal while a solar makes +2 energy. All construction costs the same amount of metal as energy, so every single bit of metal has to eventually be paired with the same amount of energy, if it is to be spent. This makes solar collectors act as a supply structure for mexes. Increasing your total metal income, for the first time, is more expensive than rebuilding after a raid.

Supply, in any game, exists to slow players down as they try to blast through the early stages of the game. It stops aggressive Starcraft players executing unbeatable all-in rushes with unreasonably large armies, and it stops Zero-K players greedily grabbing every single metal spot in an expanding cloud of constructors. This is vital for a game with income so strongly tied to territory, since the openings of such games can devolve into an all-out land grab. Overly explosive expansion runs the risk of determining the winner via early economic superiority, which feels bad and makes it hard to reach the midgame. Mexes have had their cost adjusted over the years with this balance in mind.



Metal extractors were quite cheap in Complete Annihilation, costing as little as 50 metal, but their cost rose to 75 fairly early on. Mex cost peaked at 90 metal in Zero-K and it has since dropped to 85. It takes approximately one solar, costing 70, to support a mex, so taking a new metal spot costs 155 in total, and 85 to rebuild, provided the solar is sitting safe in your base. It can be even cheaper though, as dead mexes leave 40% of their cost in wreckage, so rebuilding can only cost 51 metal. This might not seem like much, but a 100 metal discount on rebuilding adds up and stabilises the early game. Recovering from a raid would be much harder without this discount, however, reducing the cost of mexes to compensate would lead to explosive expansion. The game could probably be rebalanced with the discount removed, probably involving weaker raiders, but it would be a game of less back and forth, since losing a mex would be inherently more impactful.

There are many ways to make a supply system. The most common implementation has you try to build a unit, hear a voice yell "Construct additional Pylons", and then has you sit on your hands until a pylon is built. Many people find this frustrating, and it looks a lot like fighting the UI, so Zero-K opts for a more forgiving approach. The main differences are:

• Energy and metal can be stockpiled.
  
• Energy is supply for the rate of production, not for the total amount you can produce.
  

Stockpiling lets you build up an energy buffer, and even if you run out, excess metal will be stored until the lack of energy is resolved. This would be like stunning units in Starcraft that exceed your current housing capacity, but still allowing them to be built. The basic properties of supply are still present, but overextending is not an immediate concern, which gives players more leeway. This is a bit of a double-edged sword though, since a blunt system is much easier to teach. Players are highly motivated to make a house when their entire production is being held for ransom. Storage makes it harder to correlate problems with their solutions, and people might even use their metal storage for long term storage, rather than as a temporary buffer. So there are legibility downsides to flexibility. C&C games may have found a good middle ground, since a lack of power shuts down your entire base, but it does not block structure production and can be mitigated immediately by selling a structure.



But wait, there's more! Energy powers cloak, charges shields, and lets constructors repair, just to name a few uses. This makes things a bit more complicated as, for example, cloaked units drain more energy while moving. But it still all adds up to some fuzzy concept of supply. A cloaked unit still has two costs; the price of the unit and the energy generators to cloak it. When it dies, you can rebuild it at a discount, or even use the freed up energy for something else.

It is easy to get caught up in the theme, in how much sense it makes for cloaking and shields to require energy. But forget the theme for a moment and just consider how arbitrary this is. Costing supply is a good thing, it makes rebuilding the unit cheaper, and it seems weird to bestow this benefit on only a handful of units. To understand this, I must now reveal the full power of energy. the thing that supercharges its control of pacing and escalation; energy is expensive at the start of the game and becomes progressively cheaper.

Do not be alarmed, the price of energy structures do not arbitrarily tick down over time. That sort of thing is so inelegant as to be near-nonexistent in RTS. Instead, energy becomes cheaper simply because more efficient structures are available later in the game. Players progress from solar panels to fusion generators, and sometimes even singularity reactors. Many games do this kind of thing; Total Annihilation did it with tech levels, but even that is insufficiently elegant. Zero-K just lets players build anything they want, and lets maths do the rest.



The trick is as follows: a 91% built fusion reactor produces zero energy, while the same value in solar collectors produces 26 energy, so the efficiency of fusion is balanced out by the time it takes to start generating energy. Solar production can outperform fusions for quite a while, with the duration depending on how rapidly they are built. This creates a breakpoint where you switch from solars to fusions based on how much income you can dedicate to energy production, and how much time you have for the efficiency to pay off. It is a fuzzier system than tech levels, which is how we like it, since it leaves more room for strategic judgement.

Energy becoming cheaper flows onto everything that drains energy, effectively making them cheaper too. We use this deliberately to push units and mechanics away from the early game. Mostly this means allowing something to be so powerful that it would warp the early game, then adding energy drain to balance things out. Here are some examples:

• Cloak is best early on, when there is space to move around.
  
• Tough expensive units rely on repair, but can be hard to answer without a large enough force.
  
• Personal shields do not drain energy because Shieldbots do not need to be worse early.
  

Reclaim sort of fits the pattern since energy is required to spend the windfall, but this is forced by the rest of the economy rather than being a deliberate decision. Overdrive does not really fit, since it lets energy structures general metal, rather than using their energy as supply. In fact, the diminishing returns of overdrive counteract the cheapening of energy.

I want to avoid the impression that energy is complicated. Many mechanics look complicated when analysed in detail, and while a lot of thought has gone into it, the goal is something that is intuitive and easy to use. Energy is basically supply, primarily for spending metal. Adding one solar per mex works quite well, and another good rule of thumb is to make 20% more energy than metal. Later on it is worth ramping up production to run overdrive, reclaim, and repair. Fusions are good at around 30 income, and singularity reactors are for when you feel extravagant. Energy can be managed quite easily.



Except...

Recall how construction costs three resources, with the third resource being buildpower. It might warrant its own article, but in brief, buildpower is another form of supply. It just happens to be generated locally, rather than globally, and it cannot be stored. So it can be more complicated, but luckily it is also dead cheap. Increasing your metal income costs about 40 metal/income, and energy starts at 35 and can drop all the way to 18 with singularity reactors. Buildpower starts at 18 metal/buildpower, in the form of the static Caretaker, and mobile constructors cost around 24 metal/BP. This is on top of the fact that your commander and factory provide about 3x more buildpower than your base metal and energy income. So play loose with it, having far more buildpower than your income is fine. Just err on the side of mobile buildpower, so it can be sent out to expand, repair, and reclaim.

The idea of supply can be taken even further. What is metal, if not a supply resource for the ability to construct in the first place? Every RTS can be boiled down a single "resource", time, however I am not going to go down that particular path to madness today. For those interested in doing so, ponder this: since constructors cannot build and move at the same time, does moving cost buildpower? If you would rather just spam singularity reactors, here is a bonus graph.



Index of Cold Takes

Zero-K uses a flow expenditure system, which is the system of choice for games of the Total Annihilation and Command and Conquer lineages. However, we break from the rest of the TA-like games by paying particular attention to making the economy flow smoothly, in stark contrast to the unforgiving economies that tend to define the subgenre. This is because Zero-K is about fighting the enemy, not about micromanaging your base, and it also demonstrates how flow economies are not necessarily daunting.



A flow expenditure system works as follows:

• The player issues a construction order, and the construction begins.
  
• Resources are spent over the course of construction, such that a task which is XX% complete has consumed XX% of its cost.
  
• If you run out of resources, then construction rates are reduced to balance your income with your expenditure.
  
• When construction progress hits 100%, the construction is complete.
  

For example, if you produce 16 metal/s (metal per second) but your total demand is 20 metal/s, then the each of your constructions builds at 80% (16/20) its maximum rate. Think of it like pouring water into a bucket. When the bucket is full, the construction is complete.

Many games use an upfront payment system as it is the main alternative to flow expenditure. Examining it will reveal why Zero-K uses flow instead, so here is how upfront payment works:

• The player issues a construction order.
  
• The order is blocked if the player has insufficient resources to pay the full cost of the unit or building.
  
• Otherwise, the cost is deducted from storage, and a timer starts.
  
• When the timer finishes, the construction is complete.
  

Upfront payment is a very simple system, and there is strength in that, but using it well can be difficult and time consuming. As we saw in Making Metal, systems of simple discrete actions often end up being more complicated than systems that work more continuously.

Mastering an economy is fundamentally about reducing downtime as any time your factories are not running is wasted time. Upfront payment gives players very few tools to do this, which leads to fights with the UI, and these fights can take over entire games. More specifically, to master an economy you want to keep your money low, and to do that without breaking your keyboard, you probably need command queues.



The saying "keep your money low" is good general RTS advice. The return on investment is so high in RTS, relative to the utility of waiting for more information, that stockpiling is rarely worthwhile. Investment could take the form of expanding your economy, defending it from attack, or attacking the enemy economy, it all helps. Sometimes stockpiling 100 metal to boost out a turret is warranted, but generally, to not spend resources is to fall behind. So how do the two expenditure systems compare? Well, flow expenditure makes having zero money easy, just make sure your demand exceeds your income. Upfront payment makes keeping your money low much more difficult. Approaching the ideal with upfront payment means watching your resources like a hawk, ready to pounce as soon as they hit the threshold required to buy something. This eats up a lot of attention and can even require training to truly master.

Many games have production queues that let players queue up a list of things to be built, regardless of the spending system. Unfortunately, upfront payment queues leave a lot to be desired, as the standard implementation has you pay the full price just to queue a unit. A queued unit is making no progress towards being built, so this is just as bad as having the resources sit idle in storage. These queues are useful for freeing up attention, but they always come at the cost of efficiency, and long queues are terrible. Other upfront payment queues only spend the resources when the task hits the head of the queue, delaying it if there are insufficient resources. This is much more like a UI feature than an Ability, in the language of UI vs. Game World, since it simulates the player clicking the buy button when the threshold is reached. It also allows for infinitely looping queues, which removes a lot of busy work, but has some pretty dire side effects.



The issue with paying when a task hits the front of the queue is with low-money situations. Suppose you want to make an army of cheap infantry and expensive tanks. You queue a bunch of tanks and infantry, then go do something else, only to return to an army of only infantry. The tanks spent all their time blocked at the front of the queue, never reaching their cost threshold, since the cheap infantry would consume those resources first. Even worse, to build anything you now have to cancel all your queued infantry and let your resources stockpile. This is not entirely realistic though, since the only game I know of with this system Warlords Battlecry, and as a fantasy game it lacks tanks. Anyway, flow expenditure is great for queuing since construction rates fall uniformly in low-money situations, guaranteeing a mixed army of infantry and tanks. Flow also allows for infinitely looping queues, so your factories run themselves until you decide to change your army composition.

This all begs the question, if flow spending is so great, why do so many games use upfront payment? Here is what I think.

• Flow is a bit more complicated than upfront payment, especially when it is not the expected default.
  
• Flow has a reputation for being a lot more complicated than upfront payment.
  
• Putting anything approaching optimality beyond the reach of most players is often the point.
  

Upfront payment is a quintessential "easy to learn, hard to master" system, since it makes you do everything manually. This is great for pro players pushing the limits of what is possible, and it also lets newer players slowly build their base without being overwhelmed. Contrast this to flow, which has momentum that keeps going when you stop clicking on it. Upfront payment is like stacking boxes, while flow is like driving a truck. The average player can get a lot more done with flow, but can end up in trouble if they push down too hard on the accelerator.



To be fair, the reputation for complexity is more for the TA-style economies rather than Command and Conquer. C&C only has one money resource and its build rates are high. TA economies effectively have three resources that must be kept in balance. Two money resources; metal, energy, and a third, build power, which is the rate that a constructor or factory progresses production. Construction rates are limited by the most in-demand resource, so stalling (running out of) energy means stockpiling metal until the problem is resolved. However, using up the stored metal requires extra energy, which puts you in danger of wasting energy. Managing these fluctuations can take up a lot of attention, potentially even more than an upfront payment system (depending on the game), and feel quite unwieldy. However, unforgiving fluctuations can be dampened. They are a design decision, not inherent to flow, and one that Zero-K aims to avoid. For starters, overdrive makes it very hard to actually waste energy.

The most complicated part of many TA-like games is their love of seemingly arbitrary metal:​energy:time ratios. One unit might cost 109 metal, 911 energy and take 19.6 seconds to build, while another might cost 150 metal, 2100 energy, and take 34.2 second to build. The former drains 5.6 metal/s and 46.5 energy/s while under construction, while the latter drains 4.4 metal/s and 61.4 energy/s. Those are some weird numbers, but what do they mean? They mean you might be happily building the first unit, switch production to the second, then crash your economy right into an energy stall. In many games the stall could even completely disable your metal extractors, adding to the chaos.



Zero-K avoids these economy-crashing traps by setting all costs in a 1:​​1:1 ratio. A unit that costs 200 metal must also cost 200 energy and 200 work. Build power, which is a constructors' ability to progress construction, is set to nice friendly numbers, such as 5 or 10. Since costs are 1:​​1:1, a constructors' build power is also its demand for metal and energy. Factories have 10 build power, which means they drain 10 metal/s and energy/s regardless of what it builds, and so any factory would take 20 seconds to build a 200 cost unit. This was one of the very first changes made in Complete Annihilation, and costs were rounded at the same time as well, because balancing the cost of units down to three significant figures is folly.

Flow expenditure with 1:​1:1 ratios gives us powerful queues and avoids unforgiving economic complexity, but this was all still a design trade-off. Variable cost ratios can be interesting since they feed back into which resources you focus on collecting. This creates strategic momentum and scouting opportunities, especially in games with extreme ratios such as Starcraft and Age of Empires. TA tends to use ratios for a few special cases in the economy, as well as for general thematic trends, such as hulking ships being metal-heavy, while lightweight aircraft cost mostly energy. I am not sure whether varying ratios and flow is a good combination though, since the complexity ramps up quickly. Also, varying ratios tend to need puzzling out, which leads to long inflexible openings (build orders), which is something else Zero-K tries to avoid.



Parallel production poses a few problems for flow expenditure. Recall how production slows down when your demand exceeds your income. Well, if your demand far exceeds your income, then it can be hard to build anything new. This is like the Warlords Battlecry queue problem, but much more palatable since everything is still built, and it takes an extreme deficit to get into real trouble. There is a subtle issue underneath though, which is that incomplete construction ties up resources, so building many things slowly can be as bad as a leaving the resources unused in storage.

Zero-K, along with many other TA-style games, addresses the parallel production issue by emphasising assisting, which lets multiple constructors pool their build power on a shared task. They can even assist factories, saving you from having ten 90% complete tanks. The extreme deficit problem persists though, and in many games you have to go through your whole base shuffling around or pausing constructors to prioritise anything. This is a clear case of fighting the UI, so Zero-K has construction priorities, which were added all the way back in CA.

Construction priority is a state toggle that let you set what gets first dibs on resources. High priority constructions are satisfied first, so they only slow down if too much is set to high priority. There are three levels of priority, and they can be set on constructors to control how they spend resources, or on construction projects to control how resources are spent on them. Priorities can even be given default values, so you can make metal extractors always be built with high priority. Once we added priorities it only seemed natural to add a reserve system, which lets you set aside resources for high priority use. Just Alt+Click on the resource bar. This is how you might set aside 100 metal to boost out some turrets.



Flow has worked very well for Zero-K. It lets players use proper production queues, and much of its reputed complexity is a decision designers make, not a fundamental part of the idea. Most of the magic is in ​the 1:​1:1 cost ratios, with not-insignificant contributions from round numbers and construction priorities. It is harder to destabilise your opponents' economy, but on the upside, learning how to make a stable economy is much easier. The upside is worth it in our view, because it lets players get on with playing the rest of the game, and very few real in-the-moment decisions (as opposed to preset build orders) about how to grow your economy were lost.

Index of Cold Takes

Jumping is old, going back to the early days of Complete Annihilation, which predates Zero-K. It is also a very stable mechanic, to the point where a player from 15 years ago would not see the difference just from using it. In part this is due to its simplicity: just give a unit which can jump a jump order, and it will jump to the location once it is in range. But it is also because surprisingly little has changed.

So why write an article about jumping? Well, while there have been a few changes, each one reveals a further refinement in the design of Zero-K. Even more revealing are the ways that jumping has deliberately stayed the same, in the face of potential changes. So here are four mini-articles on the how, what, where, and legs(?) of jumping.





Perhaps the most important aspect of any ability is the types of units that can use it. Jump is one of the many abilities associated with a particular factory, in this case the Jumpbot factory, but in an unusual way. Other factories with a unique movement ability, such as the Hovercraft Platform or Spider Factory, have that ability on all of their units, whereas only about half the Jumpbots jump. This makes Jumpbots more like Cloakbots or Shieldbots, which each only have a few cloaked or shielded units. Furthermore, the Shieldbots' Dirtbag jumps, as well as the Recon Commander, and the largest unit in the game - the Detriment. This smattering of jumping is also similar to cloaking and shields.

To see why Jumpbots ended up like this we have to go back to CA, since only commanders and Detriment have gained jumping since then. Jump was an ability exclusive to the Core faction, to mirror Arm's exclusive access to all-terrain spiders. Each faction had two tiers of bot factories, with a few all-terrain options in the higher tier factory. Placeholder and Firewalker, two non-jumping Jumpbots, did not exist at the time, and Moderator existed in the skirmisher role, but with a different weapon. Technically we could have let Moderator jump, its role stopped us.



Jumping is not just a way to move around the map, it is also a tactical ability that bestows a burst of speed. So a jumping skirmisher violates Quant's Rule, since skirmishers are meant to be weak to fast units that negate their range advantage. Jumping is an excellent escape tool that negates this weakness, so Moderator was not given the ability to jump. Firewalker is non-jumping for the same reason, and also because dislodging artillery from awkward cliffs sounds very annoying. Spiderbots lack true artillery for the same reason.

In addition to violating Quant's Rule, using jumping skirmishers also sounds tedious. Jumping with a short ranged unit is a game of risk, reward, and sudden retreats, while jumping with a skirmisher sounds like game of routinely retreating when enemies get too near. Such a thing feels like it could be automated, which also comes into conflict with the idea of fighting your opponent, not the UI.

We considered creating a combined jump and spider factory while CA was being merged into one faction to create Zero-K. The goal was to create a fleshed-out all-terrain factory, and on paper it worked quite well. The only spiders at the time were Flea, Venom, Recluse and Crab, which fill the scout, riot and skirmisher roles, which leaves the raider, assault and anti-heavy roles to be filled by Pyro, Jack and Skuttle. However, this idea did not make it beyond prototyping, and instead we settled on the Jumpbot and Spiderbot factories we have today. I do not recall the exact process behind the decision, but here are some likely factors.

• Jumping is a sudden bursts of speed, while spiders can constantly dance around cliffs. These are distinct styles so should be in different factories to let the distinctiveness flourish.
  
• The combined factory would be too full, and too flexible, with all the units it could contain.
  
• It would be tricky to find new homes for all the non-jumpers and non-spiders that we wanted to keep from the rest of the bot factories.
  
• Having two factions that can play very hilly maps, or areas of maps, seems much better for diversity.
  
• Jugglenaut and Crab would fight over the role of the factory's signature unit.
  

The solution was to add Hermit and Tarantula to flesh out the spiders, and make Widow all-terrain. Redback was added later to let Venom move more towards a raider role. As for the Jumpbots, they are essentially the old CA tier 2 Core bot factory, with a few new units added later.

As for why there are no new jumping units, that goes back to the Zero-K approach to uniqueness. Many sci-fi strategy games use a weapon-chassis approach to unit design, where units can be boiled down to a combination of weapon and movement types. Sometimes there is even an in-game unit designer to make this breakdown explicit. Zero-K can be viewed through the lens of chassis and weapons, but there are so many holes in the matrix, and extra subtleties on top, that doing so is of limited use. Zero-K units aim to be more distinctive than combinations of weapon and chassis, and adding more jumping units for existing roles would work against that. Besides, jumping is primarilly a Jumpbot feature, and there are plenty of mechanics to build other factories around.





Jumping is surprisingly non-physical for a game with unit launchers and Lobsters. A jumping unit follows a set trajectory until it either dies or lands on a building, so unless that happens, it is guaranteed to end up safely on the ground. Its trajectory is calculated at the start of the jump, although the jump will be blocked if it would pass through terrain. This is all very deliberate, to the point where an impulse-based alternative written by the developer xponen was not adopted. This new system used dynamically scripted physical forces to launch and guide units through the air, then slow them down at the other end to avoid taking fall damage. It was essentially a simplified and automated Kerbal Space Program.

The impulse-based system was rejected for the unreliability inherent in its design. The goal of the system was to give units full physics while jumping, which meant that sufficient incoming fire could knock them off-course. Jumping multiple units was particularly risky since they would bump into each other mid-air, and even a slight course adjustment could lead to a unit bouncing away, down a cliff, and into a puddle. But how is this distinct from Lobster lob, which was added much later? Lobster picks up units and physically throws them in a direction, with the only nod to safety being temporary fall damage immunity.



The difference between Lobster and jumping lies in their centrality. Lobster is a somewhat niche midgame support unit, while many jumping units, particularly Pyro and Constable, are built from the very start of the game. As such, jumping has to be much more reliable. A Lobster causing part of an army to bounce down a cliff is recoverable, and to some extent it is the price of using Lobster. Armies are large enough by that point for things to average out. An early Pyro failing to jump up a cliff, or a constructor becoming stuck, would feel really bad and could be game deciding.

The general principle here is that, if you want to build a faction around a mechanic, it had better be reliable. People have to be able to trust their units' basic abilities, since taking even a slim risk of complete failure into account is too taxing. On the other hand, tactics that appear later in the game can afford to have a bit more risk. There are more options later in the game, so using any particular one is more opt-in, and there are more ways to mitigate risk.

As for the unused impulse-based jump code, there is a happy ending. Amphibious floating was originally implemented in the same way as jumping, with a set trajectory. This leaves a lot to be desired, and I could see xponen trying to get more physics into the game, so I suggested that the impulse jump tech be used for floating. This worked great since units bobbing around and bouncing off each other is a great feature for floating, and it cannot fail in the same ways as jumping. Floating is much better for it, and the impulse jump code still exists in the repository, so a modder could even pick it up for use in a game with a different set of goals.





The lack of interaction between jumping and the rest of physics has a few weird effects. Units can jump from anywhere to anywhere, provided it is in 2D range, which includes while flying through the sky after being launched from a unit cannon. Jumping just follows a calculated trajectory, which causes launched units to turn sharply and float towards the ground when they jump. I remember launching Pyros across Victoria Crater almost as soon as Newton was implemented. However, there have been a few problems.

Skuttle is a cloaking, jumping, bomb, which made it a particularly powerful unit to launch. Imagine the Sky Jacks of today, except they are cloaked and 1-shot their target. The best theoretical counter was positioning Hercules, or any other high-flying gunship, above anything important to decloak the Skuttle, and spamming Pickets. This was far too expensive, arduous, and silly, so we considered ways to nerf the tactic. Removing cloak was not an option since Skuttle needs to cloak while jumping for its mundane uses, so instead we removed its ability to jump mid-air. Thus the distinction between jumplegs and jumpjets was born.



A unit with jumplegs can jump, but not from mid-air. Skuttle was given jumplegs, along with some other units that looked like they use legs to jump. Notably, Pyro and Jack were given jumpjets, so retained their utility in unit launchers. This reflects the broader design philosophy of trying to retain as many of the creative combinations of mechanics as possible. It would have been easy to remove mid-air jumping entirely, but instead we surgically patched out the bits that would clearly break the game. Besides, jumping from anywhere has synergy with Placeholder, and saving units that are knocked off cliffs by enemy fire is cool.

Splitting jets and legs also let us make jet break cloaking. This had to happen eventually, but was blocked by Skuttle needing to cloak, since the smoke and fire emitted by jumpjets ignore cloaking. Effects like these can be seen by players, but not their units, which gives players extra information. This leads to a form of fighting the UI where players want to tell their units to shoot at the mysterious smoke, but cannot. In these cases we either remove the effect while cloaking, or make the effect decloak, to bring player knowledge in line with unit knowledge. The former is applied to damaged-unit smoke, which is suppressed for cloaked units for this very reason, but would look silly when applied to jets. The latter, decloaking the unit, was initially why units decloak when they take damage, since projectiles exploding mid-air is suspicious.



The existing jumpers were split into jets and legs on aesthetic ground. Basically, if a unit already had leg animations, then it was given leg mechanics. This was particularly good for units with a wind-up animation, since the animation caused them to actually stop mid-air to do their animation, which was too cartoony even for Zero-K. Detriment jump, which was added later, has a wind-up animation and a rocket jet, so mechanically it has jets and legs. It decloaks when it jumps and cannot jump mid-air.

Recon Commanders was hit the hardest by the addition of jumpjet decloaking, since it can equip a personal cloak module. I recall this being a desirable change at the time though, as cloak made the commanders a bit too slippery. Jugglenaut and Detriment also decloak when they land, since their impacts create a visible explosion.





The question of where units should be able to jump is a tricky one, since both extremes lead to frustration. Highly restrictive jumping will cause units to annoyingly refuse orders that it "should" be able to carry out, while unrestricted jumping results in players unintentionally ordering their units to become stuck on impassible terrain. The current system is as follows.

• Units cannot jump onto terrain that is too steep, since they would become stuck.
  
• Units can jump onto structures, however, the jump ends when they hit the structure.
  
• Units can jump into water, provided the terrain under the water is not too steep.
  
• Units cannot jump out of the water, except Detriment and commanders, since they are amphibious.
  

These rules work surprisingly well, and have been tweaked over the years. Originally units could jump out of water but not onto structures.

Jumping onto structures used to be impossible. The issue with allowing it is that a jump trajectory would let units clip completely into structures, making them impervious to enemy fire. However, this had to be solved, since being unable to jump at structures felt like too much of an arbitrary limitation. Jacks were looking silly milling around the bases of terraformed turrets, and a Singularity Reactor in a hole should be more vulnerable to jumpers, not less. So we let jump target structures, but interrupt it as soon as the unit hits the structure. This lets Jacks jump up to get a few hits on a turret on a spire before bouncing back down, limiting its damage output by its jump recharge.

Interrupting a jump when it hits a structure leaves units at the mercy of physics, so they could bounce off the structure and fall down a cliff, but I do not recall any complaints. Perhaps it is because such a jump is a deliberate decision, and one that rarely has to be taken early in the game. People naturally give jump orders on open terrain, when it is available. The bouncing is also much more restrained than full impulse-based jump, since the jump is always interrupted very close to the destination.

It also used to be possible to jump out of the water, and there was even the idea of making jumping units fully amphibious. Jack could already be used amphibiously since melee weapons fire underwater. However, the idea of giving jump a small amount of underwater utility was dropped because it was too tedious. Babysitting units across the sea by chaining jump was a form of fighting the UI, which we resolved by removing the possibility. The idea of full amphibious movement was dropped because jump already bypasses cliffs, so if it bypassed large bodies of water, then there would be too few ways to make a hard barrier against it.



Units can jump into water because it seems like something they should be able to do, and there are more upsides than downsides. Sometimes it is worth saving a Jack or Jugglenaut by telling it to jump into the sea. Rescuing such units is just a matter of a little terraform, to give them a small platform of dry land to jump from. In theory these units can jump in any direction, so it stands to reason that they should jump into the sea if it is to their advantage to spend some time stuck underwater. Jumping into the water accidentally is bad, but water is visually distinct enough to make this very rare.

There would be times when units would want to jump onto terrain that is too steep, where they would be stuck until they jump out again. However, terrain steepness is harder to make out than water, no matter how clearly it is shown, and there are far fewer advantages, since the main purpose of water is to block projectiles. Ability restrictions are about balancing the feel of units being able to freely use their abilities against the risks of each application. A niche use for an ability that has a high risk of being accidentally misused is not worth allowing.





Hopefully that was a useful insight into some aspects of jump design. Most of these articles involve dredging the principles out of my subconscious, which means at the outset I am not entirely sure how the concepts will be carved up. So I would like to take a moment to summarise a few of the new ones we saw.

• Jank Escalation - Mechanics that are central to some core set of units need to be reliable, so players can trust them. More niche mechanics, or those that show up later in the game, can have more risk involved. So jumping is reliable while Lobster is not.
  
• Disciplined Physics - Physics is great, but it should not be used at the expense of other considerations. Zero-K does not set out to apply the maximum level of physical simulation so usability often takes precedence, as mentioned in Physics vs. Formulas.
  
• Surgical Excision - Interactions that would break the game should be removed without affecting related mechanics that have not yet been shown to be broken. Doing so would hinder the creative toolbox feel of the systems. So Pyro can still jump mid-air.
  
• Practical Verisimilitude - Units should feel like they are free to use their abilities in ways that make sense within the game world as it is presented. But units with no restrictions can be told to do very stupid things, so applications with low utility and a high risk of misuse are restricted. So units can jump into the sea, but not onto steep terrain.
  

Of course, we also saw a few ways to use Quant's Rule and Not Fighting The UI, but they are going to show up everywhere and already have their own articles. Perhaps it is time to start a glossary.

Index of Cold Takes

Projectiles in Zero-K are physically simulated, meaning that shots fly through the air and collide with anything that gets in the way. This is standard for games inspired by Total Annihilation, but Zero-K leans into the mechanic hard, and embraces the implications. Not content with taking only one thing to the extreme, Zero-K also has a strong aversion to armour classes and damage bonuses. We completely avoid damage formulas of the type that let pikemen deal extra damage to horsemen, or tanks take reduced damage from rifles. The goal is to create a game world that is visceral and intuitive, something that is best engaged with as a physical space, rather than as an abstract collection of numbers.

Complete Annihilation steadily removed the damage formulas inherited from Balanced Annihilation, and it looks like BAR might head the same way too. These were mostly things like commanders taking extra damage from turrets, and various EMP resistances. Bonuses like these suffer from being confusing and hard to remember, especially in a futuristic setting with no historical precedent or clear notion of infantry to guide intuition. Besides, completely removing damage bonuses is just so elegant, and making it work is a fun challenge. So we saw damage bonuses as a crutch, they solved problems in BA, but we could use physics to come up with better solutions.



To stack hubris on hubris, we also wanted the units of CA to have roles. Roles in the sense of pikemen beating horsemen, which is a bit more detailed than the roles found in Total Annihilation and most of its progeny. The roles in TA tend to be big "theatre of war" style designations, with roles like "bomber", "fighter", "scout" and "artillery". These roles are about dominating air, land or sea, or about projecting force from one domain to another. Artillery even fits this description if you consider bases and open ground to be different domains. In any case, all this theatre-on-theatre action left little room for diversity within a domain. This limits the options for combat within a domain, and in particular, land armies designed to fight other land armies could end up quite similar. The generic "army unit" would change as the game escalated, but at any given point the unit selection felt slim.

Armies in Zero-K should consist of multiple unit types, and it should be possible to exploit deficiencies of enemy armies, all within the ground vs. ground game. So Zero-K is designed around roles. Fast light raiders beat ranged skirmisher, which beat slow beefy riots, which beat fragile raiders. Whether these are "hard counters" or not mostly depends on how you define "hard", but I think they are mostly soft counters. Units can often beat their counters with a slight numbers advantage and a good engagement. We still have the "theatre of war" style roles, since cross-domain interactions are great too, but these counters tend to be harder. Artillery is very good against static defense, and fighters are very good against bombers.

How does Zero-K have such roles, all without any bonus damages? What makes the horseman-equivalent particularly bad against the pikeman-equivalent? In many cases, the answer is physics. Game physics, not real world physics, as the goal is depth rather than realism. Physics means the way units move around the world and interact with each other. It is things like unit positions, ranges and speeds, weapon area of effect damage, and how projectiles move. This is not new, every RTS has physics, and without it they would essentially be spreadsheets. Physics is fundamentally what gives players any reason to care where anything is. Every game with time, space, and simple rules linking them together has some sort of physics.



Not only is physics used by every RTS, it is often a large part of their design and balance. Horsemen counter archers because speed physically counters range, and any arrow-resistant armour is just icing on the cake. Zero-K just takes this a step further, eschewing damage modifiers and relying more on physics instead. This is a design constraint, a rule we have set for ourselves, because it means that units need to be physically different to have different roles. Spearmen can be designed to counter horsemen with physics alone, but it becomes tricky when it is time to implement a physically similar swordsmen. There is still plenty of freedom though, since quite a bit can be done with basic stats such as speed, health, damage and range. On top of this, Zero-K uses projectile physics to a much greater extent than the average RTS.

In most games, units shoot projectiles as a form of delayed damage, and to animate the act of shooting. A standard projectile will hit its target, and nothing else, unless the target does something weird (such as dying or, in some cases, teleporting). In Zero-K, each projectile is an independent entity with its own physics. Plasma cannon shots arc through the air, lasers fire in straight lines, and missiles try to track their target. If a projectile hits something, anything, then it explodes and deals its damage. The visuals are used to convey all this, rather than just being an animation to show that a unit shot.

Projectile physics increases the importance of units' speed and model size. Many longer ranged weapons shoot slow or inaccurate projectiles, which gives small fast units a chance to dodge while closing in. The slow rockets of most skirmishers are tuned to hit large assaults and riot units. In turn, the even slower projectiles of assaults and artillery units give most targets a chance to dodge, with the notable exception being turrets. There is space for soft counters here. Skirmishers can still beat fast raiders, but it is more a matter of creating a blizzard of rocket fire than having individual skirmishers fire at and hit individual raiders.



The whole "Physics vs. Formulas" dichotomy is about which parts of the game are more important. It is about whether a player choosing which unit to build thinks more about how it moves and shoots, or about damage formulas that determine what it counters. Zero-K is on the side of physics because it is cool, and it seems so intuitive. Players can see whether a projectile hits a unit and extrapolate the results for other projectiles and units of a similar speed. On the other hand, formulas are invisible and can be arbitrarily complex, taking into account armour, unit type, weapon type, and upgrades. Enough of a reliance on formulas can make the physics of a battle irrelevant, which is a shame because it is the part of the game that players can interact with moment-to-moment. Exploiting a formula is more down to unit choice than unit usage.

Great mechanics have more than one purpose, and physics of Zero-K has many. A big one is to fight Lanchester's square law, which essentially says that an army of twice the size is four times as powerful. All games have to grapple with this law, that is, unless they are happy with players just rolling a big ball of units around the map. The trick to fighting Lanchester's square law is that the "square" only applies in ideal situations, so to fight it we just need to move away from the ideal. Most games do this via units of inconveniently short range, to limit what can fire, and area of effect damage, as it deals more damage to dense armies - armies which are dense because everything is trying to get into range. Zero-K makes use of these approaches, but uses projectile physics to add even more.

Unguided projectiles act a bit like area of effect damage, because dense forces take more hits. Consider how a large force of Ronin will fire more rockets than a smaller force, but also runs into more rockets. At least, unless the Ronin spread out, but that risks moving some too far away to shoot. This all fights Lanchester's square law, but in a dynamic way where there are tradeoffs between dealing and taking damage. A small force can hold off a large one for a while if the larger army is unwilling to take any damage. It also makes attacking from multiple angles even better, since it reduces your own density. But perhaps the most notable effect of simulating projectiles comes from allied units blocking each other.



Projectiles hit units regardless of their allegiance, and going this far with projectile physics is rare even among games inspired by TA. It means that a dense blob of units loses most of its damage to blocked lines of fire. This further encourages armies to spread out in a line. Density and facing is very important, since a good flank can leave most of an army unable to return fire, even if they are in range. High density is not all bad though, since it concentrates power and prevent units being surrounded by enemy raiders, so there is a constant tradeoff. Still, Zero-K tends to have lower density armies than the average game, which encourage spread out battles across multiple fronts. The advantages of low density even play a central role in the escalation from cheaper to more expensive units.

Projectiles have a lot of parameters, which in turn allows for a large range of weapon types. To cut down on complexity, most weapons fall into one of three categories.

• Plasma cannon that fly through the air in a ballistic arc.
  
• Unguided rockets or homing missiles. Some are fired directly at the target, while others arc.
  
• Lasers and lightning that instantly hit and require a direct line of sight to fire.
  

These weapon types results in a variety of tactics, since each type has its own relationship with unit density. An arcing projectile allows units to clump and still be able to fire, but still leaves them vulnerable to return fire. An army armed with lasers or homing missiles needs to spread out to fire, but the inability to miss removes an opponent's incentive to spread out. Being unable to miss is quite powerful, but remember we still have non-physics balance tools, so such units tend to pay for their accuracy with poor raw stats. Direct fire weapons are also particularly weak to being blocked by terraformed walls.



This all sounds great, hopefully, but it also sounds fiddly. Luckily, Zero-K is built on fighting your opponent, not the UI, so we are careful to keep the physics manageable. We avoid implementing unnecessarily fiddly weapons, and provide powerful controls to deal with everything else. Line Move lets players create formations and dial in their density with ease, and becomes their default way of issuing orders. Attack Move lets players tell short ranged units to jink around to avoid projectiles, and longer ranged units to move away from enemies that try to close range. Anti-Bait lets players tell units with big important shots to not waste their time trying to hit a speedy raider. And it almost goes without saying that units have the intelligence not to fire when allies or terrain is in the way.

I have been a bit misleading, and it is time to come clean. Zero-K has a damage formula. To start with, some units have an armoured mode that causes them to take 33% damage. I am not sure whether this counts though, since the multiplier applies uniformly. The most common damage modifier is for anti-air, which deals only 10% of its damage against ground units. But anti-air is not even capable of firing at ground units, which is a fine mechanic provided the target categories are clear. The anti-air damage modifier is mostly just insurance against anyone figuring out how to work around this restriction. Then there are shields, which have to convert status effect damage such as EMP and slow to ordinary damage. This is done at a rate of 33%, which is a bit arbitrary, but it has to be less than 100% because status effects have very high raw damage. Finally, gauss and flamethrowers deal extra damage to shields, because something something piercing something something... there is actually no excuse.



It gets worse though, as some units shoot through allies, or even terrain. And not in a consistent way, like how flamethrowers burn through everything in their path. Nukes and tacnukes pass through allies because having one explode on an errant plane sucks (although when they hit an enemy plane it is hilarious). Anti-nukes pass through everything for similar reasons, but also because they do not know how to try again if an anti-nuke misses its target. A few other weapons here and there pass through allies, although in most of these cases units still avoid shooting at allies. There is a difference between colliding at allies and firing at allies. A few units with fast ally-piercing projectiles still aim as if they would hit allies, so the caveat is more about edge cases. Some edge cases are bad, and the best uses of physics know when to relax and let things feel good. In short, know when to dial back the jank, because sometimes it just sucks.

Speaking of jank, weapons can impart force on units, pushing them around. Clearly this means there should be gravity gun weapons that just push or pull units, and there is no reason not to let it target allies. The result is unit cannons made of Newtons (the gravity gun turret) and terraformed ramps, and it is my favourite incarnation of a unit cannon. Anything can be fired, anything, provided you have the resources and skill at engineering. Such a thing would get repetitive if it were common, but somehow it hits a sweet spot. It is often impractical, but sometimes it is time to fling Jacks into the back of the enemy base.



Gravity guns and edge cases aside, the goal of Zero-K's physics is to evoke a particular feel. The game world should feel like something that should be engaged with as a physical space, rather than an abstract collection of numbers and circles. Games can end up feeling quite abstract. Put more enemy units in your circles (ranges and spell radii) than your opponent manages to put in theirs, and you win. Formulas can vary the effect and suitability of each circle, but this just mixes up which circles are used, rather than change the fact that everything is circles. Zero-K fundamentally disrupts the circles, deforming them into weird and wacky shapes, the consequences of which are too numerous to cover in one article. But it is sure to come up again and again.

Index of Cold Takes

Games in the Total Annihilation lineage almost always have the same two resources, metal and energy. Metal is produced by building Metal Extractors on deposits scattered around the map, while energy comes from power generators that can be built, by and large, anywhere. The more important resource is metal, simply because metal deposits, or "spots", are rarer than free space to produce energy. Metal is the limiting factor, which causes players to expand out onto the map, capture territory, and interact with the enemy. A game without metal would mostly consist of players sitting in their base, building energy.

Many TA style games also have Metal Makers, economic structures that drain large amounts of energy to produce a bit of metal. Supreme Commander calls these Mass Fabricators, but mass and metal are just two names for the same thing. These structures are less efficient than metal extractors, otherwise players would have no reason to leave their base, but they allow players to scale up their economy without capturing more metal spots. The only requirement is space and resources, which makes them useful later in the game when all the metal spots are taken and defended. The early developers of Zero-K liked the idea of a growing economy, but not how it was implemented with metal makers.


Metal makers were removed from Complete Annihilation, the precursor to Zero-K, just about as soon as it forked from Balanced Annihilation. For context, the average 8v8 BA team game had a few players on each team fighting over unclaimed territory, while the rest of the team sat in the back and mostly built metal makers. The back players players were not slacking, they were necessary, because games were rarely won before metal makers became a deciding factor. Any team that ignored metal makers risked being overwhelmed by the compounding income they would eventually provide. Eventually, once a team had enough metal makers, territory no longer mattered. This did not sit well with the CA developers, as they preferred fighting and expanding to sitting in the back.

Metal makers are fundamentally a way to spend resources now to be more powerful in the future. Every RTS needs something like this, some way to invest in the future. Investment can take many forms, from simply increasing income, to upgrades that increase how much power you can squeeze out of your existing income. Investment is vital because it is a dimension of the strategic triangle, with the other two dimensions being aggression and defense. Without investment, there would be no way to outproduce and overwhelm an overly defensive opponent, and there would be nothing for aggressive play to punish. So we knew that CA needed some form of investment. We tried subsisting on advanced metal extractors, another feature of the TA lineage, which are expensive income upgrades for basic metal extractors. These were a bit finicky though, and the ability to invest hits a wall when there is nothing left to upgrade, so we came up with overdrive.


Just as an aside, I recall discussion on the Planetary Annihilation forum about whether it should have metal makers. It ended up without them, and without a replacement, which might be fine, although I lost track of PA so cannot say for sure. I suspect relying on advanced metal extractors works because there is a lot more frontier to defend when playing on a planet, and PA was fairly spammy with its metal spots. So upgrades can carry the investment game, just in CA's case the maps tended to not have a ludicrous number of metal spots.

Anyway, CA went with overdrive, which may have been invented by Licho. I know he at least wrote the first version of the code. The basic idea is that every metal extractor (mex for short) should also be a metal maker, because that links metal makers to territory. A complete system can then be derived by noticing and fixing a few immediate issues.

• Metal spots can be high or low yield. It would be weird for a map of low yield metal spots to allow more metal maker income than a map with fewer spots and the same total income. So the "metal maker" income of a mex is a multiple of its spot yield, rather than a fixed amount.
  
• The standard "drain 70 energy for +1 metal" style metal maker has the same issues as advanced mexes. In particular, economic investment hits a sudden limit when enough energy is being produced to run all your mex-metal makers. So we made mexes able to turn a variable amount of energy into metal.
  
• A variable input metal maker cannot have a fixed conversion ration, otherwise players would only ever need one. This would defeat the whole purpose, so we made a mex's energy to metal conversion efficiency worsen at higher rates of energy use.
  

The result was mexes that can drain X energy to multiply their income by 1+√(X/16). We call the extra income overdrive income, so for example, a mex with +2 base income doubles its income by draining 16 energy per second, and would need to drain 64 energy to triple it. Actually, the original equation was √(1+X/4)-1, but near the end of 2014 we discovered that it had not been solved correctly, and that the correct solution required the concept of "underdrive". So we switch to the simpler 1+√(X/16).

The diminishing returns of overdrive keep territory relevant throughout the entire game. Say there are two teams, one with 10 mexes and the other with 8, which each have 40 energy to spend on overdrive. The energy is automatically split between the mexes, as this yields the greatest return, so the teams spend 4 and 5 energy per mex respectively. Spending 4 energy on a mex increases its income by 50%, while spending 5 energy increases its income by 56%. Assuming +2 base income mexes, the team with more mexes produces 10 overdrive metal while the other team only produces 8.9. So territory is important because it lets the team with more mexes convert the same amount of energy into more metal.


Overdrive was also a break from the exponentially increasing income characteristic of standard metal maker economies. With metal makers, you can always spend a fixed amount of metal for the same increase in income, and this income can be reinvested in increasing your income, yielding exponential returns. With overdrive your income can still grow, but further growth becomes increasingly expensive. These two factors cancel out, leading to high initial returns followed by approximately linear growth, since spending twice as much energy on overdrive only increases your income by 41% (√2). The graph above demonstrates the difference, with overdrive via Singularity Reactor pitted against a modded metal maker. The metal maker does not drain energy, rather, it represents an energy-neutral combination of metal makers and power generators.

Removing metal makers was also great on the fighting the UI front. It takes skill and attention to scale up a metal maker economy since energy production needs to be balanced against expenditure. Overbuilding power generation is wasteful because the excess energy is lost, while overbuilding metal makers leads to a deficit. Metal makers can be turned off to avoid stalling, but idle metal makers represent wasted resources that could have been used to generate more energy. Truly optimising your income is hard. Overdrive does away with this. If you want to increase your income without more metal spots, just make energy and let your mexes automatically drain the excess. The underlying decision, to invest, is the same across games, but getting the most bang for your buck is tricky with metal makers. Players using either system still have to balance exploiting their existing territory against expanding into new territory, but that is an important strategic decision that involves the enemy, so Zero-K retains it.

Overdrive also led to some interesting map design around high yield metal spots. Mexes drain energy to multiply their income, so better mexes are more efficient and should use a larger fraction of the available energy. The overdrive system figures this out automatically, with the optimum split being to weight each mex by the square of its income. So a +4 mex should receive 4x the energy of a +2 mex. Map makers take advantage of this system by putting high yield metal spots near the centre of the map, for "king of the hill" style objectives that become increasingly important as the game progresses. The high yield mexes are valuable early, but not unduly so, because excess energy is scarce. It is only later in the game, once people have built up their energy, that holding high yield mexes confers a significant economic advantage.


The initial implementation of overdrive had a few problems. The very first version presented players with a graph and a slider bar to control how much energy they sent to overdrive. That was quickly replaced with an innate system that spends a proportion of your net income that depends on how much energy you have stored. The first version might have also been per-player, rather than pooling team mexes and energy for improved efficiency, but if so, it was revised quickly. In any case, there were other reasons to have shared mex income. Overdrive had one tricky, nuanced, problem, which we solved by adding an energy grid. These days overdrive is synonymous with the energy grid, but the entire rest of the system was designed without it.

Grid-less overdrive was a bit prone to snowballing. A small difference in the number of mexes controlled by each team results in a persistent income advantage. More precisely, the energy to metal conversion ratio is √(X/Y) times better for a team with X mexes compared to a team with Y mexes, for the same input energy, assuming uniform mex incomes. This would compound into victory for the side with a slight advantage, before it "was time" for the game to come to a conclusion. The solution was an energy grid, so that overdriving a marginal mex required a bit more effort than just building the mex. Then a team with a slight advantage has to hold onto their mexes, and to build some vulnerable infrastructure, if they want to compound their improved overdrive efficiency into victory.

The energy grid works by setting a simple constraint: the total energy used by mexes in a grid cannot exceed the energy produced by structures within the grid. This makes overdrive usage mirror the roll-out of advance mex upgrades in other games. Players start by upgrading their main base, and then expand to increasingly dangerous territory. It creates a satisfying wave of "double expansion", where you have secured territory well enough to fully exploit it for resources, and the extra infrastructure is also extra raid-able.


The first grid was designed around dedicated pylons. These pylons gathered energy within their radius, and were the only structure that could link to mexes and to other pylons. As well as being too complicated, the system suffered from the distance threshold problem. In short, previously irrelevant minor variations in map symmetry were now extremely important. A pylon might cover four mexes on one side of the map, but only three on the other, conveying a noticeable economic advantage. We tried imposing a hard connection limit of three, and tweaking pylon radius, but maps were too variable to cover everything, and our attempts were making pylon placement increasingly fiddly. So we let everything link to everything, letting pylons fade into the background. This all happened rather quickly, the grid as it exists in Zero-K today may have been complete as early as 2008.

Letting everything link to everything turned out really well. Many RTS games have at least one spammy economic structure, most commonly houses or power plants, that can be built anywhere. Players will just pack these structure into the back of their base unless the game gives them a reason not to. Most games of the TA lineage let this happen to their power generators. Supreme Commander had a go at solving this with its adjacency bonuses, but personally I feel like they make base building a bit too prescribed, and packing a checkerboard of power generators and metal makers into the back of your base does not seem like much of an improvement. The way players make energy in Zero-K is so interesting, so flexible and alive, by comparison.


Players tend to start on their grid from the start of the game. They drag lines of wind generators between metal extractors, but these lines are perfect cover for enemy raiders. Expanding constructors might also build the occasional solar collector, which spices up expansion patterns and creates more targets for raiders. Two solar collectors are enough for a 50% increase income boost, so people often roll them out as cheap form of secondary expansion before fully gridding everything later. Placing energy in interesting ways becomes automatic, you can sometimes spot Zero-K players in other games this way. Giving players a reason to care where their energy is built creates so much nuance and variation in expansion and base layout.

Overdrive has a big drawback in that it can be harder to explain than metal makers. Telling someone about a structure that turns a fixed amount of energy into metal feels like a complete explanation, even though it leaves out all the detail of when you might want to use this structure, and how to manage an economy around it. The basics of overdrive can be explained with rules of thumb such as "build more energy than your metal income" and "link energy to mexes', but these are a bit too vague. Some players want solid numbers, even before they have the context for them. All we can give them is the energy conversion equation, and the way grids limit energy expenditure.

The trickier explanation of overdrive goes hand-in-hand with its role in Zero-K. For all its apparent complexity, I contend that mastering overdrive is easier than mastering metal makers. In general, systems made of simple discrete parts, such as metal makers, tend to be more complex than systems of smooth equations. Zero-K exploits the emergent complexity of simple elements in much of the rest of its design, but not at the core of the economy. This is simply because Zero-K is not a game about micromanaging your economy to eke out an optimal growth curve. Such a curve can be solved, and the solution has nothing to do with fighting the enemy, so we consider it to be fighting the UI. Rather than metal makers we have overdrive, which solves itself, but which has enough going on around it to remain interesting after it is solved. The different energy structures, with their different incomes, costs and vulnerabilities, act as our simple elements with emergent complexity.


We try to ameliorate the complexity of overdrive with mechanics that help players play it by ear. Grids change colour based on how efficient they are, and energy structures show an estimate of their payback time as they are being placed. This seems to work for the majority of players, and the system is very forgiving, because overdrive cannot cause an energy stall. Hopefully we do enough to get new players over the hurdle of using something so different, until they realise how smooth it is and how many problems it solves.

Index of Cold Takes