Steam Community

Store Page

Zero-K

All Discussions Screenshots Artwork Broadcasts Videos News Guides Reviews

Zero-K

Store Page

Show

All News

Syndicated News

Official Announcements

Cold Take #12 - Mighty Morphing

May 18

Players coming from other strategy games often find classic conventions broken and common systems missing. The three focused on improving units - morphing, veterancy, and research - are largely absent from ZK. Today is the first of a series of guest articles by Sprung that will talk about them.

First, let's talk about the unit improvement system that still exists vestigially in ZK: morphing. Morphing is often called upgrading, but I won't use that term to avoid confusion since it can also mean research. Very generally, morphing lets you improve or modify a single unit, as opposed to upgrading all existing and future units of that type, like research does. This can be as little as paying three seconds of time to deploy a Terran siege tank; or as drastic as changing two Protoss Templar into an Archon. Of course you can have morphing as a major part of faction identity and aesthetics, but let's talk gameplay. When to have morph instead of just letting players build things normally?

An easy answer is that sometimes you already decided not to let players build more of the unit. In ZK you only get one commander, and there's a limited number of geothermal spots. Accordingly, they are the only two cases where morphing is just a straightforward upgrade. The astute reader may have noticed that metal spots are also a limited resource, and indeed mexes used to morph into Moho mines for a short period before overdrive was instated. Here morphing lets you decide to get more mileage while working within the limit.

A nice example from another game would be the Chinese Overlord tank from C&C Generals. It has a soft limit by virtue of simply being too expensive to field many of them, but you can add extra weaponry on top for even more firepower. Allocating skill points for WC3 heroes can also be thought of as a form of morphing, and it's no accident that allocating modules for ZK commanders looks so similar.

The flip side of a unit limit is flexibility. RTS is, among other things, about making the correct units to adjust to a quickly changing battlefield. The flexibility of morphing lets players continue making choices about their unit composition in face of a limit. Warcraft heroes, Generals Overlords, and ZK Commanders all present multiple morph choices for this reason. Similarly, in Dawn of War earlygame, forcing the player to choose between Flamers or Bolters for their first tactical marine squad, blindly, would not be good design. Morphing some marines to equip weapons lets players make that choice later, while still having a squad on the field to capture points, scout, and do other tasks that don't yet involve picking a specific unit composition. Then, when you scout Orks? Brother, get the Flamer. The Heavy Flamer.

Back to ZK though, since we don't really put any pressure on the player in the form of unit limits, there is barely any need for the flexibility. Ramping economy means that even the most expensive units can become somewhat affordable over time, and by that point you have all the flexibility in the world anyway. Would it hurt to have a little extra?

The problem with flexibility is that it creates a sort of Schrödinger's unit that occupies multiple spots in design space at once, to be resolved into one of them when observing the enemy. The danger ZK sees here is that a monospammed unit could become a composition thanks to its own flexible morphs. Everything becomes much simpler when you can do Just-In-Time reinforcements of the correct type without having to do lame nerd stuff like "logistics" or "foresight". No travel time from the factory. Less risk of overbuilding a variant. Of course these can be adjusted via other stats, but that would all come with a reduction in flexibility.

What about "inflexible" morphs, where there isn't really a composition to talk about and you just want to add more stats? Say, why doesn't a factory have a +10 Buildpower upgrade? It would be more atomic than a Caretaker, who can also do other tasks such as repair! Or, if I want to upgrade Felon battery recharge rate, I have to either get Convicts and have to pay for buildpower I didn't sign up for, or Thugs with inefficient guns thrown in. Meanwhile, a +15 shield regeneration morph would be atomic while remaining a choice! Part of the answer is that units are physical entities in the world and thus there is more interaction between them. In particular, Convict buildpower and Thug guns nudge the player into using them, which then cascades into the usual complexity of the game when the enemy has to respond in turn. The other part is emergence. Felon wasn't initially designed to work as a standalone unit and get "batteries" added; rather, it was designed to itself be added to a shieldball as a way to spend charge. Batteries are a player discovery, if an extremely obvious one.

