Skip to content

Auto evo predator separation and behaviour handling#6866

Open
Accidental-Explorer wants to merge 41 commits intomasterfrom
auto-evo-predator-separation
Open

Auto evo predator separation and behaviour handling#6866
Accidental-Explorer wants to merge 41 commits intomasterfrom
auto-evo-predator-separation

Conversation

@Accidental-Explorer
Copy link
Copy Markdown
Contributor

@Accidental-Explorer Accidental-Explorer commented Apr 13, 2026

Brief Description of What This PR Does

This PR applies some penalties to Aggression and Fear behaviours to compound gathering miches, to represent fleeing and hunting interrupting the actual collection of said compounds.
This helps differentiate predator species more from the non-predators.

Additionally adds auto-evo effects and mutations for the Focus setting.

Also unifies some calculations between compound gathering miches which did not make sense to have in one but not the others.

Related Issues

  • Player observation that it's odd for compound-gathering AI in a dense cloud to instead start chasing them. (caused by high aggression)
  • Predators regularly get abnormally high populations because they're also competent autotrophs (part of the reason for toxin cell swarms)
  • Several behaviour settings are still static and unused by auto-evo

Progress Checklist

Note: before starting this checklist the PR should be marked as non-draft.

  • PR author has checked that this PR works as intended and doesn't
    break existing features:
    https://wiki.revolutionarygamesstudio.com/wiki/Testing_Checklist
    (this is important as to not waste the time of Thrive team
    members reviewing this PR)
  • Initial code review passed (this and further items should not be checked by the PR author)
  • Functionality is confirmed working by another person (see above checklist link)
  • Final code review is passed and code conforms to the
    styleguide.

Before merging all CI jobs should finish on this PR without errors, if
there are automatically detected style issues they should be fixed by
the PR author. Merging must follow our
styleguide.

@hhyyrylainen hhyyrylainen added this to the Release 1.1.0 milestone Apr 13, 2026
@Accidental-Explorer Accidental-Explorer changed the title Auto evo predator separation Auto evo predator separation and behaviour handling Apr 14, 2026
@Accidental-Explorer Accidental-Explorer marked this pull request as ready for review April 15, 2026 21:45
Comment on lines +39 to +40
new ChangeBehaviorScore(ChangeBehaviorScore.BehaviorAttribute.Aggression, 50.0f),
new ChangeBehaviorScore(ChangeBehaviorScore.BehaviorAttribute.Aggression, -150.0f),
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If adding more aggression is always a negative for this pressure (it appears to be?) then I'm not sure having a mutation that increases it is ever helpful? Any other pressures that has a positive score for should have that mutation already.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the case with many of the other behaviours as well. But the point is that it evaluates the whole pressure stack. In this case it can improve predator resistance for some species.

I previously had it in that pressure, but then it often got used when it would not be used if already taking the compound pressure into account.

Copy link
Copy Markdown
Contributor Author

@Accidental-Explorer Accidental-Explorer Apr 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To emphasise why the above could be a problem: ModifyExistingSpecies regularly prunes against the base species (rather than just pre-this-mutation) for the pressurestack to that point. So I don't want to create a situation where for some species nearly every mutant that gets out of GeneralAvoidPredationSelectionPressure has increased Aggression, but then any further mutation based on them gets pruned in the leaf nodes before it gets a chance to lower the Aggression to what is more fitting)

(Edit: and even if not explicitly pruning, I guess the frequent "top selection" would catch them as well?)

But the mutation system is quite complex so I could be missing something.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's also the fact that ChangeBehaviourScore as far as I can tell just gives a single mutant with a random change within the given range, so that seems like likely to overshoot the optimal point. The opposit gives some opportunity to compensate in the other direction.

}
else
{
if (compound == Compound.Hydrogensulfide)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a multiline if so it should use braces according to our styleguide.

@hhyyrylainen
Copy link
Copy Markdown
Member

Are we waiting for @GameDungeon to look at this again?

In the meantime I did a code review, there were a few small style things, other than that all the math everywhere looked about the same as elsewhere in auto-evo.

I did also do some performance testing. For reference 5 worlds to 15 gens took about 54 to 67 seconds on master. But on this branch the times were between 85 to 145 seconds, so it seems this has quite a heavy impact on auto-evo performance. That one longer time was an outlier but whereas on master the times clustered around 1 minute this branch has times clustered more around one minute and 40 seconds to 2 minutes, so there is almost a 100% increase in processing time caused by this PR and I think that is too much even if this makes auto-evo significantly better.

@Accidental-Explorer
Copy link
Copy Markdown
Contributor Author

Are we waiting for @GameDungeon to look at this again?

Yeah, pretty much. He seems busy recently though.

I did also do some performance testing. For reference 5 worlds to 15 gens took about 54 to 67 seconds on master. But on this branch the times were between 85 to 145 seconds, so it seems this has quite a heavy impact on auto-evo performance. That one longer time was an outlier but whereas on master the times clustered around 1 minute this branch has times clustered more around one minute and 40 seconds to 2 minutes, so there is almost a 100% increase in processing time caused by this PR and I think that is too much even if this makes auto-evo significantly better.

I'll investigate to see what's causing the most slowdown.

I think slowdowns are eventually inevitable once implementation of Miches for Multicellular starts, so I do want to strictly limit slowdowns before then.

@Accidental-Explorer
Copy link
Copy Markdown
Contributor Author

After an extensive testing on 20 worlds, can confirm that out to generation 21, auto-evo time is multiplied by about 1.8, with the time step from generation 20 to 21 being closer to multiplied by 1.9.

The number of total and living species is actually slightly lower in this PR. I think that's good, because it means it's not just a result of the new version being "better" at producing different species. So it should be possible to improve performance without worsening things.

@GameDungeon
Copy link
Copy Markdown
Contributor

GameDungeon commented May 4, 2026

I believe most of the new slowdown is from all of the behavior mutations. They are very cheap so they can flood the generated species with small variations of behaviors, which causes us to have to evaluate all of them.

I'm not sure it should be in this PR, but it would be nice to cache the pressures that are not changed by behaviors for the new species. Maybe in the hypothetical immutable species rework.

@Accidental-Explorer
Copy link
Copy Markdown
Contributor Author

I haven't tested this yet, but one potential culprit is that auto-evo now once again tries to delete any organelle, rather than only some of them. That was actually missing from the last rework by accident. Maybe can try to have a random sample of attempted deletions?

I believe most of the new slowdown is from all of the behavior mutations. They are very cheap so they can flood the generated species with small variations of behaviors, which causes us to have to evaluate all of them.

Though with the limit on "rolling through" mutants, only testing the specific mutants directly created by those mutations should really have any effect right?

@GameDungeon
Copy link
Copy Markdown
Contributor

GameDungeon commented May 4, 2026

Well you still have to test them at least once, which is the most expensive part as they are uncached. Deleting any organelle should have basically the same affect on performance as all of the behavior mods do, but it only happens once.

Other than that I don't have any specific comments on the code. Everything looks fine to me, so the output quality & performance are the only thing that matters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

Status: In progress

Development

Successfully merging this pull request may close these issues.

4 participants