Translating Multicellular species to Macroscopic species

[Rathalos]

@Deus

I really do hope we consider things from a “best for macroscopic, work backwards to the microscopic” approach instead of a “work with what we have and grow into the macroscopic” approach.

I think you can see that my primary intention with this thread was indeed to look at what exists in both systems and use that as the foundation to look at what can be done to translate between them. So, especially for anything that you think would not work for the Macroscopic concept I would love to hear it!

But I do have to add that while I think the focus should be on Macroscopic editor designs that work for the Macroscopic Stage, we do need to intentionally balance that with portability from the previous Stages. Following life through the ages and doing a better job at connecting those stages than some other games is one of the stated objectives of Thrive.

For a strictly optimal “creature creator and life sim,” a game that is just that would do a better job. Carrying things over between the Stages is a selling point of Thrive in compensation. We should not be losing sight of that.

@hhyyrylainen

Right now, metaballs are always perfect spheres, and I think that is a requirement of the entire convolution surface approach, so metaballs have to be spheres, they can’t be stretched horizontally.

Ah, I knew that mathematically, meatballs don’t have to be spheres, but it’s good to know what the limitations are we are working within.

Though in theory, the nodes you manipulate in the editor don’t have to be singular metaballs themselves either? For example, one manipulatable node could have two additional metaballs attached to the side, with the “width” setting of the node controling the size/distance of those two side metaballs. But those three would all carry over the settings and properties set in the “node.”

The reason to do this would be that creating any shape more complex than a worm out of exclusively spherical metaballs that potentially each have their own settings is potentially unusably complex. But this is really more of a discussion on the Macroscopic Editor itself.

@hhyyrylainen

I don’t know how this would be concretely programmed. The player doesn’t have to follow any symmetry in multicellular stage if they don’t want to. So I’m not sure how this would otherwise work than by just taking only “inspiration” from the player’s current shape but otherwise basically just discarding what the player designed already…

The Macroscopic Editor needs a forced symmetry mode that it either starts in, or is a very early development within it. Otherwise having any kind of realistic animal creation and evolution will be unworkable. So, we need some way of converting asymmetric shapes into synthetic ones, unless we expect players to manually trim their designs to be symmetrical before they can enable it. (Again, this is more of a discussion for the Macroscopic Editor thread) The simplest method would be to enforce it right at the start of the Stage. It’s possible to have it happen in Macroscopic itself, but that just makes things more complex.

I will also say here that if you are still imagining each metaball (or “node?”) being made up of one celltype, and us therefore being able to convert one cell to one metaball without issues, it might be worth reconsidering those assumptions. If, for example, we eventually want to construct limbs out of a reasonable number of controllable objects, one such object contains skin, muscle and bone at the same time at minimum. Many things such as flagella cells also just don’t make sense to have solid balls of. They would be assumed to be just the “skin”, with most of the volume being made up of something else. Once again, Macroscopic Editor discussion. Here, I’m just trying to reconcile the different designs.

Finally, I think you might be exaggerating with “just discarding” the shape of player’s designs. Multicellular designs in Thrive already fundamentally have a “front” and “rear”. Whatever features you have in the front, middle and rear would be fully preserved in relative position. What I am talking about would be “there is a row with a signalling cell on the left, a digestive cell in the middle and a pilus cell on the left” would be converted into “one flattened node with those three functionalities, or three metaballs which each have all three properties.” You did make me realise that potentially this would close any “gaps” left in the hex grid, so that does deserve extra consideration.

@Kashnox

That could be a fun distinction, but considering how often people want to play as “plants,” I don’t know if forcefully losing all control over your organism outside of the editor would be satisfying for them. I think ideally, “plants” will just naturally want to move less and less as they evolve because movement will waste more and more energy as they grow bigger, they won’t gain anything from movement because they don’t have to find food, and they won’t be fast enough to outrun predators.

I do realise the risk, but the problem is that in the Macroscopic Stage the movement isn’t just based on “inherent behaviour” anymore. A tree or large algae can’t just move the behaviour slider a bit to become mobile. It fundamentally does not have the anatomy to be able to react to anything. If you’re larger than one or a few cells, you need a nervous system to realistically be able to have your whole body respond to anything in a reasonable timeframe. What do the Activity or Fear sliders actually mean for a tree?

