Upgrades, Unlocks, & Endosymbiosis Master Thread

Since we last posted in this thread, a lot of progress has been made on the Discord regarding the organelle upgrades discussion. It seems that an agreement is forming that many external organelles, including the (predatory) pilus, nematocysts and flagellae will only be obtainable by first evolving a some sort of short, blunt basal pilus and then upgrading it.
I see the potential of this, but we should be careful how to visually convey these upgrades. First, Nick and Deus sketched out an upgrade pop-up for various combat related pili:
unknown

Then, when the consensus moved towards having both motile and combat-related external organelles evolve from a basal pilus, Rosae sketched out this:

All in all I support this development. It tackles the problem of analysis paralysis for new players which hh alluded to earlier in this thread.
However, I believe that we shouldnā€™t put organelle icons in these upgrade windows. Thatā€™s what the organelles tab on the left is for. I propose that we reserve the pop-ups are for sliders and such things, as this makes the whole interface more orderly. The existing pop-ups of the chemoreceptor and lysosome have layed out this distinction and I propose that we stick to it:

Instead, as Nick suggested, we should follow The Saplings lead and integrate these organelle ā€œtech/perk treesā€ into the organelle tab:
ss_af9191aa6d66356b316706763df1e93e16389bac.600x338

I donā€™t like that these organ trees are centered in The Saplings editor, I believe that ours should be
flush left and should follow the established grid pattern of of our organelle icon frames. Our organelle trees should be retracted by default, so the player sees as few organelles as possible when they first enter the editor.

Sorry for this rather long and didactic post. I hope that it at least make sense. I will try to sketch this organelle tree out to assess its viability.

1 Like

I disagree with following the saplingā€™s approach. Unless we literally want to have a tech tree in the microbe stage that permanently unlocks new organelles, I think the upgrades should still be selected per organelle with the upgrade popup view.

3 Likes

Alright, I can see why you would be wary of a tech tree. I too was originally against it.

So youā€™re not worried that this could create some kind of confusion as to what consitutes a seperate organelle and what doesnā€™t? I just fear that this makes some organelles too hidden.
Anyways, I made a mock-up of what such a tree could look like in the meantime. Iā€™m not sure if I would have done it had I seen your comment, but since I already made them I might as well just post them

This is the retracted view, which is based on your ideas from earlier in this thread:

The tree would then unravel once youā€™ve placed its basal organelle:


(I just realized that the nematocyst and the flagella proper should be greyed out in this scenario, but oh wellā€¦)

Iā€™m curious to hear wether these mock-ups reinforce your aversion to a tree or wether they make you more open to the idea.

1 Like

I get the feeling people are trying to push towards the full endosymbiosis concept where we would have a ton of organelle variants that we need the player to unlock / create somehowā€¦ As I said from an implementation standpoint that is difficult. Though, this would be easier, but to me this design seems like a tech tree that tries to pretend it isnā€™t oneā€¦

I have to admit I donā€™t really like the tech tree idea for the microbe stage.

Once again I feel like the design is running away super fast from where we are in the actual implementation of things. Iā€™d much rather this discussion would wait until we get the organelle unlocking system.

I think things will look a lot clearer once we have put the existing organelles into an unlock system, which also gives the player hints as to how to unlock more things.


Also @Kasterisk just presented the best idea so far to show that organelles have upgrades. Basically we need anyway a button or a hotkey or something to open the thriveopedia page to an organelle, so that could be shown on the organelle button itself (if people want some indication on the button itself):

2022-08-23_1.png

Iā€™m not at all in favour of the full endosymbiosis concept. Iā€™m 100% on the endosymbiosis light team. The + sign behind the nucleus was simply meant to stand in for the normal eukaryotic organelles we already have.

I am neither a strong proponent of a tech tree in the microbe stage. My mock-ups were just a reaction to discussions about this Nick and Deus were having on the Gameplay Discord channel.
Whatā€™s important to me is that if certain organelles are locked behind others, I would like these dependencies to be clearly visible.

some more detailed explanations, feel free to skip

I was mainly trying to propose an alternative to Rosaes design where both flagellae and pili would be hidden withing an upgrade window. I just donā€™t like the thought of such basic organelles which have wildly different functions being thrown into the same hard-to find upgrade menu.
It all comes down to a semantic problem: What is an upgrade? To me, an upgrade is a modification of one and the same organelle. When looking at it like this, the cilia isnā€™t and shouldnā€™t be an upgrade of some pilus, but a seperate organelle, which is why I think it should remain within the organelle tab.

Iā€™m sorry if I came off as trying to advocate for new, hard to implement features. On the contrary, what I was trying to say was more along the lines of ā€œif it ainā€™t broken, donā€™t fix itā€. Right now we have a very tidy and understandable distiction between what constitutes an upgrade and what constitutes an organelle. I was simply trying to preserve that existing distinction.

