I’ve updated the issues on Github to reflect the new name. All that’s left next is for some programmer to implement this (the graphics assets were done already).
Sorry for replying so late, I’ve been very busy with academia lately 
From the sciency point of view it’s perfect 
There are some other secondary processes that arise from ultimately the usage of Glucose6phosphate which includes some other hexose-n-phosphate (Gal1P Glu1P Fruc1P) so yeap the 6 is not important in anyway for the given context.
I’ll try to keep up with the other topics tho right now I don’t have as much free time as I would like 
1 Like
I thought some more about the implementation side of this and started wondering: How do you prevent glucose being turned into glucose in an endless cycle, wasting energy? I don’t think the current plan quite prevents that. Imagine being a cell that can use both iron and glucose for energy but has an empty iron storage for instance. Then the organelle would often have no option but to convert glucose into glucose.
From my understanding, the point of the new organelle is to only turn non-glucose energy sources into glucose. So how about we make Glucose Phosphatase care about how much ATP you can actually currently generate from non-glucose sources? Maybe you can calculate that ability somewhere and then scale the gluconeogenesis process based on that.
The details can probably be figured out while actually implementing the organelle, but I think taking the source of the ATP into account would help avoid wasting energy turning glucose into glucose, which could make the organelle more useful and intuitive.
I was hoping that we could avoid such a specific check there. As that kind of code would be really tied into the exact process. With my idea about just using being full on ATP to control the process, it should have been possible to make things a bit more general. I guess we’ll just have to see when concrete implementation for this is started to what the end result is and whether this more advanced way to control the gluconeogenesis process is needed.
1 Like
It’s quite funny that I blundered into this concept so clumsily. Everyone here has basically come up with the exact same solutions I did except I made my own posts (oops). I’ll add my current diagram of this whole discussion here too.
https://dev.revolutionarygamesstudio.com/api/v1/download/41895
I agree that RuBisCo is not the correct name and that G6P is a much better protein to base the prokaryotic protein-complex (or organelle as you call it) for gluconeogenesis on. I do think RuBisCo would be a cool later addition to the game if different chloroplasts like bacteriochlorophyll for infrared light are implemented and maybe some non-LAWK x-ray/gamma radiation chloroplasts as well. This would mean that CO2 could be fixed with the same organelle and only the energy-capturing organelle needs to change. In terms of playing with different energy sourcing play-styles, creating ATP to create glucose (pyruvate irl) to later create ATP as needed is the ONLY scientifically accurate way, and will still be interesting.
Iron & H2S can still be stored to create ATP, which can then be stored as glucose using RuBisCo and CO2.The iron oxidation can offer other benefits like iron-sheaths for extra protection from predation.
Another very interesting result of separating RuBisCo from the energy-harvesting organelles is the potential in introducing more nitrifying organelles, which reflect nitrifying bacteria irl which are also chemolithotrophs/chemoautotrophs.
heterotrophy vs autotrophy.pdf (109.7 KB)
edit: upon further thought, I think RuBisCo and the calvin cycle make more sense to implement first. Gluconeogenesis essentially takes place already in the game when you digest other bacteria. It would be necessary only when a bacteria is a photoheterotroph/chemoheterotroph, producing excess ATP in the absence of CO2. After all, to generate glucose you need a carbon source. You cannot produce glucose from just ATP. You need ATP + carbohydrate → glucose
In fact, if I’m reading this chain right, then there seems to be ALOT of confusion between the calvin cycle and gluconeogenesis. What Leinourdian describes here is in fact how the calvin cycle operates in the presence of CO2. In the absence of CO2 and in the presence of some other carbohydrate source, this would be gluconeogenesis. There are two processes here that take carbon from essentially two different sources and use ATP to convert this carbon into glucose which is then stored to create ATP later.
Calvin cycle: ATP + CO2 → glucose
Gluconeogenesis: ATP + carbohydrate → glucose
gluconeogenesis vs calvin cycle.pdf (103.3 KB)
This is why gluconeogenesis makes more sense when more complex carbohydrates are a usable form of energy storage.
It seems like you want both of these processes in one new organelle. Instead I propose either:
-
making G6P first, generating excess ATP → glucose, but later requiring a different carbohydrate for this process or,
-
make RuBisCo first, generating excess ATP → glucose, but later requiring CO2 for this process.
Even later than that, the carbon-fixation should be removed from thylakoids as the calvin cycle takes place in the stroma of chloroplasts (eukaryotes) and in the cytoplasm (inside carboxysomes) of bacteria. Thylakoids would then reflect the more accurate representation of simple light-capture in bacteria, ie; light → ATP. I would also remove the metabolosome’s ability to digest bacterial parts, making it only able to metabolise glucose.
If y’all absolutely need to condense both processes into one, single organelle, call it something else like a carboxysome, glucosome, carbohydratase (this would actually be a perfect name for a gluconeogenesis organelle) and again strip the thylakoid’s ability to generate glucose, and the metabolosome’s ability to digest other bacterial parts. the metabolosome would then be solely able to metabolise glucose, and the thylakoid would only be able to generate ATP.
Super simplified glucose-generating organelle system.pdf (92.1 KB)
1 Like
As much as it makes biological sense, I don’t think dealing with different types of carbohydrates is the right direction for thrive. It’s additional complexity for little gain on the gameplay side.
Now feel free to point out if I say anything wrong here (as I don’t know a ton about the minutia of bio-chem), but this is building off what you just suggested.
-
Complexity-wise, the Calvin cycle (ATP + CO2 → glucose) seems to make much more gameplay sense, so implementing RuBisCo or whatever we want to call it seems to be the best first step.
-
Thylakoids directly making ATP seems to make sense (from a quick glance at Wikipedia) and might be an improvement to early gameplay. Might pose a balancing issue though
-
As far as the metabolosome goes I’m not entirely sure it does that, and even if it does, if removing that from it is a good idea.
3 Likes
Yep, you are correct, I think RuBisCO makes the most sense. It’s really important to specifiy the difference between the Calvin-cycle and gluconeogenesis.
I might just be confused about the metabolosome tbh. There are no obvious organelles used for digestion.
I also realized I said this part in a weird and confusing way…
Here, I mean implement the parts in this order, not that the organelles should work like this in the finished game.
The gameplay design reason we are trying to add an organelle to generate glucose from ATP is that we need some kind of longer form storage. Reworking entirely how the CO2 inside cells is handled is a much bigger problem.
We can already just add CO2 as the environmental process input. As CO2 doesn’t currently change in the game the effect is the same as it not being a meaningful requirement.
At this point I can’t fully remember why RuBisCo was entirely thrown out as an option before. If I remember right it was something to do with RuBisCo already being implied in another organelle. But I think my opinion even then was that we could add it as a separate organelle by just saying that it is an extra amount of RuBisCo.
I agree here. We shouldn’t add a bunch of intermediate products that do nothing else except for the player to place like 3 organelles in specific order to get any use out of them.
I agree. This seems like a good idea.
This should be a separate discussion that doesn’t prevent RuBisCo implementation from going forward.
For digestion there is the Lysosome which increases digestion efficiency or allows digesting different membranes. Removing the ability to digest prey from the base microbe would be a pretty big change, and likely needs a very explicit tutorial or removing the engulf ability from the base cell (but then simple iron eaters wouldn’t be viable). Touching core parts of the game causes knock on effects on many other parts of the game.
1 Like
This is something I also agree on with the game in its current state. This would make a lot more sense further down the line if fermentation and other anaerobic processes were explored for example.
2 Likes
It was implied by the way we have thylakoids make glucose. If they were swapped from making glucose to directly making ATP it sidesteps the issue regardless of anyone’s opinion on it. It was also implied by Chloroplast, but by the time we are using real organelles I can accept that they have RuBisCo inside them anyway.
2 Likes
Chloroplasts do have rubisco in their stroma, so this is the correct implementation. The entire RuBisCo discussion is more important for prokaryotes. It would also fix the rustycyanine and chemoplast energy-storage issue, storing this ATP as glucose. This is what I think everyone had in mind in this thread.
Here is an updated diagram of the current carbon metabolism in the game + RuBisCO for prokaryotes.
thrive now + RuBisCO.pdf (87.4 KB)
I suggest that a basic RuBisCo implementation is done first, then the other metabolism changes can be discussed further. This way @Gamedungeon can get started on adding a new organelle to improve the game’s energy storage gameplay.
3 Likes
Having caught up in reading all of this. I’ll firmly say that we should stay true with simplified chemistry. New compounds should be regarded as a most extreme addition as each individual addition adds significant bloat in game complexity, visual discernability, learning curve, and more in a great many ways.
By compressing and simplifying the chemical processes of Thrive, we make gameplay far more palatable and understandable for players new and old alike. This makes for a perfect gateway for those inclined to learn more about these chemical processes they are being introduced to, without making the game look like a research paper the likes of which any layman would never willingly read.
(I will add that with the new resources afforded to us thanks to the recent Thriveopedia changes, we can even elaborate on how things really work in reality in our theory section of the organelle pages for those so inclined!)
For this feature we are discussing, I wholeheartedly agree with hh that any further speculation on how we should approach metabolism going forward shall wait until the basics are implemented. This spares us from the hypothesis of what we might want, and allows us to leap straight into the theory of how it feels to play.
Once we do get a feel for it, new compounds, or any other significant leaps in complexity should be the last option if all else fails.
3 Likes
Question, why not just call RuBisCo, a Carboxysome, It’s funny because the bacterial microcompartment discussion actually includes RuBisCo Carboxysome - Wikipedia
Carboxysomes are BMC’s (Like Metabolosomes) but they primarily just hold RuBisCo enzymes inside them,
The carbonic anhydrase which is also in them, just makes RuBisCo’s job slightly easier by concentrating carbon.
In fact, you could set it up so Carboxysomes, can be upgraded from pure RuBisCo which woudl simply make it more efficient
1 Like
Carboxysomes are somewhat analogs to C4 metabolism (just in case anyone is familiar with that concept). The RuBisCo, doesn’t matter where, suffers inhibition from oxygen, thus when there is too much oxygen it does not generate glucose properly, therefore some organisms evolved the ability to store RuBisCo into sites where O2 has a more difficult access than CO2. So a Carboxysome is not exactly the same thing as a RuBisCo.
If adding Carboxysomes then it is implied that there is RuBisCo’s inhibition from excess oxygen. Thus there should be implemented a parameter of oxygen saturation in all organelles using RuBisCo.
Which I believe could be pretty interesting actually, but naming RuBisCo as Carboxysome I don’t think would be very accurate. However creating a novel-fictitious organelle having a bunch of RuBisCo is not a bad idea, again Thrive is about accurate speculative evolution, right?
Yes, sure. I know it has been discussed, not to add more carbohydrates and to keep the chemistry simple, though I think at some point coenzymes will be important.
When this problem came out I simply thought about a cell not being able of getting rid of the glycolysis products (yet not suffering any consequence), thus having carbohydrates (since there is no need to perform fermentation since NADH does not exist) to perform gluconeogenesis. So, as coenzyme do not exist, I didn’t think that not having explicitly carbohydrates to perform gluconeogenesis was a problem.
Thylakoids as a simplified version of a completely photosynthetic capable organism is not that bad. Also for implementing an organelle able to convert light → ATP I believe that bacterio rhodopsin would be a very good candidate, as is both simpler and more efficient than Thylakoids (when thinking only about ATP).
This was already discussed here:
I discussed this a bit on Discord, but I have some concerns about the implementation of RuBisCo and the Calvin Cycle as an individual part - both for gameplay purposes and on a meta level.
On a meta level - representing the Calvin Cycle via an organelle is an awkward step up in complexity that is not consistent with other implemented parts. The Calvin Cycle is inherently a part of photosynthesis - which is already a process represented by thylakoids and chloroplasts. It’s awkward to imply a separation between photosynthesis and the Calvin Cycle theoretically, for multiple reasons…
- The Calvin cycle does not make much sense independent of the light dependent components of photosynthesis which occur in photo systems
- Wider implications on the splitting of other systems. Do we, for example, make also make a part dedicated to the Krebs cycle as a way for the player to tweak their metabolic processing rate?
I think a lot of that is a symptom/result of the mentioned meta-theoretical issues - we imply the Calvin cycle is a universally beneficial and independent process when in reality it is specially catered towards photoautotrophic processes. In other words, we are offering a useful part in a way that is too broad for the player to really know when to use that part because of the implied separation between photosynthesis and the Calvin Cycle. Ensuring that extra ATP is not wasted is a very specific adaptation and a balancing act for photoautotrophs, but is less incentivized - or atleast, less manageable - for organisms who depend on movement heavily, such as heterotrophs.
I want to playtest some more, but my experience with the RuBisCo part so far is similar to previous comments on it - it sounds good in theory, but in practice, I’m not really sure what benefit there is in most cases and it feels a bit awkward.
I ultimately think this should be a function attached to either an upgrade or the larger metabolic process panel concept rather than as an individual part. There are conceptual difficulties which players will likely regardless dealing with this process as an individual part - for example, I don’t know how a player will accurately gauge how many parts their build would require, or the effects of adding another RuBisCo.
I disagree. The debate took a long time, and happened multiple times. I’m now perfectly happy with an organelle representing a cell doing “more” of some process. If we had switched to a protein slot system, this would be a moot point, but now we need to represent that additional cell capability with some organelle. What that is doesn’t really matter as it is realistic enough to be able to make sense. Representing the calvin cycle as an extra thing fits the bill perfectly for that use case.
I just don’t see this working as an individual organelle. Even the current implementation seems to have a feeling of awkwardness about it; I don’t think it’s really a matter of balancing either, but a question of implementation/design.
In Thrive, ATP almost always represents the cumulative end product of a player’s entire design - gather/generate enough glucose/iron/hydrogen sulfide/etc. to eventually get ATP. I think that to then add another part that completely uproots that is something that the player should assess holistically rather than just through the perspective of placing an individual part, but rather as a system entirely. Of course, RuBisCo isn’t meant to be a necessary part anyways - but such a hunk in the system I’m will probably make players feel hesitant in using it.
Considering the above, representing a non-independent process in an individual part also isn’t just confusing theoretically, it also makes it awkward for the player to deal with. Placing more thylakoids/chloroplasts represents using more sunlight, placing more mitochondria represents transforming more glucose into ATP, etc.; our currently implemented independent processes make intuitive sense.
But when you represent such a dependent process with a part instead of a function/process in itself, what exactly does adding more of said part imply? A faster Calvin Cycle? More of that process? Independent of photosynthesis or other metabolic processes, what does that really mean? Especially since ATP is not a tangible or stored product easy to measure but is instead an output, that sounds like a measuring headache for players to deal with. I just don’t see any player realistically placing down such a part as is, as they’d feel it’s not useful as an independent organelle or have no idea on how to utilize it well.
It would be easier to maintain via controls that imply process fine-tuning rather than adding an individual part and adding lump sum effects on your metabolism. If this is to be implemented, why not just focus on controls related to the process panel concept first? Why not bound that within the process panel? We have plans for that anyways eventually, entirely separate from the prior passive enzyme system. I don’t think players will know how to manage RuBisCo, even entirely ignoring it even if it might be useful, outside that context.
2 Likes