Hello,
We have another dose of human generated facts for you.

I was planning to write about these biter and enemy behavior changes before the 2.1 release, but an unfortunately timed neck injury led to it being postponed.
The silver lining here is that now I can write about all the player reactions and funny bugs we've found along the way.

We might be getting into controversial territory here, but I like the biters and I like fighting them. I like clearing nests when expanding. I especially like defending against them when they smell my success.

However I never had fun with the expansion groups.
The whole feature just didn't seem to land right, and I would like to know if many other players agree — so let's delve right in.

Enemy expansion planner

The enemy expansion planner is one of those systems that has been around for a very long time (2013), and while it has had its improvements and fixes over time, it never really received a holistic review of how it was working in the modern context of the game.

Expansion groups were too small, making for weak, ineffective expansions

While we tuned and balanced map generation to make the nests a challenge, the expansion planner only ever sent small sorties to expand.

Small expansion nests do not really create a challenge, they just annoy the player and create busywork. It would feel much more compelling and meaningful to have one large expansion nest rather than 10 tiny ones, so I decided to move in that direction:

1. Increase group size with evolution factor.
2. Modify group size dependent on the map generator biter base size.

The goal with the changes, is that at any point in the game, an expansion party would be sized to present a good challenge at your current technology level.
Another guiding principle was to try to get the expansion nests to match existing ones, so that you can't tell which were from the map generation and which were from the expansions.

The numbers in the initial 2.1.0 release seemed a bit too strong (Experimental Biter expansion too strong), so in 2.1.13 I have tuned back the numbers:

(For those wondering, a graph for 2.0 would be a straight line from 5 to 20)

In short, the bases will start smaller (from 20 down to 10), but scale to the same max size of 80. The game picks a random number between the min and max when dispatching an expansion group. You can also notice the variance between min and max was reduced in 2.1.13.

There was also a bug causing the groups to settle a little bit too close to the factory walls (Expansion party worms spawn too close to wall and destroy defenses) which I fixed for 2.1.13, so there should be less pressure in this regard.

Exploring early would nerf expansions

The expansion planner time between expansions didn't scale with the number of candidates. So if you had a lot of candidates somewhere far away, then you wouldn't get any expansions near your base. This led to an unfortunate inverse difficulty relationship:

• Players who explored around the map early would experience fewer expansions near their factory.
• Biter nests in explored territory would 'thicken' and become much denser than intended.

To solve this, I did a mostly fresh rewrite of the heuristic and penalties for the candidate chunks, trying to ensure that areas explored but otherwise untouched by the player wouldn't have an effect on the expansion behavior. You can see the difference below:

Expansion candidates before (left) vs. after (right)
Greener = Higher probability.

The result is that not only do we have significantly fewer candidate chunks, but that they are more relevantly placed close to open areas or areas the player has cleared before. Expansions should now feel more predictable as well, the timing and pressure should be more consistent.

Another part of the rewrite was to untangle some subtle biter related assumptions, which were causing problems with the Pentapods on Gleba (Pentapod Expansion Broken).

Build base behavior

The expansion planner tells a group of biters when and where to go and build a base, but the actual building was carried out by a unit group with a 'Build base' command. Similar to the expansion planner, there were many subtle assumptions and hardcoded numbers throughout the logic, and the functional difference before and after is hard to explain.

The most noticeable change is to the cooldown between building the entities.

Beforehand this was calculated as 5 ticks per hitpoint of built entity, which sounds nice but effectively made the biters act inconsistently and idle for a huge amount of time (building a few worms could take over 20 minutes). It also again had an inverse difficulty curve, where late game nests would build significantly slower than weaker early game nests.

Now the cooldown is static, and is a number we can easily tune and adjust. For the initial 2.1 release, I had it set to 5 seconds, you can see its relevance below:

5 seconds between entities initially seemed fine, but after more playtesting and player feedback, I realized it was probably a bit on the quick side. It's also nice to be able to 'catch' the biters in the act of expanding, which a longer cooldown would give further opportunity for.

So for 2.1.13 we have increased the cooldowns: 30 seconds by default, and 10 seconds for Deathworld.

As with many tasks, the idea that "If you do things right, people won't be sure you've done anything at all" definitely applies here... The biter expansion groups should just act like you would have always thought they acted (a lot of the weirder implementation details were not immediately apparent).

Units define built entity

Modders may notice that now the entity being built by the unit is now defined by the unit itself (2.1 API doc).
This allows much greater control and actual use of the build base behavior outside the specific base game context, and generally makes more sense than the prior system.

As a 'celebration' of this possibility, I used it to add a 'Biological caste' system to the biters:

• Biters become Biter/Spitter spawners.
• Spitters become Worms.

I thought it was clever and great from some lore or naturalistic perspective... and soon a bug report came in: Oops! All worms!

Oops! All worms!

It turns out, by chance and RNG of map generation, the groups can send just spitters or biters, which means the resultant expansion base would be exclusively worms or spawners respectively. Also in the early game, we don't even spawn spitters, so all groups would always be 100% biters (Early game expansions not spawning any worms).

I mean... it could be a nice feature, some expansions are more spawners, some are more worms... but when the map generation is a pretty consistent 50/50 split, I don't think it's worth the inconsistency, and it clashes with the prior goal of "you can't tell which nests are from the map generation and which are from expansions".

So with 2.1.14, I tweaked the definitions so it acts like 2.0: Biters and Spitters can both become Spawners and Worms.

Expansion base built alert

Even with the increased base building cooldown, it can still happen that you look away for what feels like only a moment, only to be met with an unexpected collection of pals frolicking on your doorstep.

An inconvenient surprise in my 2.1.13 playtesting.

We could espouse the virtue of being vigilant with checking the map... but we have machines to do that for us. So we've added a new alert: if an expansion base (worm or spawner) is built in a chunk with active radar coverage, you'll receive the 'expansion base built' alert.

Now we know

The alert only applies to chunks with active coverage, and a radar's 'far scan' might catch them at the right time if you're lucky.

So to wrap up, I just want to restate what we've changed to accomplish the goal of "make enemy expansion nests more fun":

• Expansion groups are generally bigger but less frequent.
• Enemy expansions are directed more toward open areas instead of thickening infested areas.
• Biter base building is more robust and its speed is tuneable.
• If a biter nest is being built in your radar coverage, you will be alerted about it.
• We've been fixing bugs and tweaking things based on your feedback.

As always, let us know what you bite at the usual places.