Solving the Nucleus Paradox

[domin2ktr]

Brief Description of What This PR Does

This PR gives a buff of +30% bioprocess speed and -10% osmoregulation cost. This is done so that the nucleus finally has a meaning other than "this part is needed for more advanced organelles"
As a result, this gives a break-even point for the core when the cell size reaches approximately 25 hexagons.

This has biological justifications in the form of the fact that the nucleus reduces the likelihood of errors in the production of proteins, and also accelerates the production of proteins, which reduces the requirements of osmoregulation, as well as increases the efficiency of organelles (since proteins are used to produce energy, accordingly, increasing the rate of protein production will increase the rate of energy production).

Related Issues

• 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)

[revolutionary-bot]

The lead programmer for Thrive is currently on vacation until 2025-07-07. Until then other programmers will try to make pull request reviews, but please be patient if your PR is not getting reviewed.

PRs may be merged after multiple programmers have approved the changes (especially making sure to ensure style guide conformance and gameplay testing are good). If there are no active experienced programmers who can perform merges, PRs may need to wait until the lead programmer is back to be merged.

[0HyperCube]

Hi @domin2ktr,
You seem to be having a bit of trouble updating the ProcessSpeedModifier and OsmoregulationModifier. You might be interested to review the following patch:

diff --git a/src/auto-evo/simulation/SimulationCache.cs b/src/auto-evo/simulation/SimulationCache.cs
index e8528674f..630a44c68 100644
--- a/src/auto-evo/simulation/SimulationCache.cs
+++ b/src/auto-evo/simulation/SimulationCache.cs
@@ -536,6 +536,15 @@ public class SimulationCache
 
         var result = MicrobeEnvironmentalToleranceCalculations.ResolveToleranceValues(tolerances);
 
+        if (!species.IsBacteria)
+        {
+            // 30% bioprocess speed bonus if have nucleus
+            result.ProcessSpeedModifier *= 1.3f;
+
+            // 10% osmoregulation bonus if have nucleus
+            result.OsmoregulationModifier *= 0.9f;
+        }
+
         cachedResolvedTolerances.Add(key, result);
         return result;
     }

P.S. Mostly you do development on your local computer with git rather than editing directly on GitHub.
P.P.S. Also I recommend you don't commit to the master branch of your fork. I suggest you instead create a different branch allowing you to have multiple PRs at the same time.

I hope that helps.

[domin2ktr]

Hi @domin2ktr, You seem to be having a bit of trouble updating the ProcessSpeedModifier and OsmoregulationModifier. You might be interested to review the following patch:

diff --git a/src/auto-evo/simulation/SimulationCache.cs b/src/auto-evo/simulation/SimulationCache.cs
index e8528674f..630a44c68 100644
--- a/src/auto-evo/simulation/SimulationCache.cs
+++ b/src/auto-evo/simulation/SimulationCache.cs
@@ -536,6 +536,15 @@ public class SimulationCache
 
         var result = MicrobeEnvironmentalToleranceCalculations.ResolveToleranceValues(tolerances);
 
+        if (!species.IsBacteria)
+        {
+            // 30% bioprocess speed bonus if have nucleus
+            result.ProcessSpeedModifier *= 1.3f;
+
+            // 10% osmoregulation bonus if have nucleus
+            result.OsmoregulationModifier *= 0.9f;
+        }
+
         cachedResolvedTolerances.Add(key, result);
         return result;
     }

P.S. Mostly you do development on your local computer with git rather than editing directly on GitHub. P.P.S. Also I recommend you don't commit to the master branch of your fork. I suggest you instead create a different branch allowing you to have multiple PRs at the same time.

I hope that helps.

Will this have an effect on the player's cells as well?

[0HyperCube]

@domin2ktr I have created an updated diff that also alters the cell editor:

