Multicellular Stage "non-cellular" parts

I’ve mentioned this topic a few times, including on the Multicellular roadmap planning thread, but I figured I should make a more systematic overview of the different options.


Background:

Lots of animals (complex but also simple ones) have large chunks of the body that are not really made up of cells. Cnidaria (yellyfish, corals, etc.) have Mesoglea, a gel-like skeleton that takes up much more space than the actual cells of the animals. Sponges have Mesohyl, which is very similar. Then you have things like shells, bones, the stony structure of corals, etc. There are also things better described as “cavities” like the coelom seen in most bilaterals (basically just body cavities in general), but also the digestive system (including “blind” guts).

Technically these kinds of topics could be left to macroscopic (where they would really become necessary). But I think there is value in adding them already in the Multicellular. For one thing, being motile on the Macroscopic scale on earth happened with animals that already had internal body cavities. Which would suggest we either already try to simulate the origin of those in Multicellular, or all life starts as pretty sessile in Macroscopic.

There are quite a few different ways these real-life features could be simulated. But to first make some more general points:

  • Some of the functions I have listed (like “external shell”) can currently be approximated by giving different cell types different membrane types. From a gameplay perspective, this works fairly well. But from a scientific perspective, it is very odd, as pretty much every life form we know of has a uniform membrane/wall type across the whole organism, with some just having additions/modifications or simply things “in between” the cells. Which is why I suggested in the roadmap thread to lock membrane types in Multicellular and instead use one of the other systems proposed here.
  • The systems I propose have overlaps in functionality. So the idea is to pick just one or two to implement.
  • Many of these proposals would benefit from a better extracellular matrix system, to essentially bind all the cells together and fill in the gaps between them. In fact, many of the things I suggested are a form of “ECM”. But such a system is out of scope for this post, and in any case from what I understand the main limiting factor here is the requirement of a graphics programming expert on the team.

And now for the different proposals:

Membrane type variants

I only just suggested removing varying membrane types and here I go suggesting to put them back in again!

But this is slightly different: instead of fundamentally different membrane types, these represent smaller adaptations and modifications to them. When entering the Multicellular Stage, the membrane type selection would be replaced by a different set of options depending on which membrane type you had at the end of the Microbe Stage. Examples of where this fits well:

  • Lignified cellulose cell walls.
  • Calcified cellulose cell walls.
  • Melanised chitin cell walls.
  • Normal/double membranes that can’t engulf (like the vast majority of animal cells), in exchange for for example reduced osmoregulation cost.

Probably less accurately, we could also use these for more explicitly “extracellular” components like bone tissue or the arthropod-style cuticle. But in this case I would suggest we at least make the “membrane” of these cells expand much further than it normally would, so that it really fills a lot of space beyond the cell’s own parts.

Non-cell Hex Parts

These would be listed separately from cell types in the main editor screen when available. They would be placed on a hex in the same way as a cell. They can only fulfil very limited functions, but because they’re not living cells they don’t cost much upkeep. Functions could be low upkeep storage, a tough outer shell, a place to farm bacteria, a stomach or gut, etc.

Availability would depend on the cell types in your organism. For example, the binding agent would unlock “glob of extracellular matrix” (meaning this is always available in any Multicellular organism from the start) and the slime jet/mucocyst could unlock a permanent slime layer. This system could even be implemented so that you can only place these non-cell parts next to a cell that can produce them. I think that would be a fairly interesting mechanic for players, but am not sure if this would be too much work to implement.

“Area-of-Effect” cell parts

Like above, but instead of being a hex without any cell in it at all, these would be parts in a cell that make the cell “project” an area around it where the extra-cellular material is placed. The most direct visual comparison to something in-game would be how mucosysts project a slime barrier around them.

“Background” cells

This could be considered a kind of expansion to the above. Instead of only having material or effects projected around the cell, the cell itself is placed in the background, with the effect or material also applied “above” the cell. In a 2.5D style, we would disable collision with everything except terrain chunks on these cells, making them work as “stomachs”, where things can really look like they are “inside” your multicellular organism.

Obviously works the best for cavities, but would be a bit more odd for anything placed above it that is opaque.


