Knuckle Cracker

Simply put, it was intended to be a Creepivorous lifeform, which would adapt to your strategy by a evolutionary process. For example, killing any that were vulnerable to Snipers would mean that there were almost no "Snipable" genetics in the pool. And so on for Beams, Nullifiers (partially), Creeper eating/dumping, and other stats I don't currently recall (altitude?).

However, there has to be a trade-off for better stats, otherwise everything becomes invincible, lightning-fast, and dumping vast amounts of Creeper.

I chose to do this by increasing Creeper required for upkeep. The problem was that, Creeper being the limiting resource, every scrap available was used up. This meant that after an initial flood (when the population boomed) the Creeper became so thin that a single Pulse Cannon could hold it off, and most of the population died off. The map was then pure cleanup, and merely destroying Creeper was enough to starve the custom units.

It might work if there was a different trade-off, or if I had allowed for indefinite improvement.

The other problem is that for this to work correctly, there should be behavioural change, which involves more variables and thus more lag and complexity; and a "large" population. For a half-dozen variables, you want about 2^(6*2)=4096 units in order to allow a reasonable convergence rate. This is impractical due to lag, unless they worked on a very simple algorithm. Dropping to a much slower method, still with 6 "genes", we can get to 6*2^2=24 units, with high risks of genetics being lost.

Having written this (and automatically considered methods to circumvent the flaws), I might return to the concept, but not for some time. Feel free to attempt it yourself, it is likely to be a good exercise in script structuring.

The intended lifecycle:

Unit spawns, has stats. Eats Creeper, starves without. If killed, drops stomach contents (possibly with interest, can't recall).

Unit occasionally lays "eggs" (ish) with slightly different stats. These hatch in Creeper.

Unit has a stat that is "chance to be invisible to Beams", similar for Snipers.

If you use Beams, then there will be fewer units surviving (and laying "eggs") which are Beam-targetable. Therefore, any eggs laid are more likely to have a high "Beam-invisibility" chance. Eventually, every unit will be 99% likely to be Beam-proof.

In order to make sure that you don't end up with a crowd of organisms running around that are proof against anything, I had to put in a cost for being better. So, better armour requires it to eat more Creeper for upkeep. This means that, having higher requirements, invincible units would be out-bred by units which didn't need as much Creeper if the other units could survive even nearly as well.

If the stats could improve without any cost, then the units would become progressively better, until they were unkillable.

However, with a trade-off, if there is no advantage to a given stat rising, then it will tend to fall, because there is a cost but no benefit.

The Creeper-appetite was my choice for a trade-off, because it also seemed like a tidy way to limit the population without (patently artificial) global variables. If there was insufficient Creeper to feed all of the units, they would die off until the Creeper could feed all of those which remained. If there was plenty, then the units would breed up until they ate it all.

The "ate it all" killed the balance, though, because the player weapons are designed to be balanced against vast amounts of Creeper.

The other flaw in this form is that without a vast population (about 5^gene count), it takes a number of generations for the genetic balance to adjust. Quite possibly, the probability-based genes, like Sniper-proofing, would not have more than three oherwise-weak units carrying them (and actively feeling the effects) at the time when the player attacks. This means that everything is vulnerable to something when the assault begins, and you can prevent the evolutionary mechanic from emerging by killing everything indiscriminantly.

Build a Runner-like unit, which has the capacity to split in two. More size means more health, less speed. Also more sight (only in H/V lines). Skip sight if you wish, moving randomly. Smaller units can regenerate in parallell, because there are twice as many. Larger units gain a resistance to an absolute amount damage each frame. All of these units will gradually grow. Each time you split, change the intended split size slightly on each child.

The variable that will auto-optimise is the size at which it splits.

Note that the population size and stats are not capped. However, there should be an optimum point (not necessarily the same) against any opposing setup. Cap damage limitation at 19 or so if it turns out to make invincible units.

Without a player killing units, this script will auto-generate a varied population, making it resistant to the "apocalypse rush" attack.

If it works, add a Core that picks two units and swaps their "split size" attribute, at random.

A better comparison might be in some Castlevania games that used elements. The elements in question are mainly holy and dark: holy beats dark, yet dark still beats holy.

I'm already done with the script, I just need to finish play-testing the map. Sadly, I intentionally implemented a "go big or go home" thing to be able to get the resources, though. I haven't implemented a "safe level" feature (where anomalies don't occur), so it's even worse.

Basically the unit upgrades specific enemy units (normal enemies are static), but it does so in a slightly different way. Rather than gathering upgrade points from corrupted totems, the unit gathers these points from uncharged totems. For each uncharged totem, the point gain interval decreases by a set amount. You can make this 15 frames, or even 1 full second.