In that case I’d suggest that we avoid naming upgrades after colors. As said, it would be strange to have a “brown chloroplasts” upgrade which doesn’t make the chloroplasts brown(er). So if we can’t/shouldn’t mess with the coloring of the cells/organelles I’d suggest going for more neutral upgrade names.
So the red-pigmented thylakoids could be named twilight thylakoids or penumbral thylakoids. THe brown pigments could be named cryophilic thylakoids.
This would solve another problem which was bugging me anyways: Stars other than the sun can have different wavelenghts and light colors, so the best chloroplast color for semi-lit environments on another planet might be something different than red. So upon rethinking I see multiple reasons for not naming upgrades after colors.
I think the colour based names are pretty good, because they actually indicate more scientifically what they do. I think. We have chloroplasts that aren’t required to be green so I don’t see that big of a problem here.
The difference to me is that we don’t call our normal chloroplasts “green chloroplasts”. Calling an upgrade specifically “brown” and then not making the organelle brown(er) feels weird to me. But if you guys like the color based names more nontheless then we will use those of course:)
I see, there’s an implicit assumption that the player knows that the “default” colour (due to Earth) of chloroplasts is green. It’s been talked about before that chloroplasts would be configurable and the player would need to match it to their star’s spectrum. I’ve not been keen on that idea as just unnecessary complexity that’s not needed (chloroplast colour is one thing I think we can pretty well handwave and say it just evolves to be whatever colour is needed). Before other parts of the microbe stage is complete I think reserving playing complexity for adjusting it is not a good idea.
I guess from that point of view naming the upgrades based on what they help with and not what they are, would be fine. Though, I won’t give a final conclusion before we have some kind of WIP implementation and can compare the options.
Since implementing endosymbiosis lite is at the top of the release 0.6.4 milestones list on GitHub, I figured that it might be a good time to clarify one or two things about it.
The issues description reads that
endosymbiosis lite is a system whereby engulfing prokaryotes the player can unlock organelles based on what the eaten bacteria had.
I agree that it’s probably not worth the computing power to keep track of what all of the AI species engulf during gameplay. But if this system is only for the player, we have to ask ourselves what to do about the AI. In my mind it’s fine if we keep things a bit easier for the AI as it sometimes needs a bit of an edge over the player, given that it can’t profit from a humans intelligence. I would however find it strange if no limitations apply to what kinds of eukaryotic organelles the AI can evolve. If eukaryotic organelles evolve through endosymbiosis for the player, we can assume that “canonically” that’s also how it works for the AI. It would be unrealistic then if the AI evolved an eukaryotic organelle which it couldn’t evolve through endosymbiosis under the given circumstances.
My proposal is thus to add a check to auto-evo to determine which eukaryotic organelles can be evolved by which species. Species X can evolve a eukaryotic organelle when either all of the following criteria are met:
- there is at least one species Y in at least one of the patches species X inhabits which is small enough that species X and which has the right prokaryotic organelle which would allow species X to unlock the corresponding eukaryotic organelle
- species X has a membrane type which allows for engulfment
- species X has a nucleus (I’ve also seen suggestions which would allow for non-eukaryote to also develop one endosymbiont, so I’m not 100% sure about this one but I would wager that right now the consensus is still to lock eukaryotic organelles behind the nucleus which I agree with btw)
or when species X already has a eukaryotic organelle of the kind in question.
I hope this system for the AI is simple enough and could be implemented along the player version of endosymbiosis lite.
I think that’s a pretty reasonable proposal. Still it’s a bit unlikely to come up immediately as the AI kind of first would need help to actually become eukaryotic (it’s very rare for the AI to get a nucleus)…
It’s pretty simple but it requires some code interlinkage. Right now the mutations generation doesn’t need to know anything else except what kind of species it is given. With this change the mutations generation would additionally need to be given a list of species that exist also in the same patch to perform the check if the mutated species is allowed to gain some eukaryotic part.
With the auto-evo exploration tool I’ve seen it pop up quite a few times I think. It’s also common for a AI species to split off the player once the player has evolved a nucleus. But you’re right, the AI has trouble evolving one in a regular playthrough if it can’t rely on the player to “help” it.
I’m glad the proposal is reasonable. And I agree, it doesn’t need to be implemented right away in tandem with endosymbiosis for the player. It can also be implemented a few updates later, and in the meantime people like me who are bugged by a “canonical” inconsistency in the game have to bite that bullet for some time. It would certainly help for immersion if the AI seems like it has the same logic applied to it as the player (even if the systems work differently), but it’s not like it would be an extremely jarring experience if the AI evolved eukaryotic organelles which it theoretically couldn’t for a few releases.
some rambling, feel free to ignore
I think this simple addition could lead to a few interesting emergent situations. It would mean that membranes which would block engulfing could be initially powerful, but would prevent a species from unlocking the powerful eukaryotic organelles. That way they might be dominant for a few generation, but would eventually face competition from species which first went for the eukaryotic organelles and only later evolved the engulfment-blocking membranes.
It’s exiting because other it adds a new kind of dependency of adaptions. The nucleus/eukaryotic organelles dependency is a positive one while this engulfment-blocking membrane/eukaryotic organelles dependency would be a negative one. Still, it feels like it wouldn’t be frustrating as it only takes one generation to switch to a membrane type which allows for engulfment.
Alright, so a few days ago I was thinking about some new features of Thrive and suddenly came upon some ideas on how to revitalize an older concept for a pilus upgrade, the long awaited straw pilus.
From a gameplay perspective, designing the straw pilus can be challenging as it must contend with the very much capable and effective base perforating pilus. Why bother stealing a few resources from another cell when you can just slice them open like a visceral pinata? The solution; Making the straw pilus more resource efficient at the cost of only harming one creature at a time.
So, I’ve devised the following concept as an ideal for the straw pilus.
Hunting with Straws
A straw pilus works quite differently from the classic perforating form. Instead of slashing and poking several cells at once, the straw pilus can only target a single prey item at a time. When a straw pilus collides with valid prey, it will “bind” the user to the prey and begin transferring the contents to the user. All the while, the prey will begin taking gradual damage and potentially even risk starvation if enough resources are stolen. This allows a predator to efficiently drain resources straight from the source instead of mopping up the diluted remains from a popped cell. At any point, the predator can release their prey by using the unbind hotkey.
There is no restraint in relation to size, and even the tiniest straw pilus wielding cell can hunt the largest prey. If the predator has a larger mass than it’s prey, they will be able to drag them around, and the prey will be quite limited in their options to escape. This can be seen as a “game over” state similar to engulfed digestion. If the prey is heavier than the predator however, the predator will be dragged around with their prey instead.
This sound pretty rough for prey… So how can they defend themselves from this new threat?
Avoiding The Straws
There are two primary ways to disconnect a straw user from it’s prey. The most reliable is spinning rapidly and vigorously. High turning speeds will eventually dislodge the predator. The higher your turning speed, the faster you are able to potentially dislodge them. Otherwise, taking any form of damage will also dislodge a straw user. Those loose toxin clouds might have a user after all!
Silica and calcium carbonate membranes may be potentially resistant or outright immune to the dreaded straw.
Possessing stored toxins could potentially make you an unhealthy snack for predators, unless they have some means to safely store or process it.
The major catch here is that if the predator is larger than the prey, there may not be much the prey is able to do, effectively resulting in the aforementioned “game over” state should they not get lucky.
This concept would bring a new and exhilarating form of combat to Thrive, open up more predatory options for cells unable to engulf, and make hh really want to have my head for devising something that requires physics collision calls akin to the colony binding system disaster of 2021.
Now, as much fun as being able to latch onto prey is, my biggest fear is how this would interact with the binding system in general. What happens if multiple straw users stab the same prey? Form a conga line reminiscent of basic food chain diagrams? Worse still, straws being used in conjunction with colonies?? There is a lot that could go horribly wrong. But if done right, it would be a wonderful mechanic, at least in theory.
All feedback is welcome.
The potential for dedicated parasite microbes with the straw pilus could lead to some interesting stuff down the line. Assuming the amount of resources you drain scales based on your size and you attach to a cell much larger than you that produces a lot of glucose through photosynthesis, you’d be able to survive forever bound to that one cell. Mabe someday there could even be a way for the “predator” to buff the “prey” and this could open the gate to symbiosis. Figuring out how to factor that into auto-evo sounds like a nightmare, though.
Bringing up endosymbiosis again, as implementation approaches. I will summarize the current concept which we can work on.
- Players will choose an endosymbiont from a list of priorly consumed organisms in the editor, represented by a + button in the organelle section. Endosymbionts can be transformed into an organelle based on their composition, and will be better or worse candidates to be transformed into an organelle based on their part count. Generally, the more parts of a specific type there are in a candidate, the quicker the candidate can be integrated into a specific part.
- When the player spawns in, they can consume the specified endosymbiont candidate, which gives the player abilities corresponding to the organelle they are attempting to unlock for that life. The player must successfully reproduce with that organelle candidate. If the player dies, they lose the endosymbiont, and must search for another of the candidate species to integrate. Engulfment does not penalize the engulfed specie’s population, and successful reproduction boosts the endosymbiont candidate’s population as well. This will help the endosymbiont stick around for long enough as long as the candidate species isn’t on the brink of extinction.
- After a certain number of successful reproductions, again specified by the number of parts within the candidate, the player fully unlocks the corresponding organelle. The number of generations needed to successfully integrate the endosymbiont is known to the player initially, so the player does not have to guess how many successful reproductions they need to unlock the organelle.
Players can only perform endosymbiosis once without the nucleus, meaning only one type of organelle can be unlocked. Placing down the nucleus allows for more organelles to be unlocked.
Potential Benefits
- Active unlock process increases engagement, strategy, and decision-making considerations, allowing players to experiment. It provides a sort of “task” to the player that isn’t necessarily placing down parts in the pursuit of a nucleus and that isn’t necessarily “find food”.
- Realistically represents the process of endosymbiosis.
- When combined with the more “traditional” alternate unlock conditions, provides a reward and incentive for players to utilize endosymbiosis.
If properly synergized with traditional unlock conditions, endosymbiosis will serve a unique role in being able to give players access to parts that they otherwise probably wouldn’t achieve with their given morphology. For example, if a player really wants to utilize toxins but can’t otherwise afford to significantly devote their morphology to unlocking toxin vacuoles, then they can engulf a toxin candidate endosymbiont enough times to unlock it otherwise. When combined with traditional unlock conditions, players can naturally stumble upon organelles that make sense for the player to evolve eventually even without a proper endosymbiont, while devoting attention to more unique parts.
This gambit sort of creates a meta-strategy to unlocking organelles that is similar to the real world evolutionary incentives of endosymbiosis. Organisms may often develop symbiotic relationships with other organisms to take advantage of metabolisms that they otherwise would likely not be able to count on. For example, the chloroplast likely evolved in a symbiotic relationship between a non-photosynthetic eukaryote and a photosynthetic prokaryote. Modern day plants would likely not have evolved photosynthesis “by themselves”.
So essentially, we end up with two strategical facets of the game which are both accommodating to experienced and less-experienced players…
- Players who are intimidated by endosymbiosis will eventually end up getting the parts they need by just playing the game. Or, players who are confident with endosymbiosis can just choose to unlock certain parts passively, while actively pursuing other parts.
- Players who utilize endosymbiosis are rewarded by access to game-changing organelles potentially quicker, and the option to unlock organelles that they otherwise probably wouldn’t unlock unless they change their morphology.
Potential Drawbacks
- Active process necessitates making sure the player knows that they have this option. If there are too many active processes going on at once without proper navigation, it could overwhelm newer players.
- Might clutter editor with new button added.
- Traditional unlock conditions for organelles must be balanced to ensure that endosymbiosis is viable; if players end up unlocking things easily without much action, then there is no reason to engage with endosymbiosis.
Making endosymbiosis an active process gives another decision for players to consider. More decisions are definitely needed currently in Thrive, but there are various features yet to be implemented that will provide decisions - we must seriously consider this while implementing new mechanics.
Furthermore, endosymbiosis is a complicated scientific process, and in game, will be a rather untraditional unlock mechanic. The mechanic itself might be easy to understand on paper, but when tasked with multiple things, we need a way to encourage the player so that they know they are engaging with the mechanic correctly.
Again, I do think that the alternative unlock conditions accommodate for players which have less experience, and I think that we have ways to affirm the player. But we cannot overlook the increase in Thrive’s complexity that is likely over the horizon.
Open to thoughts, as well as commentary on how feasible such mechanics are to implement, as well as potential alternatives.
Here’s my thoughts on what I’m going to try implement next week to get an endosymbiosis lite sufficiently implemented.
I guess this is fine but it’ll take a while for a player to notice this, so there would be a need for a tutorial at some point when there are endosymbiosis candidates. Also I’ll just put an “endosymbiosis” button at the bottom of the organelles tab in the editor.
This is going to be super complicated to implement, I’d say offhand that nearly 50% of the complexity of endosymbiosis feature would be in this one minor point. As such I’m going to skip adding this in the initial implementation. An issue can be opened to maybe at some point implement this.
This is going to be a tiny bit tricky but should be doable.
I think it should be made so that placing the endosymbiosised organelle would be free once so that the player gets the benefit of getting at least a free organelle out of it. This still keeps endosymbiosis as viable option for organelle types that are very easy to unlock or for a player who has already unlocked everything.
When initially reading your post this morning I was thinking there would be way more problems, but now that I’ve dissected and thought about it, there really isn’t that many problematic things that couldn’t be implemented like this.
Good to hear on the feasibility of the proposal. Surprised that the auto-evo handling of the endosymbiont is the most messy aspect of this, though I guess it is a pretty unique case.
I shall now unveil part 2 of this concept: editors within editors /s
First full implementation of endosymbiosis lite is now ready:
Though it has a few bugs like some GUI layout and mouse wheel stuff (and the popup window size not updating immediately to accommodate). And I haven’t checked if it works correctly with the unlocks yet.
Other than those few rough edges remaining to be ironed out it should have everything, except:
I’ll open issues later for:
- Make endosymbiosis target receive a population benefit (to help it stay around while being endosymsiosised)
- Add GUI warning if an endosymbiosis candidate is not present in the current patch the player is in
Edit: this is now merged and I opened the follow up issues: