Managing Complexity and Defining Scope

Thinking about Complexity in Thrive

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.


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.


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.


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.



Maybe this can be a useful way to outline the scope of stages and focus theoretical discussions. I’m happy to hear your thoughts.


Appreciate the shoutout to the game design team!

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.

1 Like

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…

Anyways, thanks for the interesting input:)

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.

1 Like

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.

1 Like

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.

1 Like

Alright well that’s reassuring to hear. Stay the course it is.

1 Like