1 Like

Iā€™d also say that a blatant ā€œtech treeā€ is beyond the scope of what Thriveā€™s microbe stage will essentially end up to be. I previously mentioned this, but because the microbe stage wonā€™t have an abundance of parts, there wouldnā€™t really be a point I feel.

What Nick and I discussed with some input from Maxonovien wouldnā€™t really be a very drastic change if implemented. We discussed the validity of these two ideas:

  1. Have it so that for unlocking of certain external parts, you would essentially have to spend MP on a variant for another part. For example, the flagella is generally thought to be derived from a structure like the pilus. We could reflect this by having flagella first be a ā€œvariantā€ of the pilus, and once the player spends MP on this variant, the flagella is unlocked as a permanent part in the editor.
  2. Have it so that the player has to spend MP to unlock every membrane, and have it so the membranes offered occur in a specific sequence. So the player would start off with a single membrane, and would have every other membrane option greyed out except double. Once they unlock double, they can unlock either cellulose or chitin. And once they unlock cellulose or chitin, they can unlock either calcium carbonate or silicia (not sure which of the previous options these will depend on).

If we decide to implement these, they wouldnā€™t require big changes in the UI or a full on tech tree graphic; they would just need very minimal tweaks to the existing UI.

Since that discussion and in reflection, I have grown wary of option 1 because, again, I canā€™t envision us adding too many more parts, so there really wouldnā€™t be any replayability or gameplay purpose attached to hiding a flagella behind a pilus and so on. Those are pretty much universally useful parts, so itā€™s not like the player wouldnā€™t want a flagella, and it could be adding an extra barrier to the game for little reason other than realism. But I like option 2 still because it helps prevent players from being overwhelmed by the different cell membranes they see at the beginning of the game since realistically, most players would have a specific membrane in mind and wouldnā€™t change so rapidly between the options.

3 Likes

I agree that the 1. option has too many downsides to really be worth it. And the second option sounds like a very reasonable change.
Wether this will extend to things like the nematocyst only appearing once the player has placed a pilus can be decided at a later date. For now the membranes sound like the best candidate to try out such a system.

1 Like

So, generally speaking to my knowledge, most people like the idea of my post and an upgrade system, but that it should be moved to the left panel, because a skill tree would be too complicated and unappealing? Or am I confusedā€¦

I was just making a point about what an upgrade is and what an organelle is.
I believe that organelles and their icons should stay in the organelle panel on the left.
Meanwhile, the upgrade window should be reserved for things like sliders, gradients and other modifications which donā€˜t turn one organelle i into another.

To reiterate: I donā€˜t have a strong opinion about having or not having a tree.
All Iā€˜m saying is if we have a tree, we should keep it inside the organelle panel. Having certain organelles be hidden within the upgrade pop-ups of other organelles would be functionally identical to a tree, but visually unclear.

1 Like

gotcha gotchaā€“yeah that makes sense-

I also think if we do have editor panels, they should be placed in a way that avoids hiding what youā€™re actually editing.

1 Like

Iā€™m glad to see revived interest in this topic! I suppose itā€™s high time I provide my own input on this matter, and clarify my intentions behind the original designs.

About Upgrades:

My vision of the upgrades system was never meant to be a series of progression or development. The intent of itā€™s design was to create a new and indepth layer of customization that expands the possibilities available to in-game life. Infact, the very name ā€œUpgradeā€ may be seen as misleading for my original designs, and a much better description might just be ā€œcustomizationā€. Basically; Instead of lateral enhancement, the upgrades system provides parallel adjustment to a part.


About Progression:

To this day I remain wary of introducing a fully fledged system of gradual enhancement and progression of individual parts. I fear that by doing so, we immensely steepen the learning curve with what ultimately boils down to a forcibly lengthened progression within the microbe stage. Itā€™s the difference between choosing to evolve a pilus, or committing to gradually evolving an effective enough pilus over generations.

My design philosophy for Thrive is to encourage specialization over direct enhancement. The player becomes an effective photosynthesizer not by enhancing their thylakoids to harness more sun, but by assembling their entire organism around doing so. Every change has tradeoffs, and the more they specialize the more they must abandon other abilities. Of course, Iā€™m not against deviating from this philosophy if needed.

At the very least, We should wait until after the implementation of said lateral customization before we try tacking on a system for progressive upgrades.


About unlocking:

The unlocking system as originally devised was in truth two separate features tacked into one;

Endosymbiosis
The process of unlocking new organelles by engulfing certain prey or just forcibly unlocking them at an extra cost. This was a largely imperfect proposal I devised to appease the widespread desire for implementation of endosymbiosis.

I donā€™t precisely agree with my own original designs for it anymore, as the execution feels rather contrived to no benefit. I might pursue the concept again some day.