An interesting feature of morph is that it provides its own buildpower and can have different tech requirements, which then can be used to adjust the appeal of different options. If you require a unit to be built "normally" then it competes for infrastructure (buildpower, logistics) with other units that you may rather be building. Morphing is a way to avoid this, which makes the unit more attractive, or the usual infrastructure less attractive. To put this in concrete terms: say you want to encourage mobile cloakers, because cloaking is cool. If you require people to build them from a cloaky factory, then sometimes they'd rather build a different factory as a secondary, or if they already have a cloaky factory, they'd rather build a different cloakybot. Morph lets a unit be its own little temporary factory, and the elegance of this is that much like energy requirements, it touches just the infrastructure and not the unit itself. The morphs for mobile cloaker and shield, while originally created just as a way to let them redeploy, fall under this category. We try to avoid this type of morph outside of utility units since infrastructure exists for a reason, and while it is easy to manage it should not be obsoleted.

At the beginning I mentioned Siege Mode as an example of morph. In ZK, a handful of units - for example Crab, Fencer and Emissary - have a soft siege mode where standing still gives them some sort of benefit. They deploy so fast that not doing so would mostly be a matter of not having the APM, so rather than make the players fight the UI by spamming Deploy every time they want to move, the units deploy on their own. To let this happen, there is a deliberate large gap in unit design space where nothing has a deployment mode that would be long enough not to automate, yet short enough to make you miss the automation by being commonly desirable. On the other side of this gap we have Desolator, which can deploy into an armoured form, but it takes long enough to make it a rare decision that can afford to be manual. Thus, unit intelligence, or rather avoiding situations that would create unit stupidity, is what prevents sufficiently cheap morphs from existing.

A final way morph can be used is to randomly change a unit into a completely different unit, apparently for no good reason. Why does Lurker morph from Hydralisk? The answer seems less to do with any explicit unit design, and more with how it just had to be crammed somewhere given there were no empty slots on Larva build GUI. Hydra was the least awkward place to put it. Surely ZK would not do something as silly as, say, let Knight morph into Crab without an extraordinarily good reason, right?

...right?

But that is a topic for another week.

Index of Cold Takes[zero-k.info]

Zero-K

126

Zero-K v1.12.5.0 - Settings Override Fix

May 6

This is a small patch that was released to fix the settings deployment bug. A few other things we were working on made it in too.

Fixed a recently introduced issue that caused particular settings to be overridden on launch.
Units far from the epicentre of a Shockley impact are now stunned sooner, to match the explosion visual. Which units end up stunned is unchanged.
Added a cracked ground impact scar for Quake.
Fixed inverted track stretching for, eg, Paladin.
Moving a block in a factory production queue no longer re-applies the multiplicative key modifiers.
Fixed the commander selector ending up off the edge of the screen on particular scaling settings when shifting from windowed mode.
Simplified window resolution switching code to try to make it more reliable.
Fixed sun and water settings overrides being too persistent between maps.
Fixed the sun on Tempest.
Fix thumbnail and minimap images for maps containing unusual characters.
Fixed a bug caused by map searches finding no maps.
Fixed the player name tags widget possibly being assigned incorrectly.
Tweaked the draw order of name tags, health bars, and overhead icons.

Zero-K

Cold Take #11 - The Atomic Solution to Monospam

May 4

Zero-K units are generally quite simple, with many of them designed around a single weapon or ability. The idea is that the complexity of an army should come from how it combines unit types, rather than having any individual unit be particularly complicated. I call this the principle of atomic unit design, because it characterises units as the building blocks of armies, and simple units are, in a sense, indivisible. Simplicity is a good enough goal on its own, but atomic unit design also has an important role in fighting monospam.