Keep in mind also that for terrain generation we have a design need for designating some lifeforms as completely inactive. We’ve previously had discussion about whether to use things like behaviour or substrate anchoring to decide this, but when writing this post I just realised that this is a good candidate.

@Kashnox

1. Making the macroscopic species look identical to the multicellular species, with each cell being replaced by one metaball. So, most players’ species will probably start as sort of circular blobs. This does mean they’d start with a quite a few metaballs, though.

Yes, that’s pretty much what we have right now. (though of course, there is no functionality yet to which metaballs have which functions yet). And I do in fact think it’s too many metaballs for the player to be individually manipulating free-hand.

It also doesn’t resolve the symmetry problem, it just kicks the can down the road.

@Kashnox

2. Ignore the multicellular species shape and just make one metaball for each type of cell. The more copies of a cell type that were in the multicellular species, the bigger the metaball would be. This would be “discarding what the player designed,” like you said.

I will point out again that maintaining “one metaball = one celltype” is not sustainable for Macroscopic in the long run. The amount of work/time it would require for the player to add things in the editor would be absurd.

I would really recommend everyone to try to get a grasp on Deus’ Macroscopic Editor concept. It’s the only design we have for the Macroscopic Editor that would at least work and be usable. There are no (actually worked out) competing designs at this time.

But in any case, I don’t see the merit in this second option, because just making sure each cell type has its own metaball is not valuable.

---

So I would sooner advocate for:

3. We use the shape of where cells are placed to inspire where metaballs are placed and the overall shape of the organism, and the celltypes to determine what functionality metaballs in a general area have. But that does not mean that one cell = one metaball with only that cell’s functionality in the same place.

@MirrorMonkey2

Ah, my favorite topic of the starting size of the macroscopic stage! As some may know, I‘m partial to starting at 1mm, but I believe the vague consensus is currently that it‘s easier to start at 1cm. But you raise a great point, if the adult size of the starting organism is 1cm, then you‘d likely start at 1mm anyways as you‘ll presumably be playing as a juvenile at the beginning. Feel free to further discuss this in Handling Scale.

Oh right, I actually got the unit wrong!

@MirrorMonkey2

Also, if I‘m not mistaken, I‘ve seen design documents in other threads which presumed that eventually metaballs could be made stretchable/flatenable. I can‘t find these mentions, but does anyone else remember reading or writing about this?

I feel like I’ve mentioned something like “if it’s possible to flatten/stretch metaballs, that would be much better than only being able to do that by placing many metaballs next to each other” and that this would make it much easier to make a creature that is made up of one line of nodes from front to back, with other things hanging of the sides. Like Spore, but being able to change the shape of the main body. Probably I said this in response to somebody else> But I can’t find it either!

@hhyyrylainen

@MirrorMonkey2

Then maybe we need a general seperate discussion about how to handle flatness in macroscopic. It‘s an extremely common adaption for a myriad of different reasons (absorbition/gas exchange in e.g. flatworms, camouflage against the ground in e.g. flounders, navigation and locomotion benefits in inummerable fish species e.g. yellow tang (verical flatness) or stingrays (horizontal flatness)…)

You handle that by making a specific configuration of metaballs that results in a mostly flat surface.

So, exactly like MirrorMonkey already said:

@MirrorMonkey2

Right now, such shapes can only be achieved rather cumbersomely by placing many tiny metaballs next to each other to eventually form a flat disc.

Am I correct?

---

Right now we the constraints we have that lead to this are:

1. The convolution surface approach requires spherical metaballs.
2. Each metaball needs to be individually placed and controlled in the editor.

Point 2 is currently the case, but does not have to be. A metaball can have a “width” slider that spawns additional metaballs to the sides that are not individually controlled but just take the properties from the parent metaball.

Sorry to derail my own thread, this belongs more in a Macroscopic Editor thread like MirrorMonkey said.