Food decay [enhancement]

[SelfSealShelf]

The only options we have to control food is producers, randomized spawning and the option "food blocks reproduction"

Unblocking reproduction inevitably results in a highly optimized space filling sedentary producer evolving. With only one or two killer cells they can stop predetation by movers and shape their environment. I call these 'thorns'. They no longer need movers to clear out dead thorns, and can block the reproduction of movers by either killing them or just taking up as much space as possible.

The other binary alternative is to have food block reproduction. This tends to lead to die-outs of vegetive producers. Movers either evolve into omnivores that can prey on both vegetive and mover life, or evolve into "fructivores" that only take excess food produced by plants. Fructivores are exceedingly rare however, as they're only distinguished from omnivores by the presence of a single cell which greatly increases their individual fitness. You can shorten the lifespan of organisms to prevent excessive predetation by movers, but that significantly limits how big organisms can get and consequently works against the rise of fructivores that require complexity.

There's also the rare but possible extinction scenario with 'movers can produce food' of a highly optimized space filling mover gradually covers the map in corpses, running out of space.

I think the solution is a food decay mechanic. Food decay in seconds would allow some predetation by movers without the plants needing them to survive, as they can continuously repopulate decayed regions if movers don't clear it out in time.

[groudas]

I agree.

Without food decay, this "real state" problem caused by excessive copses greatly reduce the viability of a large number of environment setups.

I can't code but I imagine it would be costly, CPU wise, to track each food pixel "age" for decaying purposes, but I think a "chance" based mechanic would be easy to implement, with light CPU cost.

[xkortex]

I imagine it would be costly, CPU wise, to track each food pixel "age" for decaying purposes,

Yeah, you don't wanna maintain state with the food if at all possible. CellState is a lightweight object and should be kept that way. On top of that, the eatNeighbor mechanism checks for food tiles and mutates them. Any time you have this much shared state, parallelism gets harder.

It'd be fairly easy to have some sort of food_decay method in WorldEnvironment.update() which runs every N ticks, or maybe runs N rows at a time (just some sort of downsampling mechanism) and randomly picks food tiles to delete.

[groudas]

How about using the same the auto drop food function, but instead, "remove food"?

e.g.: the higher the setup value, higher number of random pixels being checked if there's food. If positive, remove that food.

[xkortex]

That would work and would be pretty easy to implement. It's just generateFood but converting food to empty. Performance is kinda suboptimal for a couple reasons but it'd be easy enough to try out and profile.

LifeEngine/src/Environments/WorldEnvironment.js

Lines 118 to 131 in 779d80a

	generateFood() {
	var num_food = Math.max(Math.floor(this.grid_map.cols*this.grid_map.rows*Hyperparams.foodDropProb/50000), 1)
	var prob = Hyperparams.foodDropProb;
	for (var i=0; i<num_food; i++) {
	if (Math.random() <= prob){
	var c=Math.floor(Math.random() * this.grid_map.cols);
	var r=Math.floor(Math.random() * this.grid_map.rows);
	if (this.grid_map.cellAt(c, r).state == CellStates.empty){
	this.changeCell(c, r, CellStates.food, null);
	}
	}
	}
	}

I literally just changed the rate to account for relative abundance and used the probabilistic deletion and it works pretty well actually. The next step would be to give it its own parameter.

This is a really naive implementation:

    deleteFood() {
        var num_food = Math.max(Math.floor(this.grid_map.cols*this.grid_map.rows*Hyperparams.foodDropProb/50000), 1)
        var prob = Hyperparams.foodDropProb;
        for (var i=0; i<num_food; i++) {
            if (Math.random() <= prob){
                var c=Math.floor(Math.random() * this.grid_map.cols);
                var r=Math.floor(Math.random() * this.grid_map.rows);
                var state = this.grid_map.cellAt(c, r).state;
                if (state == CellStates.food){
                    this.changeCell(c, r, CellStates.empty, null);
                }
            }
        }
    }

One consequence of this method is that it introduces a positive feedback mechanism towards some median food level. Even with a low food drop rate and high decay rate, the probability of hitting a food cell to remove is way lower than adding one. As the food density increases, it balances out. Also the way it's written above, it makes num_food attempts. I could probably have it keep trying until a certain threshold it met (you'd have to be careful not to get into a loop condition). That's why a more "methodical" decay mechanism might work better. I'll need to fiddle with it.

...
Wow, okay I've been running with separate drop and decay rates for a bit, I have drop to 0 and decay to 100. I'm already noticing things are a little bit more dynamic. There's less aggressive tiling of the plane by thorny plants. At producer rate = 4.0 I'm not seeing any real increase in animal complexity though. Still the same initial bloom -> plants start to dominate -> overgrowth -> bloom of small animals -> population crash -> repeat.

I turned down producer=3.0, lifespan=70, drop=5, decay=100, now we are cooking! Structural complexity is increasing. I'm seeing way more animals with affinity towards armor and producer (normally it seems to always converge onto toward food, away from killer/armor). A little while later the animals have eaten all the plants.

Needs some fiddling/balancing but I'm 100% behind the idea of a food decay of mechanic of some sort.

[xkortex]

See https://github.com/xkortex/LifeEngine/tree/xkortex/60-food-decay for trying this out.

[MaxRobinsonTheGreat]

Would you mind opening a pr? It'd make it easier to checkout.

My intuition tells me this wouldn't really be that big of a change, but it seems like you're seeing some new things and I'd like to check it out.

[xkortex]

Sure, not totally ready to merge it but I guess I could open a draft PR.

You know you can do a git remote add xkortex https://github.com/xkortex/LifeEngine.git then git fetch --all to add someone elses remote to your working dir, right?

[xkortex]

#66

[groudas]

Even with a low food drop rate and high decay rate, the probability of hitting a food cell to remove is way lower than adding one.

Like you pointed later, the solution would be finding a "default" decay parameter that will be the "starting point" for this mechanism.

Unfortunately I couldn't run your code because I have no idea how to do it.

I downloaded the ZIP file, extracted, run the "index.html" with a browser, but only a faulty and buggy version of the original interface opened.

[xkortex]

Are you able to operate a CLI and install NPM? https://github.com/MaxRobinsonTheGreat/LifeEngine#building

Otherwise it's gonna be tricky.

Do you know how to use docker? I could PR a dockerfile if folks might think that would help, but I suspect if you can't run NPM you probably can't run docker either.

[groudas]

Are you able to operate a CLI and install NPM?

No... I tried to run the "npm run build" at the windows command line, but I realized I don't have those JS frameworks to run it (docker, npm).

But, nevermind, later I'll look into it.

[MaxRobinsonTheGreat]

Sounds like you need to install npm on your machine first, then run npm install in the directory you downloaded, then npm run build-dev for development builds.