Monospam, i.e. spamming a single unit type, can be a contentious issue in RTS. Many players consider such a strategy "unfair" or "cheap", and games are often designed to discourage it, including Zero-K. This makes Zero-K a bit unusual within the Total Annihilation lineage, since TA had a bit of a reputation for monospam, and many successors dealt with it by culling the "excess" units. Zero-K went the other way, and found ways to balance a large unit roster without the resulting monospam. But before we get to that, we need to pin down what makes monospam powerful in the first place.

Monospam derives a lot of its power from being easy to manage. The logistics are simple. Just set your factory to repeat-build Scorchers, spam Ctrl+Z to keep them all selected, then repeatedly hit your opponent with them. The Scorchers move at the same speed and want to fight the same types of battles. But mix in more unit types, and it becomes much more complicated. Even maintaining the right mix is a challenge, since different units often die at different rates, and reinforcements take time to reach the fight. A mixed army that loses most of one type has to wait for the build ratios to be adjusted, while monospam can rely on a constant stream of appropriate reinforcements.

To skew things further, mixed armies are as bad as their weakest unit across many attributes. For example, mixed armies move at the speed of their slowest unit, and are as vulnerable to attrition as their most fragile. Consider an army of tanky Minotaurs and glass cannon Ogres. Such an army is either going to lose a lot of Ogres, or it is going to avoid taking fights that Minotaurs would weather without hesitation. In many situations, half an army wants to fight while the other half wants to run away. None of this is an issue for an army of a single unit type, with uniform strengths and weaknesses. Essentially, most units synergise best with themselves.

So, why do we want to discourage monospam? In short, because there is no crunch in easy decisions, and Zero-K is largely about deciding what to build and how to use it. This is much more involved when dealing with multiple unit types, both on your side and in the enemy army. And, as mentioned previously, the goal is mixed armies of combat units. Mixing battle tanks and anti-air is fine, but the tactical goals for such an army are often quite simple, depending on the type of enemy that is coming at you.

Now that we know what makes monospam powerful, how can we avoid it? The first principle is that mixed armies are 'allowed' to be much more powerful than monospam. My gut says 1.5-2x as powerful, but there is no definite value. The principle is great for guiding balance discussion though. For example, say we are thinking about how Rover might counter Fencer. Scorcher is a decent suggestion, but then some theorycrafter objects that Scorcher is solved by mixing in a few Rippers. At this point, we can invoke the principle, and say that Scorcher losing to a mix of units is fine. Forcing your opponent into a mixed army is half the battle, with the other half being to wait for them to succumb to the extra complexity. So we are free to focus on whether pure Scorcher beats pure Fencer.

Likewise, the second principle for avoiding monospam is that everything needs a hardcounter. It is not enough for a unit to have bad matchups, it needs some absolutely terrible ones. This because straight-up cost-for-cost fights fail to take logistic and self-synergistic advantages into account, and such fights in a vacuum are an important part of judging counter relationships. So any unit that manages to not lose too badly against anything is a prime candidate for monospam. This is not to say that hardcounters have to feature prominently in how the game plays, they just have to be lurking in the background, threatening players with annihilation if they invest too much into one unit type.

This is where atomic unit design comes into play. A unit that does one thing well tends to have weaknesses everywhere else, so must rely on other units to cover those weaknesses. Atomic unit design is not a strict rule though, as it often fights the Rule of Cool. This is a hard fight, especially when big units are concerned, but we still try to keep the abilities of complicated units pointed towards the same purpose. Sea has struggled the most with the Rule of Cool, since ships want to have multiple weapons, and the disparate weapons of Siren are a remaining nod in that direction. The worst offender was Envoy, which used to have a depth charge that acted as inbuilt riot support against anything on or below the water.

Factory abilities further dilute the idea of atomic unit design. If you count things like personal shields, jumpjets, and spider legs as abilities, then a lot of units have two abilities; one weapon and one utility ability appropriate to their factory. However, this extra complexity is well worth it, as having an ability in common strengthens the feel of factories as cohesive factions. The same could be said of, say, Zerg Burrow. Besides, a "faction ability", one shared by many units, has a much lower complexity penalty than an ability that arbitrarily exists for a single unit.