Part Discovery
Intended more as a means of gradually submerging new players into a progressively larger sea of parts in the editor; This concept would reveal parts whenever the player would encounter a situation where they would prove viable. This would prevent new players from such mistakes as evolving thylakoids in the abyssopelagic. Think of it as how platforming games introduce new obstacles each stage one by one.

I still feel this would provide a great way to ease new players into the game by hiding an overwhelming amount of options until they are ready. Perhaps it could even be expanded into a sort of ā€œgame-wide save fileā€ where once revealed, parts would remain placable throughout all future saves. An attribute that could potentially add that replayability and discovery that you have discussed.


Input:

I think we should simply pursue upgrades as a means of broadening customization, and expand upon it at a later time if we decide that such is needed. Likewise, I feel the unlocking system should be implemented as a sort of introduction rather than a mandatory progression gate for the time being.

I would also like to say Iā€™m unsure about the idea of locking parts like flagella behind pili.

Iā€™m the one who made this particular concept by the way.

1 Like

Marvelous! That concept I can get behind btw, as the upgrades (letā€™s call them specializations or modifications from now on) to the pilus visible in your concept can still be classified as pili.
This way the classification of what encompasses an organelle is preserved. The poisonous pilus is still a pilus, as is the proboscis pilus (or whatever that other variant is supposed to be).
The flagella on the other hand is not a pilus. Thatā€˜s why it shouldnā€˜t be in the specialization window of the pilus.

2 Likes

I agree with your post wholeheartedly.

One new thing that hasnā€™t been mentioned before that I think is worth highlighting is:

As that is a pretty interesting concept, it would certainly remove some frustration that an unlock system might cause for people who want to play the game multiple times. And in fact this could improve replayability with having overreaching goals for multiple saves.

1 Like

Just a quick note that this will confuse programmers vs. other team members because Iā€™ve already written a bunch of code to back the upgrade system, so thereā€™s a lot of code already that have the word ā€œupgradeā€ in it. And renaming those variables is not possible without writing a save upgrader or breaking save compatibility so I canā€™t really recommend we rename the implementation at this point.

2 Likes

Alright, in that case we should probably stick with ā€župgradeā€œ.

2 Likes

I wanted to do some more research and thinking on this topic, but it seems like it keeps coming back up for discussion, so here are my thoughts on this currently.

Organelle Upgrades

I fully agree with Bucklyā€™s thoughts on this. I would add that even some upgrade paths that seem wholly beneficial on the surface do actually have tradeoffs. For example mitochondria have evolved over time to become more folded to increase their ATP yield per unit of glucose, but this has increases the biological materials needed to reproduce them, as such this upgrade path would increase the Nutrient Cost of your mitochondrion organelles.

Organelle Unlocks

I think that most people agree on having a progressive system of unlocks for organs in the macroscopic stages. It helps that the evolution of organs are very well documented in zoology and botany, so we have a lot of reference material to go off of.

However I think thereā€™s also a great case for what a progressive system of simpler organelles unlocking more complex organelles can add to the Microbe Stage. I totally understand the sentiment to not add such a system to the Microbe Stage, but here are my reasons why I think it would add a lot to the game:

  • Itā€™s realistic. We have lots of evidence that many organelles have evolved from other organelles. For example, pili were first evolved as projections of the cytoskeleton, and then flagella appear to have evolved from pili that became flexible so they could undulate in water. Then some of these flagella evolved into mastigonemeā€™s, a flagella that has bristles on it that actually propels the cell towards the direction its placed, and draws objects in from the other side as well.
  • It allows gating powerful organelles for later. There are many cool and powerful organelles we can one day add to Microbe, like the Suctoria, but how do we prevent the player from placing them extremely early? Well luckily thereā€™s evidence that Suctoria are a highly evolved structure that was evolved from either flagella or pseudopods.
  • Iterative evolution. It follows the theme of ā€œIterative Evolutionā€, which is a persistent theme throughout the game. Evolution happens in small steps, thatā€™s why an organism canā€™t go straight from being terrestrial to flying. The player needs to be able to survive and thrive at each step of the way as they evolve to what they want to become. First they need to survive and reproduce as a terrestrial organism, then do it again as a terrestrial organism that perhaps jumps really high, then perhaps as a simple gliding organism, and then finally they can evolve into a fully aerial organism. This puzzle of finding a path to evolve, without going extinct, towards the creature you want to become is the main gameplay loop of Thrive. This is also why we want to make the transitions between the gameā€™s stages so seamless, to show the constant iterative evolution and zooming out from a single cell to a space faring civ.
  • Reduces initial overwhelming of the player. By gating some organelles behind others, the initial list of placeable organelles becomes smaller and less overwhelming to the player. For example, look how many unique external structures we could one day add to Microbe. Many of these can be initially gated behind the pilus, and some can be gated even further back. These connections are all drawn from research I could find showing what evolved from what.

  • Adds strategy and consequences to evolution. Another big pattern in evolution we want to emulate is that evolutionary history has consequences. Creatures that specialize have a tough time going ā€œbackā€ on their evolution (at least not without consequences). A creatureā€™s future possible evolutions are highly dependent on what they evolved before. This translates well into a game because it means we want to make a game where they player may need to think in advance which ā€œdirectionā€ he wants to evolve in, and have some backups in mind if things donā€™t go as well as planned. This adds a lot of strategy to the gameplay, versus if you were just able to place every part from day one.
  • Adds an element of discovery and replayability to the gameplay. The fact that you currently need to work towards unlocking mitochondria and chloroplasts make them more rewarding when you finally get to place them in your cell. Additionally, the process of working towards unlocking them motivates players to play the game. One of the most common goals I set for myself when I do a playthrough is: ā€œOkay I will play as an iron eater and play until I unlock mitochondriaā€. Adding more organelle progression, and have some locked behind 3-4 tiers of evolution, just adds incredibly more progression and thus potential goal-setting for players. We could even make it so that you can only see the next immediate tier of unlockable organelles, so that thereā€™s also an element of discovery to evolution as well as you gradually discover new locked but potential organelles as you unlock the immediately available ones.