As said before, implementing all of these mechanics is not the objective here, so here I provide a table to compare how well these different options cover real-life use cases:
:check_mark:: Definitely works
X: Does not really work
—: Can work, but probably a bit odd.

Attributes: Cell Membrane Variants Non-cell hexes “Area of Effect” cell parts Background cells
HH’s estimated implementation weeks 2 3 2
Body cavity X :check_mark: :check_mark:
Stomach/gut X :check_mark: :check_mark:
Mesohyl/Mesoglea :check_mark: :check_mark: :check_mark:
External shell :check_mark: :check_mark:/—
Cuticle :check_mark: :check_mark:
Bone :check_mark: :check_mark:
Slime layer :check_mark:
Fungi’s external digestion —? :check_mark: X
Wood :check_mark: X :check_mark: X
Calcified cell walls :check_mark: X :check_mark: X
2 Likes

Additional design details on what I call “non-cell hex parts” was requested on the 1.7 planning thread, so I am adding it here for now.

After processing any comments and alterations and if generally positive (whether there is truly time to implement or not), I will add the design to the wiki.


Non-Cell Hex Parts

The objectives are is to:

  • Accurately represent the real-life biological structures that are not really made of cells.
  • Let people place things that have different properties to their normal cells (such as providing much better defence), without allowing multiple membrane types in one species.
  • Provide more variety in the design of Multicellular Species.
  • Provide for specific functions really well, without the high upkeep, but also flexibility, of real cells.

Editor mechanics

These are found on the structure tab in the editor, under where the cell types are listed. A part can simply be selected and placed in a hex, same like you would do with a cell type. They have their own set MP cost, like organelles for cells. Unlike cells, you cannot modify them in any way. They are included in the growth order, same as cells.

Mockup

For gating/unlocking these parts there are a few options, but none of these are necessary for the feature to exist at all. Having them available at all times would still be functional.

  • Use the same unlock system as Organelles do.
  • For them to be placed, require having certain parts inside the true cells.
    • Only allow placement of non-cell parts that require cell Organelles adjacent to cells that have those parts.
  • The first placement costs more MP, subsequent placements cost less / unlocking them costs MP.

Gameplay mechanics

Non-cell parts would functionally actually be pseudo-cells that use the same base mechanics. They grow, have collision, MP, have HP and can be destroyed, etc. However, there are also things that may (functionally) be missing/unused, for example ATP costs and processes. They also have traits that are normally connected to the membrane type (like damage resistances), but have them be different from the actual membrane type of the species.

Rather than having specific models, non-cell parts are typically made up of model-less invisible parts that just exists to have a membrane generated (and technically to provide some of the mechanics to the non-cell). The looks then thus come down to the membrane shape and texture. The hex size of these parts can technically be anything and in any case we rely on the membrane stretching system to make it shape itself to the rest of the body design. (this will work especially well if further membrane stretching improvements succeed) Making the “invisible part” large enough would ensure it covers enough area/surface. Considering the minimum size Multicellular cells have, they could easily be made to be 14 hexes.

Specific Examples

Shell

Basically the defensive benefits of a Calcium Carbonate membrane, without the hassle of having it as a cell.

  • High HP (~200MP)
  • High phyisical resistance, not so much toxin resistance
  • 13 hexes invisible part, so has:
    • 13 phosphate and ammonia cost
    • Reasonably high mass so it slows you down a bit.
  • But does not require any osmoregulation or movement cost for the above.
  • Does not have processes.
  • Cannot collect any compounds.
  • Visually uses either a new texture (based on microscopic shell textures) or the one of the existing Calcium Carbonate membrane type. But importantly, it is a 100% rigid and opaque “membrane”.

Chitin Cuticle

Represents a tough but flexible outer layer made of proteins, like on roundworms and eventually arthropods.

Like the shell part, but:

  • Medium HP (~100MP)
  • Some physical and toxin resistance
  • Low density, so it does not slow you down much
  • Visually, can use an opaque and less wiggly (but not rigid) version of the Chitin texture, or some new texture.

Others