diff --git a/src/microbe_stage/MicrobeEnvironmentalToleranceCalculations.cs b/src/microbe_stage/MicrobeEnvironmentalToleranceCalculations.cs
index 429bc84c1..953d1ef02 100644
--- a/src/microbe_stage/MicrobeEnvironmentalToleranceCalculations.cs
+++ b/src/microbe_stage/MicrobeEnvironmentalToleranceCalculations.cs
@@ -1,6 +1,7 @@
 using System;
 using System.Collections.Generic;
 using System.Diagnostics;
+using System.Linq;
 
 /// <summary>
 ///   Helper class that contains all the math for environmental tolerances in one place (though the microbe editor and
@@ -9,6 +10,8 @@ using System.Diagnostics;
 /// </summary>
 public static class MicrobeEnvironmentalToleranceCalculations
 {
+    public static OrganelleDefinition Nucleus = SimulationParameters.Instance.GetOrganelleType("nucleus");
+
     /// <summary>
     ///   Calculates the total overall score of environmental tolerance without giving the sub-scores
     /// </summary>
@@ -60,6 +63,7 @@ public static class MicrobeEnvironmentalToleranceCalculations
             resolvedTolerances.UVResistance = 0;
 
         CalculateTolerancesInternal(resolvedTolerances, noExtraEffects, environment, result);
+        result.HasNucleus = organelles.Any(orgnaelle => orgnaelle.Definition == Nucleus);
 
         return result;
     }
@@ -206,6 +210,15 @@ public static class MicrobeEnvironmentalToleranceCalculations
             result.OsmoregulationModifier *= Math.Min(Constants.TOLERANCE_UV_OSMOREGULATION_MAX, 2 - data.UVScore);
         }
 
+        if (data.HasNucleus)
+        {
+            // 30% bioprocess speed bonus if have nucleus
+            result.ProcessSpeedModifier *= 6f;
+
+            // 10% osmoregulation bonus if have nucleus
+            result.OsmoregulationModifier *= 0.1f;
+        }
+
 #if DEBUG
         if (result.OsmoregulationModifier <= MathUtils.EPSILON)
         {
@@ -435,4 +448,5 @@ public class ToleranceResult
 
     public float UVScore;
     public float PerfectUVAdjustment;
+    public bool HasNucleus;
 }

[domin2ktr]

Hi @domin2ktr, You seem to be having a bit of trouble updating the ProcessSpeedModifier and OsmoregulationModifier. You might be interested to review the following patch:

diff --git a/src/auto-evo/simulation/SimulationCache.cs b/src/auto-evo/simulation/SimulationCache.cs
index e8528674f..630a44c68 100644
--- a/src/auto-evo/simulation/SimulationCache.cs
+++ b/src/auto-evo/simulation/SimulationCache.cs
@@ -536,6 +536,15 @@ public class SimulationCache
 
         var result = MicrobeEnvironmentalToleranceCalculations.ResolveToleranceValues(tolerances);
 
+        if (!species.IsBacteria)
+        {
+            // 30% bioprocess speed bonus if have nucleus
+            result.ProcessSpeedModifier *= 1.3f;
+
+            // 10% osmoregulation bonus if have nucleus
+            result.OsmoregulationModifier *= 0.9f;
+        }
+
         cachedResolvedTolerances.Add(key, result);
         return result;
     }

P.S. Mostly you do development on your local computer with git rather than editing directly on GitHub. P.P.S. Also I recommend you don't commit to the master branch of your fork. I suggest you instead create a different branch allowing you to have multiple PRs at the same time.

I hope that helps.

Why it chek failed?

[0HyperCube]

@domin2ktr the check failed because SimulationCache.cs line 547 has trailing white space.

[domin2ktr]

@domin2ktr the check failed because SimulationCache.cs line 547 has trailing white space.

It remains to wait until someone allows the merging.

(And by the way, will they add me to the credits?)

[Deus-Codes]

Good initiative to take this on yourself. I will take a look at it. My initial reaction is that I'd prefer it to be attached to a blatant mechanic such as a size-related cost just to make its functionality more apparent, but this could definitely do otherwise.

[adQuid]

I would like to add that we already have a 50% damage reduction for eucaryotes that we never tell the players about, that was our first attempt at addressing this issue #3341