Atomic unit design also applies to structures. For example, Complete Annihilation had a few types of metal extractor, including an armed metal extractor. This structure was not atomic since it had two distinct abilities, metal extraction and a laser turret, so it was removed in favour of the more interesting method of defending a metal extractor: just make a Lotus. This confers all the subtlety inherent in atomic units, A turret might be built forwards to better protect the mex, or in a more defensive position and use the mex as cover. A weak raiding party might have to choose between killing the turret or the extractor. Armed metal extractors provide none of these decisions, approaching one is the same every time, and a fight with one only has two possible outcomes.

Commanders, being the opposite of simple, are a constant thorn in the side of atomic unit design. They are upgraded a bit like a composition of units, with each module adding a single weapon or ability, but fight like a single unit. A high level commander is akin to a one-unit monospam, with all the logistic simplicity and self-synergy, so it needs strong counters. This is hard to square with the feel of commanders, but that deserves its own whole article.

By now you might be wondering, is this all just Quant's Rule? Yes and no, I would say that the ideas are complementary. Atomic unit design is more of a goal than a method, while Quant's Rule is not so strict about how many strengths a unit can have. Quant's Rule guides us through day-to-day balance changes, while atomic unit design is more holistic. Waffling aside, it is mostly just useful to look at things from multiple directions, and it should not be surprising that many of the principles behind Zero-K lead to the same place. So stay tuned for the third I can't believe it's not Quant's Rule article, where I expect to cover Moonwells and the nature of greed.

Index of Cold Takes[zero-k.info]

Zero-K

232

Cold Take #10 - The Smartest Unit in Zero-K

Apr 20

Most player actions in real time strategy boil down to giving commands. After all, these are games about telling units what to do. But there is a subtle difference between RTS and most other genres, in that players tend to act indirectly, by assigning goals to units. The game world itself is only ever affected by units as they try to achieve their goals. This takes a certain level of unit intelligence, and the stakes are high. The fantasy of commanding an army can be shattered by a single unit wandering off in a weird direction.

Issuing commands also has to feel good, since it is your primary way of interacting with the game. This implies that common commands should be small and simple, like short words. In fact, commands can be thought of as the language used by players to tell their units what to do. This analogy turns unit control into a communication problem; how can the player communicate their grand plans to the fragile bundles of code that stand-in for the brains of their units?

The units of Zero-K are relatively smart. Here are some examples.

Units in almost all games know how to close range with the enemy, but Zero-K units also know how to step backwards when the enemy gets uncomfortably close.
They can be told to hold their fire against cheap targets, and know how to stop short of firing enough missiles to kill something twice over.
They can be told to repair or reclaim everything in an area, rather than requiring that the player point out each target individually.
Some can be told to avoid wasting their precious reload time on wobbly radar dots, while others can be told to fire in the general direction of distant targets.
Units even know how to spread themselves out along a line.

The examples above hardly seem earth-shattering, but that is by design. Zero-K units are only much smarter than average because they understand a wider range of commands. The more complicated behaviours, such as the ability to move away from enemies, are optional. Set a unit to hold position and avoid telling it to Attack Move, and it will stay put. This is vital because the principle fight your opponent, not over-automated ingrained unit behaviours is just as important as fight your opponent, not the UI.

In short, Zero-K units are smart by virtue of their expanded command vocabulary, rather than by making decisions themselves. Units should not be making significant decisions, those are for the player to make, because otherwise we start diluting the "Strategy" in RTS. To this end, the complexity of each command has to be quite limited. Notice how the examples above were explained in about half a sentence? You have to be able to to describe your intention when giving commands, otherwise unit control becomes a process of clicking random buttons while hoping for a good result. So unit behaviours need to be predictable. For example, the "keep enemies at a distance" aspect of Attack Move only considers the closest enemy, since a whole-battle view would be too chaotic.