Other easy options are fluid pockets that can be used for low-maintenance storage.

Many other things are possible, but would rely on the same amount of effort as creating mechanics for a new Organelle, just that the end result would be using this framework instead of being placed inside a cell:

  • Transportation cavities.
  • Extracellular digestion area

Any thoughts on the above?

So actually non-cell parts are cells??
Did I get that right?

They would basically just be cells with a predefined set of organelles, and some features disabled like needing to use ATP?

I’ll need to have a think about this because selectively disabling just a few features is, on an initial think-through of the feature, more difficult than making them separately. Making them separately makes the growth system a bit more difficult to update, but making them cells requires touching a ton of systems to make sure they work in a sensible way for the partial cells.

1 Like

In this design I made, yes. I think I remember you saying when I first proposed this “non-cell parts” idea that for placement and handling you would need to treat them as pseudo-cells anyway. That got me thinking whether treating them as special cell entirely would be an easier way to conceptualise/implement them. Using the membrane system avoids having to make models (though getting new textures may not be any easier) and with the membrane system lets things more easily fit into the existing body.

But of course I could be entirely wrong about what’s actually easier to implement, so I would very much like to hear what you think is easier. Having them be actual parts with models similar to organelles would also work I think. (though I would still like to use the membrane drawing system if possible)

Except, then we have to define special membrane types that are absolutely not to be accidentally selectable in any place where membranes currently are changed.

And even when treating the parts as cells, it needs custom handling all over: exemption from uniform membranes, unmodifiable type, disabling right click options. And that’s just in the cell body plan editor. So I think there’s probably as many exceptions to the features that could be shared than what can be just shared.

So I’m kind of almost thinking that a parallel list of external parts in a multicellular species is the easier implementation to get right rather than try to make sure all the exceptions that make the non-cell parts unique from other cells work without bugs.

1 Like

Fair enough, I will defer to you on what you think is the more achievable path.

Okay, that just leaves the question of what would be the available parameters such as system of parts could handle/would be relatively easy to implement. Can they have HP, or collision, other mechanics? Also, what would the constraints be/what would every part need to have in common?

I can design around the technical constraints of what you think the best system would be.

Well when making them separately each extra feature is more work. While if making them just special cells, each removed feature is quite a bit of extra work.

But I definitely had collision in mind for them for the start. And also it shouldn’t be too hard for them to have a health to allow them to be destroyed, mouse over text, and them growing as part of the growth system. Though slotting them into the growth order would be a bit complicated.

I see. I was hoping with the cell-like approach it would be possible to easily do: “there is a process list, but it’s empty”, “there is an osmoregulation cost, but it’s 0”, etc. But I already gathered from you that this is not the case.

This (plus damage resistance maybe? Though I think that is a core part of the damage system anyway?) would be plenty for all sorts of defensive barriers, which is the biggest demand I think. Not having HP but still having collision would be sufficient for a very extreme defensive tool.

I do have some concerns about how well a defensive barrier made of parts can work if they have a model of a set size, but that may have other solutions

How would parts in theory function if they’re not in the growth system?

Would having them in the growth system without being in the growth order work at all? Or are you just saying that would be the most difficult part of putting them in the growth order?


Some other functions that I could also imagine being useful, but are of much less importance, are storage and the ability to deal damage like a pilus.

Any other, more creative ideas are things that I am sure would be very difficult to implement, whether by this methods or via other features. A slime that does not have absolute collision but does act like mucilage, a damaging field, etc. Basically at least as hard as any organelle with a non-process function.

I think that’s all out of scope here, but maybe the architecture of the parts system existing can help any future volunteers.

This is again a special case for cells. So damage resistances would need to be made from scratch.

Damage has two ways to apply: a general thing to anything that has health, a special override for microbe targets (anything that provides cell properties).

This is part of the reason why I want to be actually 100% done with the microbe stage as each added feature has added more and more spaghetti onto the codebase, so it is starting to be a mess and any microbe feature change is really painful.

Spawned all at once either at the start or the end of growth.

I’m talking about having just a very general GUI for either picking all external parts to be added last or after a specific cell in the order.