Personally I was never in love with that idea (even though I made the first PR about it), so I'm fine if we want to replace it, just posting for awareness when balancing.

[domin2ktr]

I would like to add that we already have a 50% damage reduction for eucaryotes that we never tell the players about, that was our first attempt at addressing this issue #3341

Personally I was never in love with that idea (even though I made the first PR about it), so I'm fine if we want to replace it, just posting for awareness when balancing.

As deus said, "we need to focus on more general game mechanics", so he added the sunlight tolerance mechanic first, rather than the preferred flowers for photosynthesis mechanic.
That's why I think the energy bonus is better, it gives more universal, meaningful and general, while the health increase is only useful in some situations.

[Deus-Codes]

I'm in agreement with Rathalos (Accidental-Explorer) here. The effect should be much more subtle in my opinion.

The thing with the nucleus is that it represents a significant progression in the Microbe Stage. If the part is extremely beneficial from a really early part of the game, it is much less of a goal the player must build to and much more of a part which has immediate benefit.

Again, and as Rathalos says, the bonus being this strong completely throws off balancing for the rest of the game, and can encourage the evolution of the nucleus by turn 4 or so.

On Earth, the nucleus evolved atleast 2 billion years after life first evolved. In Thrive, that amount of time is equal to 20 generations. I'm not saying that generation 20 should be the target for when the player starts placing down the nucleus, but it shows that the nucleus really took a while to place down. Such an expansion of the player's capabilities should be more of a challenge to build up to, and the paradox is meant to be a subtle nudge for the player and AI to encourage some +/- rather than it being just an immense cost sink. But it should still be a bit cost.

[domin2ktr]

I'm in agreement with Rathalos (Accidental-Explorer) here. The effect should be much more subtle in my opinion.

The thing with the nucleus is that it represents a significant progression in the Microbe Stage. If the part is extremely beneficial from a really early part of the game, it is much less of a goal the player must build to and much more of a part which has immediate benefit.

Again, and as Rathalos says, the bonus being this strong completely throws off balancing for the rest of the game, and can encourage the evolution of the nucleus by turn 4 or so.

On Earth, the nucleus evolved atleast 2 billion years after life first evolved. In Thrive, that amount of time is equal to 20 generations. I'm not saying that generation 20 should be the target for when the player starts placing down the nucleus, but it shows that the nucleus really took a while to place down. Such an expansion of the player's capabilities should be more of a challenge to build up to, and the paradox is meant to be a subtle nudge for the player and AI to encourage some +/- rather than it being just an immense cost sink. But it should still be a bit cost.

I'm in agreement with Rathalos (Accidental-Explorer) here. The effect should be much more subtle in my opinion.

The thing with the nucleus is that it represents a significant progression in the Microbe Stage. If the part is extremely beneficial from a really early part of the game, it is much less of a goal the player must build to and much more of a part which has immediate benefit.

Again, and as Rathalos says, the bonus being this strong completely throws off balancing for the rest of the game, and can encourage the evolution of the nucleus by turn 4 or so.

On Earth, the nucleus evolved atleast 2 billion years after life first evolved. In Thrive, that amount of time is equal to 20 generations. I'm not saying that generation 20 should be the target for when the player starts placing down the nucleus, but it shows that the nucleus really took a while to place down. Such an expansion of the player's capabilities should be more of a challenge to build up to, and the paradox is meant to be a subtle nudge for the player and AI to encourage some +/- rather than it being just an immense cost sink. But it should still be a bit cost.

I've already reduced the bonus to 33%, which I think is quite sufficient. Furthermore, I can say that even without this osmoregulation bonus, it's possible to reach the core in 4-5 generations using photosynthesis + metabolosomes or chemolithotrophy (I even have a screenshot of how I achieved multicellularity in less than a billion years). So I don't think a 33% bonus will change much.

[Accidental-Explorer]

I have to admit it is now a bit difficult to judge the effect this would now have in master considering Deus' balance changes now added there (in particular the oxygen and ATP production changes, as well as the change to nucleus mass).