Commands are great, but how do they relate to the smartest unit in Zero-K? Well, players assign goals to units, which the units then try to execute. Achieving goals seems like a good measure of intelligence, so we can think of the smartest unit as the one that is the best at using its abilities to achieve goals. This includes goals that the player has trouble communicating due to a limited command vocabulary, so as to not give a free pass to abilities that are trapped behind poor UI. Also, since we are talking about game AI, it is more useful to think in terms of "least stupid", where stupidity is the misuse of an ability in pursuit of some goal.

The stupidity formulation of smartness turns abilities into liabilities. For example, if you tell a unit to move East and it ends up walking West, then we would say it uses its movement stupidly. But if the unit has no legs, so fails to move at all, we can hardly blame its failure to achieve the goal on its inbuilt AI. Thus, the only units with "perfect" pathfinding are those with the inability to move. And being incapable of failing is almost like intelligence.

So there you have it. The smartest unit in Zero-K is the humble Storage. It has a single ability - to blow itself up - and it is very rarely a good idea. Consider some alternative candidates. Most energy structures have impressive explosions, so it is more conceivable that a player would want to give them some sort of Fire At Will stance. Solar Collectors are out due to the wealth of agency bestowed upon them by the ability to armour up. But perhaps you have a more normal, less technical, definition of unit. One that involves the ability to move. In that case, I might have to argue for Aspis, the mobile shield generator, for the title of smartest unit. But if you have alternative candidates, be sure to post them.

So let's take stock of Aspis's abilities. Being unarmed is a good start, since deciding where and when to fire is a whole can of worms. Then there is the issue of pathfinding, which I could have avoided by nominating a plane or gunship. However, with great mobility comes great responsibility, so even Owls need to be pretty smart to not fly into an untimely end. No, a slow ground unit is safer, as its low speed makes it less responsible for its fate. And besides, the pathfinding in Zero-K is pretty good.

Aspis can also charge its shield, float, morph, and self-destruct. Floating and morphing are niche options for Aspis, and self-destructing is very rarely good. That leaves charging, which can be toggled on or off, and is integrated into the priority system. So Aspis has a pretty good command vocabulary in this area. Remember, it is not on Aspis to optimise its energy drain for the overall economy, it just needs to have a rich set of ways for the player to tell it what to do. So Aspis is very good at using its abilities. Now, those of you with some shield experience might be wondering, what about shield link? Aspis can share its shield charge with nearby shields, and there are some well known ways to exploit this ability.

Aspis' bid for the title of smartest unit hinges on the fact that shield link is a passive ability. Think back to Storage, is it "smart" or "stupid" for blocking projectiles? No, being hit by projectiles is part of being a Storage, it is a passive rather than an active ability. So too with shield link. If two allied shields touch, they share charge. Nobody can control it, and this sort of thing is a powerful technique for making units seem smart. Simply avoid giving units opportunities to be stupid.

Imagine if Aspis could control when to link, it would be an absolute AI nightmare. Linking is great when you need to pump charge into a Felon, but it can send a shield cluster below the threshold required to block tacnukes. The decision to link or not would take global information into account, and the best course of action would change too fast for players to manually control. A configurable linking stance would be unwieldy and riddled with edge cases, making it unpredictable. So it is better to keep linking innate, and let both sides of a battle work its straightforward behaviour into their plans.

Shield link is the highest-profile case of making an ability passive to avoid tricky optimisations, but we have many other more subtle ones. For example, Snitch and Imp have the ability to hide themselves by burrowing when stationary. If they took a significant amount of time to unburrow, then whether to burrow would be a decision with many strategic factors. Rather than make this decision, or make players manually press the burrow button, we made unburrowing near-instantaneous. Here are a few more examples.