1 Like

I think itā€™s a good design to make organelles be unlocked incrementally. However I have slight concerns regarding how the GUI would be.

Hereā€™s my understanding on what would be the best idea so far for the GUI:

  • Only a few of the current organelles would be shown in the editor initially
  • Each category that has still locked organelles in it would have one ā€œ?ā€ organelle in it. When that is hovered over the tooltip would show some info like ā€œx things left to unlock in this categoryā€ and it would show one unlock condition the player hasnā€™t reached yet (and for unlock conditions that arenā€™t a yes or no type of thing, it would show the progress).

With that system having multiple complex unlock conditions for really important organelles isnā€™t the best because the player would take a long time to even find the unlock conditions. Though at the same time I guess that increases the feelings of progression. For subsequent playthroughs this might also be a bit of a bad design as memorizing the unlock conditions for subsequent playthroughs, where you might know the exact build you want to go for, would be a bit difficult.

2 Likes

As a note, the pilus/flagellum distinction could perhaps entirely be settled using a rigidity slider, with more rigidity granting more damage but less speed (note that less speed might mean negative speed, i.e. a malus). Not sure how this would fit with ā€œlaterā€ organelles such as Suctoria or pseudopods, however.

Also, from an evolutionary perspective, this is definitely the right approach to our whole game. Evolution is not about upgrades, but adaptation to varying pressures that may differ over time. And I feel like we should overall be wary of not conveying the idea that there are ā€œupgraded versions of some speciesā€; all are fit to their environment. All comes with tradeoffs, as you said, Nick.

Now, of course we want progression since we are doing a game, but we may want to be careful with how we go with this whole idea.

1 Like

I think so far the user only knows the word ā€œmodifyā€ from the right click menu. And the upgrade popup dialog also has the title ā€œmodify organelleā€ so as long as no text in the game is added explicitly mentioning ā€œupgradeā€, the players wonā€™t actually know that it is internally the organelle upgrade system.

The name of the system should not be thought too strong about because eventually in development you end up doing a bunch of random stuff with a system so the name of the system anyway wonā€™t fully convey what it actually does anyway. Similarly to how in the game code we have the TemplateOrganelle (not the same as OrganelleDefinition) concept which is very different from what PlacedOrganelle is. Someone who just reads those two words wonā€™t be able to tell what gameplay purpose those two have, and why they are different.

3 Likes

Yeah I think that could be a cool upgrade path for the pilus. However I think in addition to such an upgrade path, the pilus should also act as the intermediary evolution to evolving a flagellum.

From what we know scientifically, the evolutionary history behind flagella is that originally they didnā€™t exist. Then some cells began evolving internal cytoskeletons, AKA using protein fibers to arrange their parts inside their cell, and also using these same fibers to anchor to the membrane to help maintain its shape against outside pressures. We could potentially add in the Cytoskeleton as an intermediary part. Some cells then evolved to stick out some of the protein fibers from their cytoskeletons outside their membrane into the surrounding water. These were the first pili. They were used to slow down engulfment, attach to cells or surfaces, and gently beat in the water to create thrust. Since cytoskeletal fibers are rigid, these pili were initially rigid.

These pili then evolved into a wide variety of different external organelles (flagella, cilia, injectisomes, cnidocysts, etc). Flagella appear to have evolved from some of these pili evolving to become longer and more flexible, so that instead of beating back and forth like a fin, they fully undulated like the flagella animation we see now in game.

1 Like