This is again because of the way the growth order GUI works it would be a major hack to put anything that isn’t a cell to be displayed there.

It’s literally starting to sound like there’s no other way to implement this feature than with a premade cell template that tries to customize almost everything related to cell functionality. We just have to deal with all of the weirdness that comes from the non-cell cells accidentally doing some cell stuff they aren’t supposed to or being counted in somewhere (I imagine you want the movement speed calculations etc. to not count these extra cells, and not drain the colony average shared compounds into them etc., so basically every single cell-touching system has to get a special case for this feature).

I’m sure @ImanProductions will absolute love this as there’s going to be so, so many corner case bugs due to this design.


Well I can at least look forward to being able to call the multicellular stage done in a few months and then telling everyone to never touch the code again where there’s a bunch of hard coded corner cases all over the place…


Edit: one more question: were you thinking that non-cellular parts can be engulfed or not? That’s also a major pain point if they need to be engulfable. Or if implemented as cells, not allowing them being engulfed is going to be the difficult option.

I see, I was quite unaware of there being a “general” system at all.

Hmmm, spawned at the end could perhaps work, but at the start definitely not. After a specific cell would also be functional.

I did mention those as “less important” for a reason. I’m not saying what absolutely needs to be in there, just trying to probe what is reasonably doable.

This whole feature is labelled optional for a reason. My main hope here is just to have a discussion on whether we can spend development time here in a way that’s worthwhile for gameplay. I am hoping I can also get @Deus opinion on this.

Well it would make sense for them to just drag you down with their set weight, but they should not be propelling you. Though I remember there may be some… oddness with how the colony movement system actually works with that?

Not entirely sure what mechanic you are referring to, but is this a problem if they have a storage capacity of 0?

I think either outcome here is fine. What they’re representing mostly is not supposed to be nutritionally great, and so having them non-engulfable makes sense. If they can be engulfed, that’s not really a problem either.

Well for rotation calculations they would basically tank the rotation, because they themselves would be no rotation (unless we hacked that as well), as it is now about the average rotation of the colony so throwing in a 0 there would slow things down a lot.

That’s kind of the thing, we wouldn’t really want them to get compounds into them, but I’m sure that 0 capacity compound bag will trigger some other bug somewhere, needing extra fixing. And trying to omit the ability to store compounds likely won’t work as the colony won’t allow stuff into it that doesn’t store things.

So yeah, we’ve built all of these nice systems based on requirements at the time of their writing. But then there’s like 5 more ideas that need to modify the system for other stuff and then you end up having to dirty the original design that no longer fully makes sense for the added 5 things on top. That’s kind of the situation where we are at in regards to many of the microbe and colony related places in the code.

1 Like

I think my general thoughts are that it might be worth prioritizing part-related concepts discussed in the other thread (Multicellular Parts) - such as the digestive/signalling/nerve system analogues - over a more elaborate feature which we aren’t fully sure about.

Non-cell parts sound fun and open up a realm of possibilities - shields, unique abilities, etc. - but because they’re a pretty alien concept to Thrive as of now and would likely require a ton of design and manpower, we aren’t fully sure where that could lead, and if the time sunk into that would do a meaningful job of having an impact on larger questions for the multicellular stage.

I think more traditional parts also tie more conveniently into larger themes of progression - for example, having the presence of certain parts results in a more advanced start to the macroscopic, needing to implement certain internal parts/organelles before progression, etc. It’s a bit harder to tie non-cellular parts to progression in the same way.

So while non-cellular parts are a good idea to make the multicellular stage more fun, I’m not fully sure if they work as well as other concepts in filling out the needs our stage currently has.

2 Likes

I do actually agree that each of those other example has a higher priority. I wrote this design now because it’s requested in the 1.7 planning thread (as this was listed on the roadmap for 1.7 as optional feature). I think we can conclude from this conversation that it’s wiser to focus on the non-optional features listed for 1.8 and later features first, rather than looking at the optional features for 1.7.

I am actually doing some research for a final design on signalling/nerve cell/axon since that’s also listed for 1.7. I do want to note I left a previous comment on that thread about the other listed features, digestive especially.

2 Likes