Bulkhead and Fencer pack up quickly for similar reasons.
Units cannot hurt themselves with area of effect damage, as firing safely has tradeoffs.
Vehicles are very bad at moving in reverse, so that they do not seriously consider doing it.

To sum up, unit intelligence has three parts; vocabulary, competence, and not expecting too much. Think about what is going on next time you encounter a stupid unit. Does it lack the command language to understand what you are trying to tell it, does it lack the competence to achieve the goal, or do its abilities mean it has to solve complex optimisation problems which lack a satisfactory answer?

Index of Cold Takes[zero-k.info]

Zero-K

199

Zero-K v1.12.4.0 - Combat Engineer

Apr 6

The most experimental change of this patch gives Engineer Commanders the ability to build units out in the field. The goal is to make it more than the base building chassis. A much more normal change accentuates the speed of Strike Commanders by reducing the speed of the competing Recon Commander. Planes have been tweaked slightly, with the most notable change being Sparrow stealing Owl's radar jammer. Disco Rave Party has some ludicrous buffs since the newish spin-up requirement had a greater than expected impact on its power relative to Zenith.

For all its weird experiments, this patch is more about tech than balance. The engine has been updated with a new decal rendering system that performs better and will let us do more with explosion scars. Unit selections are drawn much faster and many of their edge cases have been solved. A new ambient occlusion shader gives the everything a bit more sense of depth. This is on top of a bunch of fixes and polish that built up over the last few months.

No Cold Take[zero-k.info] this week, because there was a lot to do for the patch.

Balance

Engineer Commander can now pick a unit to build out in the field.

Use the Copy Factory Blueprint command on a friendly functional factory to select a unit.
The unit can be switched during the game.
A unit is automatically selected from the plopped factory.
Set your plop selection under Settings/Unit Behaviour/Default States/Misc/Blueprint.

Recon Commander is slower to let Strike have an identity as the speediest commander.

Speed 43.5 -> 40.5 elmos/s
Jump reload time 20 -> 22/22/20/20/18/16 s
Jump speed 180 -> 135/135/142.5/150/157.5/165 elmos/s

Lightning Gun is better, particularly against swarms.

Reload time 1.83 -> 1.73s

Owl no longer jams, by popular demand[zero-k.info].

Removed 700 range radar jammer.

Sparrow is now the radar jamming plane.

Now has a 540 range radar jammer.
Increased manoeuvrability slightly to make coverage more consistent.

Hacksaw deals more damage to catch up to Phoenix.

Damage per volley 1000 -> 1400

Phoenix was a bit too good, especially when reused.

Rearm time 8s -> 10s
One-shot by Hacksaw as per above

Thunderbird has more health to escape Hacksaw.

Health 1200 -> 1600

Disco Rave Party spins faster, also by popular demand[zero-k.info].

Increased spin cap by 50%, increasing its peak rate of fire from 1 to 1.5 shots/s.
The spin bar has been rescaled so 66% is the old maximum.
Spin up to 66% is unchanged. It still takes 90s to reach its old spin.
Spin from 66% to 100% takes 40s.
Aiming is quite slow above 66%, so a fixed target is required to exceed the old spin cap.

Disco Rave Party is also deals more direct damage and is more accurate.

Accuracy improved by 20%
Red Killer damage 3000 -> 3500 (matches Eos)
Orange Roaster damage 300 -> 250
Orange Roaster duration 15s -> 8s
Orange Roaster AoE radius 320 -> 400 (larger than static shields)
Yellow Slammer damage 800 -> 1000
Green Stamper damage 400 -> 600
Green Stamper smooth radius 240 -> 300
Green Stamper smooths more per hit
Violet Slugger damage 450 -> 500
Violet Slugger slow damage 4500 -> 5000

Aircraft can no longer fly so far outside the map.

The external map border starts 400 elmos away, down from 800 elmos.
The border is softer, so brushing it is less drastic.

Graphics

