Multicellular Stage: The Beginning

We don’t have code for an organelle just consuming ATP like that. If this is wanted (again, this is just something on top of the normal functionality of the organelle), it needs special handling in a cell to subtract ATP.

How would this be calculated? Currently absorption rate is a maximum percentage (per second) to take compound that is in a cloud.
Basically limiting the compound transfer speed to that value, would be very marginal, unless you had huge ATP demand and fast processes to generate it, then this could be a problem, in all other cases I don’t see this having any effect other than requiring a bit of extra time to program it in.
Well, maybe it animates the compound amount bars in a nicer way, if those are kept showing your amounts. But I was thinking that the compound bars for the player should just show the total storage and total compounds in all colony members.

I put this in the related github issue (Binding agents · Issue #1712 · Revolutionary-Games/Thrive · GitHub).
How I imagined it to work is to have a separate key (perhaps ‘U’) and pressing that unbinds your cell from all other colony members, so you can ditch them if you want for speed or something to keep you from dying.

I don’t think we need a limit. Binding to something needs anyway for your collision box to hit it. If you are roughly circular you could in an optimal case have only like 9 cells bound to you.

I think it’s fine to leave as is, we’ll want to have a hard limit on the number of alive AI cells anyway.

I think that kind of limit is a bit low. I imagined that something like 20 cells bound together is a prerequisite for becoming multicellular. Also if there is a limit of 40 cells before moving to a tissue editor, I think that’s a bit low. I think that maybe something like 50 cells is a good limit when you can go to the tissue editor and become macroscopic, the limit for staying in the cell stage, should be a few times higher than that. Maybe we can get away with max colony size of a little over a hundred (in this case there probably couldn’t be that many colonies on screen at once, but this is only a concern once the AI knows how to form colonies)
I don’t foresee colonies (of course this depends on how they are formed, fusing into a single physics body or using physics constraints, which might spazz out) taking more performance than the equivalent number of cells not in colonies. It’s probably less laggy as the AI doesn’t need to run as much, though the AI is quite cheap currently.

1 Like

Yeah sounds nice :slight_smile:

Can I ask about like controls? So say I bind with a few other cells, do I have control over them, can I turn and move the colony as I like? Can I fire their agents and do any other active things?

Another thing is about damage. So say I make a colony of 5 and then one of the cells dies in combat, is that a problem or can I just carry on? Does it matter if it’s my original cell, if that dies is it game over even though the rest of the colony is ok?

Sounds like good progress on the concept.

1 Like
2 Likes

My assumption was that it would work just like the bio_processes code but without a product.

    "oxytoxySynthesis": {
        "name": "Oxytoxy Synthesis",
        "inputs": {
            "oxygen": 1,
            "atp": 5
        },
        "outputs": {
            "oxytoxy": 1.5
        }

From my understanding this subtracts ATP like I intend. I assume there is something else at work that prevents us from doing that?

Hmm interesting. Before now I never really considered if the player should become the colony or not. I think thoroughly expanding player control to the whole colony might be favorable as it would be much simpler without having to worry about complicated mechanics that would arise otherwise.
That does make me wonder how health will be managed though… I’ll have to spend some time contemplating it.
That being said, you raise a good point about the absorption speed, I was thinking a calculation as simple as dividing player absorption by 2 but that would probably not be as simple as what is in my head. I suppose it wouldn’t be too necessary anyway.

That’s fine for me. I would still like to avoid using two different keys for binding agents but it shouldn’t be a problem.

Excellent questions, and with no easy answers.
My initial thinking was that the player would assume control of the colony’s thinking, but would otherwise remain an individual when it comes to health and resources.
However, after reading hh’s post, I think it might be favorable for the player to truely become the colony as a whole. That is, their UI would now display the stats of the colony rather than their original cell.

Health is a complicated issue. Having the entire colony have a single health pool would be rather bland, and wouldn’t really reflect well on the fact that it is a colony and not one creature. However, each cell retaining individual health values could introduce it’s own issues and complexities.
I believe it would be ideal if each cell retained it’s own health and could die separately from the colony. Displaying the health to the player might be complicated, we might have to add up all health between all cells and display that to the player, while the cells themselves each retain their normal values, would that be too complicated?
Finally, my idea here is that the player is no longer a single cell but the colony itself. The “original cell” ceases to be the player. Should all but one cell die, the player will assume control of that cell, as it is still the “colony”. The problem here is that it might be complicated to choose which cell becomes the player when the colony is disbanded by choice.

I hope that this isn’t too needlessly complex. The more I think about it the more I realize that this is a really sizable feature no matter how we handle it.

Something I want to point out is that this feature could be described as a “game-defining” feature. It’s something that a designer would often build their entire game around, as it is a relatively complex gimmick that would likely serve as the selling point of the game. It really brings to mind the enormity of our project, and how what would normally serve to make a game stand out, is just one of many features of this monster we call Thrive. People would rightfully think that this is insane, but Thrive’s very existence as an ongoing project is statistically improbable to begin with. The very impossibility of this project is what made me fall in love with it so quickly. It’s very exciting, and part of why I intend to focus on learning a bit about programming myself whenever I find time so I can help with the real heavy lifting of this project.

3 Likes

Processes must have outputs, in theory it could be changed that processes with no outputs are allowed. But the reason they are not allowed is that it is weird to have a process that just makes stuff disappear.

If we make up an output for it, the cell will eventually become full of it, so the process will stop. Like oxytoxy synthesis will stop once the cell is full up on toxins.

This is the direction I’m leaning towards, as long as the physics shape index stuff doesn’t turn out too problematic. If it turns out problematic then it’s not possible to tell which part of the colony took damage and we’ll just have to have one single health bar for the entire colony. There’s an open issue in Godot repo about it, but seems a fix hasn’t been finished yet:

From code perspective it is easier to keep so that the original Microbe object the player controls is the colony leader, and also the cell the player controls after disbanding.
Also it’s probably also easier to just make it so that if the colony lead cell (in the player’s case, their original cell) dies, the colony is disbanded and it acts just like if the player had died.
This gives some benefit to forming a circular colony around your original cell to protect it from damage (assuming of course we are able to keep individual health for each cell in a colony).

2 Likes

I’ve started implementing the binding agents and still have a few questions:
How should the binding feature work in detail? Do the membranes have to touch, or do the binding agent and the other membrane have to touch?
Should all reccources be shared between all cells or should one cell transfer reccources over time to a neighbour if it has less?
How should the logic to decide who is the colony leader look like? If there is a player involved, the player should be colony leader, but if there isn’t a leader? What happens if one member of colony 1 binds to another member of colony 2? Who should be the colony leader then?

I wrote a bunch of technical details here:

I’ll make another post there adding some details.

Should every membrane type be able to bind?

If some membrane type couldn’t bind, it would make it quite an useless choice, as the player would need to pick another membrane type to advance in the game.

1 Like

Over the last days I have been sporadically working on a simple concept of how the very early multicellular editor might look. Since my concept shows the multicellular editor before the dimensional shift, I figured this would probably be the appropriate place to post it instead of in the „The Aware Stage and Mechanics“ Editor thread.

As there are up to 3 year old posts in this thread, my concept might not be 100% in sync with all of the ideas layed out above. But it seems to be largely congruent with the draft @Buckly recently posted in the „Cell Specialisation and the Dimensional Shift“ Thread.
I also included the copy and edit buttons posted by @Narotiza in the Aware Editor thread.
The icons for the cells on the left might be a bit large. Maybe there should be three in one row to make things more compact? I‘d apprechiate feedback about that specifically and about everything else in general.

6 Likes

Putting three in a row might help with organization at the multi-cell stage in my opinion. That way with specialization cells and basic cells the player might more quickly or easily be able to create a multi-cell creation more freely and be able to create future/further cell specialization. This could then in turn influence or aid in future mechanics further into multi-cell life.

I think we need to think some on what kind of creation abilities we are going to allow the player to have when they pass a certain variation of cells (3,5,8,etc) in this stage of evolution for their creature to introduce some more complexity to the game in terms of difficulty. Thoughts?

Overall I do like the UI and the editor design and feel we can keep it into later stages of the game until we possibly branch fully into a 3d editor if we are still taking that route.

1 Like

It’s been some time now since I’ve last discussed the multicellular editor and it’s workings, and I apologize for my late continuation. To help out those who may be a bit behind, I’m going to write a recap below to explain the overall idea we seem to have settled on, before I present my ideas.

Multicell Editor Recap

The multicellular editor is going to be accessed immediately after the player evolves from a bound colony of 8 or so cells via either the normal evolve button or a new separate one used to represent a transition.

Once within the multicell editor, the player will be presented with a single starting cell, and a “parts” list from which new cells can be selected and placed. The player may now place cells adjacent to the original to assemble their multicellular organism.

An additional feature is the presence of a specialization editor, where players can edit their cell type to create new specialized variants of their cell. This editor behaves identically to the original cell editor, except that it is accessed temporarily through the multicell editor by clicking the associated buttons located on the cell selection.

Once the player has assembled their organism, they are now ready to proceed into the brave new world of multicellular life, and with that, you are now caught up!

As it is currently planned, Thrive is going to feature a transitional 2D or 2.5D stage between microbial and multicellular proper. My intent is to discuss our options of how to proceed with the design of the early multicell editor, and hopefully address some of the logistical problems we face.

Cell Placement
An important thing to consider is how we intend to handle cell placement, as placing cells will be a bit different than placing individual cell parts.
I present two options:

  1. Hex grid
    By continuing to use the hex grid, we can effectively reuse a large amount of code and features that we already have. Since cells are already made of hexes, placement will be identical to the microbe editor, but with bigger parts and maybe a couple more placement rules.
    However, this system restricts part placement to limited angles, which might be somewhat unappealing. (Refer to MirrorMonkey’s concept for an example.

  2. Free placement
    By removing the hexgrid, we can grant players a far greater degree of flexibility for part placement and organism customization at the cost of much more development work.

Players would be able to rotate and flip their cells at any angle, as well as potentially even resize their cells if we so chose to include such a feature.
However; free placement would require lots of work to implement for something that is only intended to be transitional.

After some consideration, I feel that sticking with the hex grid might be our most realistic option, as much as I would love free placement.

Cell Specialization
The creation of new cell variants is arguably the most important part of multicellular, and so we need to carefully consider how the player accesses the editor window for individual cell types, as well as how we shall handle cost of mutation, and updating already present cells with new layouts.

It has been established that clicking the edit buttons placed near or on the cell icons will grant access to the cell editor. But how the editor window will reveal itself is a matter that we have not yet considered in depth. Below are two different concepts on how the window might change.


This concept effectively replaces the entire editor with the unicellular equivalent for the selected cell type. It is also functionally identical save for the preview window used to view the entire organism for reference purposes.


In this (admittedly messy) concept, the part selection window is expanded into a miniature portal within which the cell editor is displayed. This concept would allow for smoother transition between editing parts, without changing scenes entirely.

In addition to editor windows, we must also carefully consider how changes should be applied to presently placed cells in the event that the player edits them without creating a new variant. The problem posed by this situation is that when cells are edited, their size may change which will undoubtedly create positioning issues within the organism. Note that this problem is specific to the transitional stage, and won’t be applicable to the 3D editor. Below are a few options that I have considered to remedy this problem.

  1. The previously placed cells must be manually updated by the player, requiring them to reposition surrounding cells.
    Nothing necessarily appealing to this option other than the lack of programming involved.

  2. Cells are resized or otherwise don’t change size/shape but still effectively inherit changes made to them in order to fit.
    Instead of cells having unique shapes in multicell, we could potentially get away with them all being generic save for some visual changes and external organelle placement. That or we automatically resize cells to fit, but that would not work well with the hex grid.

  3. Surrounding cells are automatically pushed/repositioned to make room for edited cell types.
    This is probably a nightmare to program without creating all sorts of bugs and issues, as well as potentially alter the organism’s shape in unwanted ways.

I don’t know if there is any perfect solution to this, I would greatly appreciate input from our programmers about how this might be solved.

Finally; We need to decide on how we want to handle the cost of editing cell types in the organism, this is very important as it sets the pace of player mutation and customization in the game. The expanded depth of customization brings some added difficulty to this endeavor, as more things to change in the organism means slower evolution per generation. Below are some proposed methods for handling this.

  1. Per-Cell MP Pools
    By granting each cell type their own MP pool, we can allow the player to make small changes throughout the cells of their organism without having to focus on any particular one. This could be balanced by altering the cost of individual cell parts, or by decreasing the amount of MP granted to each cell so less can be changed in each cell at once.

  2. Divided MP Pools
    By having two separate MP pools for cell specialization, and cell placement, we can allow players to tweak one or two of their cell types without sacrificing options for placing new cells on their bodies.

  3. Dynamic MP Exchange
    A bit of an unusual take that is difficult to explain, but by granting each cell their own MP pool, and then an overall MP pool for all changes, we can allow the player to make limited changes to many of their cell types at the cost of spending some MP they could use to place new cells.
    (Ex: The player spends 90 MP to place 2 mitochondria in a cell, which then deducts 45 MP from their overall MP pool, leaving them with enough MP to make the same change to one other cell).

  4. Standard MP Pool
    All changes cost MP from the same pool, preventing the player from making very many changes to their organism at once.

Personally, I would prefer some variation of 3, but perhaps there are better solutions out there.

Dimensional Transition
Another highly important aspect is how we intend to translate the player’s 2D organism to 3D. My only idea so far is that we essentially utilize something akin to @Nunz’ 3D membrane generation methods to similarly generate a solid body from the player’s component cells.

The resulting body would act as the torso section for the fully fledged 3D editor, upon which the player would begin to place limbs and other parts. I would like to hear what everyone has to say about this, as well as Nunz’ own opinion on the plausibility of this method.

I hope that by bringing up these issues and their potential solutions, that I can promote fruitful discussion through which we may decide on our course of action. Once we have decided, we will be largely free to move on to charting out early multicellular gameplay mechanics.

Let me know what you think!

Edit: I forgot to bring up placement rules for external cell parts. Obviously, placing cells where external parts collide with or clip through other cells and their parts is bad, and should be avoided. So we should consider options on how to prevent this from happening.
If we go with the hex based, I suppose we should make the external organelle hexes check for adjacent hexes and prevent them from being placed if the check is triggered. With free placement, we would need for them to have some manner of collision check.

2 Likes

Great overall summary of our current ideas about the early multicellular editor!
I have a crucial question regarding the dimensional transition: In the concept art of the multicellular editor you posted, the organism consists of only six cells when the transition to 3D happens. Is this on purpose?
This question is also adressed to the creator of this concept art (I assume it’s @Narotiza since he made most of the interface concept art).
In my understanding the transition would be easier to implement and make more sense from the players point of view if it happened once the players organism reached a scale which feels noticably different from the scale he was playing in as a single cell.
If the transition happened at around the size this concept art seemingly proposes, the single-celled organisms around the players organism would still be visible in all their detail, with all their organelles being discernable. If the transition happened at a size of for example 25+ cells, the unicellular organisms could be represented as simple semi-translucent sprites or maybe as extremely simplified 3D models without all their organelles being visible.
The transition happening at a size of 25 or more cells would

  1. save a lot of computing power, as in a 3D environment with the same density of microbes and the same rendering distance a lot more microbes would have to be rendered.
  2. negate the need to rework the current membranes to be visible from all sides. As far as I have in mind atm the membranes only look right if you view them from above.
  3. make intuitive sense from the players perspective. Why would you be able the see the same cells you saw before with the same amount of details, but now in 3D rather than in 2D? If the player is gradually introduced to a new sense of scale the intruduction of 3D makes sense to him when he looks back at how the world now looks different from his organisms point of view when compared to the view it had when it was a tiny microbe.
1 Like

It’s just intended to demonstrate how the game might trace the overall shape of the player’s organism to generate the torso, the cell count is simply the same because I was too lazy to make a different organism.

The art is not indicative of the requirements to reach late multicell.

Nah I made it, I can understand the confusion, but Naro’s would probably be much better quality. (I mostly make my concept art by haphazardly assembling and editing screenshots from the actual game.)

I’ve been thinking about something similar, with the organism’s individual cells gradually becoming less individually discernible via shader or something else as they progress. I am not aware of the specific feasibility however so I would very much like some input from our programmers on the matter.

1 Like

That adds complexity to the game.

I think something like 20-25 cells should be the limit when you unlock a button to become macroscopic. When you do each cell is converted to a metaball of tissue of that cell’s type and your entire species is basically scaled up to represent that each cell has now turned into like billions of cells and you are a big creature now.

I went ahead and created some polls for quick feedback since not everyone is willing to try and discuss the post in full detail on the spot. I hope this helps.

Which placement method should we pursue?

  • Hex Grid
  • Free Placement
  • Other

0 voters

How should we handle updating edited cells that have already been placed?

  • 1: Manually update and relocate each cell
  • 2: Resize cells to fit
  • 3: Push away surrounding Cells
  • Other

0 voters

Which method of MP cost should we implement?

  • 1: Per-Cell MP Pools
  • 2: Divided MP Pools
  • 3: Dynamic MP Exchange
  • 4: Standard MP Pool
  • Other

0 voters

I like how this approach radically simplifies everything by not having to deal with everything in between “each cell is placed individually” and "tissue is so macroscopic that you can’t see individual cells at all.
But if each cell is suddenly replaced by billions of cells of their kind, we’re talking about a drastic jump in scale.
The jump from 2D to 3D will already drastically change the ratio between surface and volume of the organism. This could confront a lot of organisms with sudden problems, especially photosynthesizers. If I’m not mistaken (and I very well may be), scaling up the body plan of an organism by a factor of 1000 or more (as you seem to be suggesting) can give rise to similar problems. If we go this route of suddenly scaling up the organism like this, we’ll have to stay aware of such problems.

I think the approach of scaling up each cell to be a ton of cells at once is the best of the options we have. I think we will hit a performance issue with more than a few hundred cells existing at once. Meaning that it is simply impossible to let colonies get into thousands of cells and having multiple of those on screen. The only doable thing I can think of is to just make the jump from less than a 50 cells to a macroscopic organism where we can stop rendering individual cells.

1 Like

Only way this 100-1000 cells stage could work is if we simplify the Microbe class( or create a cell class) and have one shape per microbe. Just my 2 cents.

1 Like

I’m also thinking that rendering the individual organelle models is a pretty expensive operation (I think there must be some kind of frustrum culling or instancing option in Godot we aren’t using that would improve the current performance with many cells as a lot of players have low FPS problems).