Disclaimer I am not very deep into ongoing gameplay discussions and not on the gameplay team. As such, if this has already been discussed to death, you can gladly shout at me in the comments.
Abstract
I provide a graphic and some food for thought about the scope of Thrive stages and how they are a necessary component for managing complexity in Thrive.
Intro
Merging realism with gameplay is one thing that makes Thrive unique, and it already does really well.
In my limited excursions through the forum, I have seen how passionately people discuss science and go into incredible detail in research.
Of course, these ideas then need to be refined and brought into a form feasible for implementation.
As such, having rough guidelines on what the Thrive stage progression represents and why it is necessary is beneficial.
From what Iāve seen, Deus and the gameplay team are doing excellent work on this with posts such as this one and this one.
I want to present some thoughts on the topic with a quick and dirty graphic.
Concept
Every complex system has a limit to which it can be simulated. With life being perhaps the most complex system that exists, this of course applies to Thrive. While we aspire for realism, we thus need to define sensible limits beyond which processes are simplified for performance. Currently, the Thrive stages clearly define these limits.
While lifeās complexity rises exponentially, our gameās computational capacity stays the same. As such, the later each stage is in the evolution of life, the more it needs to be abstracted away.
I agree with Deus that a top-down design approach is the best within this constraint. After choosing a starting point, you can add detail and features until the performance threshold is reached. Then this is repeated for each consecutive stage. Alternatively, it might be possible to estimate the performance limits beforehand and refine them over time.
I think itās always good to share perspectives on how we can think about the progression and scope of Thrive. Even if others look at things differently, thereās an underlying philosophy behind how Thrive is designed that should be articulated as much as possible. The more discussion project management gets, the more we can understand this underlying focus.
I think you brought up a very good point in the top-down approach to designing various mechanics in Thrive (itās something I didnāt explicitly realize we were doing until you brought it up). It always helps to make sure systems work at the broadest and most versatile level of detail/application before we implement more detailed simulations. It makes me think of the conversation for environmental tolerances, where there is so much possibility to cover that it makes things difficult to think about specifics from time to time. That is also what some of my macroscopic posts were trying to get at; the most general lens of application.
Feel free to contribute to design discussions on the forum as you please. More voices helps bring in more consideration for every detail we put in.
This is quite different thread than what I assumed from the title. But I like the visualization graphic here. Itās pretty much exactly what Iāve had in mind: as the player progresses to the further stages we need to stop or at least greatly reduce the complexity of the earlier (lower level) simulations. Without that the game would not be able to run on any reasonable computer.
This is indeed a very interesting way to conceptualize Thrives design philosophy. I really like the idea that we create a kind of āsketchā of each stage which is as detailed as the performance threshold permits. Itās a liberating thought that at some point that performance ceiling for a stage will be reached, allowing us to go on to the next stage with the good conscience that weāve made the preceding stage as detailed and life-like as possible.
If we are inclined to day-dreaming, we may even note that that blue square which represents the max. capability of a personal computer isnāt necessarily static. Since Thrive has started as a project (a bit more than a decade ago if Iām not mistaken) the average computers performance capacity has increased a lot. This leaves us the possibility of revisiting earlier stages years down the line and adding details if this performance capacity of computer indeed continues to increaseā¦
Here lately I have admittedly begun asking myself if keeping the microbe editor in all later biological stages is truely a good idea. I suppose now is a good time to bring up the question.
Do we want to justā¦ drop the microbe editor once we reach the macroscopic stage? We would need to replace it with a different system of tissue customization, but not having to worry about specific part placement and all that jazz would hypothetically streamline the editing process at a stage where the editor would otherwise be more than doubled in complexity/depth.
As cool as it would be to design the cells of my animalās liver, it might just be a bit too much. Especially for the less science-oriented of our fans.
Iām not in favour of dropping it. Just because it is a very complex system, rivalling in complexity with the microbe stage itself, and replacing it with something else is even more work that doesnāt help in making the later stages of the game.
I think the player will be familiar enough with the cell editor that it is more familiar than any new system could be for editing tissue types.
One one hand I agree with hh on this one for. Replacing it with another interface which determines a tissue types myriads of parameters simultaneously sounds like its more work for us and less intuitive for the player. After all, the cell editor is a both a very haptic, intuitive experience as well as one that the player has already mastered by the time they reach the macroscopic stages.
On the other hand, I concede that it sound daunting data-wise that we will have to save the information about all the different organelles and their placement of all the different cell types of all the different species.
This could be remedied in a number of ways. Firstly, we could think about making osmoregulation costs for individual cells simply scale with size for macroscopic species (not necessarily linearly, but in a fixed curve which in is the same for all cells regardless of their shape). At this stage, there are already many considerations about surface vs volume, energy intake vs output etc going on on the macroscopic scale. This would permit us to store the organelles of NPC macroscopic speciesā cells only as a simple list, without having to store all the additional data about placement and rotation. I think the fact that at the moment organelles are largely āplacement-agnosticā in the sense that they work equally well regardless of where they are placed further permit us to consider this approach.
On top of that keeping the cell editor open for all of the macroscopic stages doesnāt necessarily mean that the player will always interact with it a lot. Maybe we can nudge editor gameplay to rely less and less on the cell editor as the stages progess by keeping the ceiling on how much your cell design can boost your stats fairly low. That way the player would still would interact quite a lot with the cell editor in the early 3D stages when they have to make all of their basic cell types like muscles, nerves, fat etc. But once these have been made and designated (and maybe upgraded a few times in the case of very important types such as nerves) I could see the player touching the internal information of their cell types less and less and gradually focusing all of their attention on macroscopic body plan, organ upgrades and behavior editor.
Still, I see this as a discussion where few definitive decisions have been made as of yet and where preliminary decisions can still be corrected as we go about filling in the blanks. I think we should try to go with keeping the cell editor, but if we find that it creates more problems than solutions, we should remain open to correcting our course.
I donāt think this is going to be significant. A single cell type (the cell data is saved per-type not per placed cell) is going to be just going to take up as a little less storage than a single microbe species. Considering all the other data that multicellular species is going to need to store. And the fact that each microbe existing in the game has a ton of organelle data instances in it (and even more for each cell in a cell colony), the data increase with keeping storing all the organelle positions is insignificant. Computers are really good at storing extra 10-20 kilobytes of information. In fact just today I made a decision with the C++ module side that using 1 megabyte of extra caching memory is going to be fine, and no one is going to notice.
Unless someone can show what I missed or if my math is off by more than a power of then, I donāt think this should be given any thought in the design.
I suppose, but anyone suggesting the replacement of the microbe editor with something else will need to realistically try to estimate the extra programming work in doing the separate system and maintaining it in case some organelle related properties are changed. And maybe even volunteer to do it as I donāt really want to have to deal with the complexity of trying to make 2 variant editors for basically the same thing.
Youāre right. Now that I think about it, the cell information of a macroscopic species wonāt occupy much more disk space than the cell information a players colony species or 3D species does today. Especially compared to the amount of disk space the 3D body plan and things like behavior information will occupy, it will be almost negligible.
Alas, one more reason to try keeping the cell editor into the later stages.