Added new explosion crater scars to use the engine's new decal system. The new scars have better performance, stick to the ground properly, and have new features such as glow and variation by weapon type.
Added a screen space ambient occlusion widget. Basically, it adds subtle shading to put shadows in every nook and cranny. The widget is enabled for hardware that supports deferred rendering, which is most hardware.
Improved the walk animations of the Engineer and Recon Commanders.
Disco Rave Party has firing dust and complains every time it tries to turn.
Improved the look of Ogre missile explosions.
Fixed jittery Detriment launch smoke.
Improved Detriment and Jugglenaut stomp effects.
Made a few effects that were simulation-limited run at >30Hz if able.
Reaver aims more smoothly.

Interface

Updated selection circle rendering (thanks moreginger, and Beherith for the original shader). Selections look similar, but render much faster and resolve a few graphical edge cases suffered by the previous widget. Selection visuals can be configured under Settings/Interface/Selection/Default Selections.
Jumpleg units retain jump commands while midair so they can jump as soon as they find the ground.
Hermit auto skirmishes from slightly further away, making it better at dealing with Redback (thanks Mach565).
Improved replay controls (thanks moreginger).
Improved Athena and Newton selection volumes.
Control groups now obey selection rank.
Added an option for control groups to ignore some ranks.
Autogroups can now be used for buildings.
Autogroups no longer override manual groups set during production.
Added incomplete French and Ukrainian translations.

Maps

Added lava to Stronghold because it looks like it wants it.
Added boxes for Ravaged Remake v1.2

Awards

Some awards show up almost every game in nonsensical ways. To address this, the minimum threshold for a few awards has been raised.

Spoils of War requires 3.3x more reclaim.
Slow King requires 2x more slow damage.
Peacemaker requires 4x more disarm damage.

Modding

Add customParams.turn_accel_factor to control the angular inertia of units.
Add Spring.Utilities.ConcatArrays to concatenate arrays.

Fixes

Fixed split switching spectators to players in the split room.
Fixed load order of replays so the most recent replays show up first.
Fixed Bellicose Islands boxes (edge gap east).
Fixed a rare issue with the external map grid (thanks AntlerForce).
Fixed Newton launcher auto-jump sometimes causing jumps on the launch pad.
Fixed Envoy overkill prevention.
Fixed command insert not working with line formations.
Fixed jumping units sometimes using their walk animation mid-air.
Fixed shields sometimes not activating when rapidly thrown out of the water.
Units no longer move to clear the "entrance" of plane factories when a plane is built.
Units that start retreating are no longer automatically deselected for spectators.
Fixed the select damaged/healthy hotkey presets.
Fixed Fire Once leaving Set Target applied.
Fixed Restore not working correctly on random maps and maps with changed water level.
Fixed Sparrow's wingtip ribbons.
Fixed teleportation sometimes leaving tracks.
Fixed slow and Stardust heat rounding.
Fixed missing ghosts for some campaign-only structures.
Fixed orbital drops of ships trying to land ships on the sea floor.

Zero-K

191

Cold Take #9 - Energy as Supply

Mar 23

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.info]

Zero-K

142

Cold Take #8 - Smoothly Flowing Economy

Mar 9

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[zero-k.info]

Zero-K

190

Cold Take #7 - Jumpjets and Jumplegs

Feb 24

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

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

Which units jump?

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

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

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

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

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

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

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

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

Jump physics

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

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

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

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

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

What are jumplegs?

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

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

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

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

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

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

Where can units jump?

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

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

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

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

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

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

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

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

Distilling some principles

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

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

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

Index of Cold Takes[zero-k.info]

Zero-K

157

Cold Take #6 - Physics vs. Formulas

Feb 10

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[en.wikipedia.org], 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[zero-k.info]

Zero-K

200

Cold Take #5 - Making Metal

Jan 27

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[zero-k.info]

Zero-K

253

See More Content

No more content. So sad.

You can help: share a screenshot, make a video, or start a new discussion!

Returning to where you were last on this page...

Cancel