But overall I think 33% is still a very large bonus. Even if you have just 7 hexes, a nucleus adds less to your total cost than 4 cytoplasm. The effect is still stronger than membrane choice (because it effects both osmoregulation and movement cost). (By the way, testing this I noticed that the nucleus' cost modifier does not affect the osmoregulation cost in organelle tooltips. It probably should.) Going forward after placing the nucleus, every hex you place takes up 33% less ATP.

To repeat myself from before: don't think "how much do I need to reduce this bonus to be reasonable" instead think "how small can I make this bonus while still having an effect".

Right now, taking into account its own bonuses, the Nucleus by itself has an ongoing ATP cost of 12. For example, reducing the bonus to 20% but also decreasing the base cost of the nucleus to 8 (instead of 9), will keep that at 12,8. So that would make the bonus less distorting while still making the nucleus a bit more easy to place.

But again, I really need to see this in combination with the rest of current balance to make any judgement.

[Deus-Codes]

1. With the new balancing changes to metabolism, rapid progress like that should now be much harder. Oxygen builds up much more slowly, and anaerobic respiration is now less powerful.
2. Even then, there’s still the added element in this PR of the nucleus reducing all future costs you place down. In most video games, global effects like this are scaled to be very subtle unless there’s a huge amount of effort in getting some really powerful loot or something. Because the nucleus is meant to be the first “level up” in Thrive, it can’t really be balanced to be rare enough to warrant such a huge bonus.
3. With the prior balancing, even though energy generation was extremely generous, you still had to be intentionally aware of all the costs associated with the nucleus and build your organism around that. With this, because the nucleus pays for itself extremely quickly, that layer of decision-making associated with progression is lessened.

So again, I think Rathalos’ suggestion of scaling this down with the approach of it noticeable would be more appropriate rather than ensuring that the nucleus is extremely beneficial.

[domin2ktr]

I have to admit it is now a bit difficult to judge the effect this would now have in master considering Deus' balance changes now added there (in particular the oxygen and ATP production changes, as well as the change to nucleus mass).

But overall I think 33% is still a very large bonus. Even if you have just 7 hexes, a nucleus adds less to your total cost than 4 cytoplasm. The effect is still stronger than membrane choice (because it effects both osmoregulation and movement cost). (By the way, testing this I noticed that the nucleus' cost modifier does not affect the osmoregulation cost in organelle tooltips. It probably should.) Going forward after placing the nucleus, every hex you place takes up 33% less ATP.

To repeat myself from before: don't think "how much do I need to reduce this bonus to be reasonable" instead think "how small can I make this bonus while still having an effect".

Right now, taking into account its own bonuses, the Nucleus by itself has an ongoing ATP cost of 12. For example, reducing the bonus to 20% but also decreasing the base cost of the nucleus to 8 (instead of 9), will keep that at 12,8. So that would make the bonus less distorting while still making the nucleus a bit more easy to place.

But again, I really need to see this in combination with the rest of current balance to make any judgement.

I think reducing the bonus to 25% would be optimal, you won't be able to become eukaryotic too quickly, but you can still reach a point where the core saves more energy than it consumes.

[Accidental-Explorer]

I think reducing the bonus to 25% would be optimal, you won't be able to become eukaryotic too quickly, but you can still reach a point where the core saves more energy than it consumes.

Of course, I do think that is moving in the right direction.

Though keep in mind the nucleus does not necessarily have to save energy. It's a development that IRL happened once, and we really only need it to happen once. So it doesn't need to be something that's definitely worth it for every large cell. It needs to be at least just about worth it for large cells in certain situations, where it might not just be about the discount, but also the gained size and storage.

Once it exists, there is all the unlocked advanced organelles that should carry it forward.

But again, comparing it in the current balance would be very useful. Do you think you can update this branch with the latest commits in Thrive master?

[domin2ktr]

@hhyyrylainen merge this pr. I consulted about the balance and also changed the descriptions.

[Accidental-Explorer]

@hhyyrylainen merge this pr. I consulted about the balance and also changed the descriptions.

Does the osmoregulation cost in the tooltip when hovering over organelles in the tab now update after you have a nucleus?

[hhyyrylainen]

I really think it would be much better for these key stats to be included in the list of buffs and debuffs the organelle has (so a different part of the tooltip as well), because otherwise at a glance these very important stats that affect almost everything about the player's cell will be easy to miss for players who are in general notoriously bad at reading more than a few sentences.

And for this tooltip text, I think this is something that will be balanced a bunch so I kind of think the numbers should not be hardcoded into the text, but rather put in as placeholders ( {0}, {1}) and then during runtime updated with the actual values, because otherwise any balance changes will break the translations etc. which would cause a lot of problems for balancing this change (I do realize that the 50% damage reduction is hardcoded text but that's different I think as the exact value of that has never been a topic of debate).

[hhyyrylainen]

Does the osmoregulation cost in the tooltip when hovering over organelles in the tab now update after you have a nucleus?

That's also a very good thing to test that every display updates correctly upon placing or undoing the nucleus.

[domin2ktr]

I really think it would be much better for these key stats to be included in the list of buffs and debuffs the organelle has (so a different part of the tooltip as well), because otherwise at a glance these very important stats that affect almost everything about the player's cell will be easy to miss for players who are in general notoriously bad at reading more than a few sentences.

And for this tooltip text, I think this is something that will be balanced a bunch so I kind of think the numbers should not be hardcoded into the text, but rather put in as placeholders ( {0}, {1}) and then during runtime updated with the actual values, because otherwise any balance changes will break the translations etc. which would cause a lot of problems for balancing this change (I do realize that the 50% damage reduction is hardcoded text but that's different I think as the exact value of that has never been a topic of debate).

I don't think this is a cause for concern. The percentage values ​​stand out from the rest of the text, so players will notice (plus, I decided to keep the description brief). And the osmoregulation and movement cost reduction values ​​set in the core are unlikely to change more than a few times. Besides, this change isn't significant enough to be too concerning.

Stop wasting time already. I think it's ready for merge.

[Deus-Codes]

When we bring things up for implementation, we aren’t just making things up - they are constants and necessities for every part of the game, and are necessary before implementation. All features are to be judged in their quality of implementation by the programming team, and all features are to be judged for their balancing and value by the design team. So when we say things need to be changed, things need to be changed. With all due respect - it is up to us what goes in to our game, and how it is implemented.

There is room for discussion about new features of course, and different interpretations. But when we say that a change is significant and requires proper accessibility/documentation, we mean it. All features get judged by the same standard your PR is getting judged by.

You’ve displayed a dismissive and combative attitude towards multiple team members of the development team now, taking their input and contributions for granted. If you continue with this disrespectful behavior, we flat out won’t accept this PR, even if it’s the greatest thing we’ve ever seen. Knock it off, and react accordingly to the input of the lead programmer of the team.

[hhyyrylainen]

Thank you, Deus. I don't like demanding tone when asking for a PR to be merged.

And just to be clear, these aren't just arbitrary requirements, but ones for keeping the game codebase manageable, because Thrive will absolutely turn into a spaghetti mess that would eventually make any significant game progress impossible to do unless we stay vigilant and improve the quality of all changes before they are finalized.

Also from my point of view having done some major overhauls to Thrive somewhat recently, it is very bad when I need to update some code that is not sufficiently documented / I don't understand it and end up making mistakes as a result. So that's an extra point why I want contributions from other people to be polished to close to perfection, because if there is a problem I'm the one who has to deal with that as most people disappear from the project after a year or two, and many bugs are discovered only after multiple years.

So as such I'm asking that you would please do those few more changes to the flexibility of this feature so that future developers (and balance tweakers, like Deus) will have a much easier time adjusting this feature. Though, again I'm like really burnt out with reviewing this PR, so could you please then ask someone else to review your work before I would do further checks?

[domin2ktr]

I decided to reorganize my fork, since I can't make it so that the pr is copied from the branch, and not the fork itself, now the solution to the kernel paradox is transferred here:
#6595