A Comprehensive Concept for the Macroscopic Editor

[Rathalos]

@Deus

---

This didn’t properly address everything you bring up, but I do think there is something of value in the framework. Many of the points you bring up can be individual topics themselves - what really mattered to me with this document however is creating a sort of lens we could use to look at the editor with, and illustrating examples of this lens in action. It’s really hard to talk about the starting point of the stage without knowing how the editor works, how to talk about wings without knowing how appendages/limbs could work, how to understand how we can present dynamism without understanding how our stats could work, etc. So I hope we can establish atleast one basis of understanding that we can base some sort of future concepts on.

Right, and I hope I have at least demonstrated that there’s still a lot of room for design in this system. And that many disagreements on the smaller detail can all still be resolved within the same overall system, which is a good sign I think.

@Deus

I think one of the benefits of having something like center of mass relate to limbs is that the system has more of a framework to work with, even if placement is relatively free form. If the distance between a center of mass and an appendage/limb has an effect, then auto-evo has some sort of parameter it can work with. The additional joints and segments on an appendage is a bit more complex, but with that, something like the streamline relationship to appendages (longer appendages reducing streamline) can also have an effect. There obviously is more to think about with positioning, but we do have atleast some frameworks existing (hopefully) with a concept like this.

I was specifically thinking about how a joint, for example a “knee”, can theoretically be placed in many 3D locations relative to the “hip”: Forward/back, left/right and up/down. That’s a lot of variation that each need to have a statistical effect (and then have robust player and auto-evo editability), or a fixed selection (removing the choice), or have a “default” assumed by auto-evo with the player making purely aesthetic changes. But yes, I think this is possible to figure out.

---

To try to give some focused responses:

@Deus

• How do we present progression in a way that encourages gradualism?
• How do we adequately present this gradualism in a way that isn’t extremely convoluted, or overly simplistic?
  …
  The first one I think is something that relates to the two other bullet points, and the second one is something that I think can be solved with intentional thought behind when “unlocks” occur.

I think rather than answerable through unlocks, this is more directly answerable by how many intermediate required steps we design and require, in combination with MP limits. For example, coming back to your vertebrate wing example:
Let’s start with “limbless but vertebrate worm” for convenience:

1. Add appendage.
2. Add joint to appendage.
3. Make appendage long enough (slider?)
4. Add additional joint.
5. Convert joint to ball-and-socket joint.
6. Add extremity.
7. Add flight membrane.
8. Make flight membrane large enough. (slider?)
9. Turn joint into a fused joint to allow for powered flight (?)

So, assuming you can only do one of these steps per editor session (and I think that should be the case), that’s 9 editor sessions to (entry-level) powered flight. That’s a fairly gradual transition I suppose. Of course, as it should be, each of those steps has its own advantages and disadvantages, and after each of them you could go in a different direction entirely. But in this case, for example “typical vertebrate limb” to “basic powered flight” is only 3 steps. If we think that’s too short, we can add more steps in between. For example, extending the membrane one segment/digit further is one step in itself, or maybe step 9 is just the start, and you still need to adjust more joints, enlarge different muscles, etc. That’s all just a question of execution of pacing in my opinion.

@Deus

• How do we present gradualism in a way that doesn’t completely lock the player into a specific path, but also reflects the “commitment” behind several adaptations?
  …
  The third doesn’t necessarily keep me up at night, but is one of the more challenging aspects of this editor. We don’t want there to be a case where the Thrivian version of an arthropod suddenly evolving an internal skeleton rather than an exoskeleton, or a mammal immediately transforming itself into a fish with gills occurs.

I think one approach we can keep in mind: we have to expect that some of this will occur in Thrive, just for the sake of player approachability and the fact that we are ultimately an editor-based game. Being a sandbox game, we generally avoid “locks” as much as we possibly can, unless that lock is tied to a stage progression. So there will be points of time where a player could hypothetically jump across an evolutionary “decision” rather easily, or revert a change.

So the way we approach this is - with this acceptance of the above fact - having a discussion and categorizing different “categories” of adaptations as ones that we are okay with being a bit more flexible for the sake of customization, ideal progression, and ease of development, and adaptations that we want to make sure are more strict and “commital”.

For one thing, I don’t think there is really any need to prevent reversing changes, at least as long as you don’t have later changes that are fully dependent on those earlier changes (apart from stage transitions for practical reasons). Realistically, some molluscs completely lost the shell, snakes lost limbs, etc. I think the more important thing is that both the gain and loss of any such feature (really, we should regard both as “change” in a neutral way) should happen in small enough steps.
Secondly, I do agree that having some things more locked in (rigidly or by incentive) would also be fine. Because ideally, you should not need things that require a different change 20 editor sessions ago. So you developed an exoskeleton, no vertebrate limbs for you. But say you feel the need to fly. Developers may or may not have allowed the “limb membrane” method to work for exoskeleton wings. But you do have the option for “insect wings”. And you might not have digited hands, but you have other ways to grab things. You have no spine, but you do have nerves and a brain to think with, etc. So any restrictions from previous choices just serve to make those choices more interesting, they should not make you feel “stuck”.
Thirdly, coming back to “any change is fine as long as there are enough steps to it” (and we are firmly into “optional stretch goals” territory here): I do think it’s fine to add some unconventional paths for changes that seem too large. For example: remember the discussion on squids in the community forums? That’s a shell turning into something like a partial endoskeleton, far later and in a far more complex and large animal than that divergence originally happened. So some bizarre path like a creature with a exoskeleton growing more tissues around it, eventually turning parts into an endoskeleton, does not seem entirely impossible. And I would be supportive of adding it, as long as actually performing it takes long enough. (Though again, this part isn’t necessary)

---

Slight detour here: you’re familiar with the concept of the “fitness landscape”? (Accessible explanation here) Basically, it’s the same issue as water always running downhill, and not being able to run up a hill even a little bit to get down even lower. You can expect both real life evolution and Thrive auto-evo to get stuck in local optima, not being able to get to other, more optimal, points because the steps to get there would require them to get less effective first. The player is always going to have more freedom, because they can take that leap, and I think that should work fine for giving the player enough freedom while we make auto-evo strict enough.

@Deus

I do agree that the starting point of the Macroscopic Stage should be a bit before the urbilaterian, though I do think that level of complexity should be unlocked somewhat soon.

I agree, which is also why I feel like the option to develop symmetry (if it is not something started in Multicellular), should be immediately (or almost) available once you enter Macroscopic. Of course, that doesn’t mean you have to take that option immediately (placozoans sure never did), there are other options you could go for first.
I guess I should start writing my thoughts for the rest of the multicellular stage over on the other thread.

@Deus

Yeah, that was something I was beginning to think about towards the end of this process. As you mention, some of the most explosive animals have rather massive limbs because of their muscle. You see this in ungulates and species of feline, such as horses and cheetah.

I do still think that certain extremities should interact with the mass of an appendage - for example with damage or offensive weapons - and do think that certain extremities should use this constraint in a way that relates to mobility. But like you said, there definitely needs to be another layer of care dedicated towards musculature.

On the effect of appendages, I think it could work quite easily on a modifier/multiplication system.
For example, part of what goes into “speed” could be “muscle power of limb” x “traction” with type and modification of the extremities altering that traction. Similarly, damage from a claw crasping could be something like “sharpness” x “Muscle power driving the claw”.

@Deus

In my head, buoyancy ought to be a stat derived from your parameters and the effects of specific parts. So that can be an important distinction to declare; instead of mass or center of mass determining your behavior in fluids in broad brushstrokes, Buoyancy itself is an independent stat that mass and center of mass effect, but don’t necessarily define.

So the advantage of having “weight” and mass (and their respective centres) tracked separately (with weight of course mainly deriving from the mass) is that we don’t have need a separate stat for buoyancy. Buoyant parts just have negative weight.

@Deus

You do bring up a very interesting point with your distinguishing between CoM and center of weight (CoW). That is the tough part about designing an editor with such a scope; there’s a bunch of nuance for different situations. Because I do think it’s important that a generalized parameter like CoM exists, but it doesn’t necessarily act cohesively in all cases where we would like it to.

Yes, this is also a question of how complex we want to go. I thought having a (center of) “weight” and mass in the game would work, since you just use one at a time for different other mechanics. But one point is definitely easier to keep track of than two, and in a lot of situations,the two will actually be in the same place (for practical purposes).

@Deus

I wonder, if anything else, that specific parts like swim bladders can alter the effect that the mass of your torso/parts in a specific area has on your CoM, in a way that is more impactful in organisms with less mass but less impactful in an organism with more mass? That way, CoM remains as a definitive constraint and we still demonstrate the fact that larger mass organism do tend to have more weight, but we provide that sort of nuance needed behind animals shifting their weight with specific adaptations.

I will also bring up that I am open to changing the name of different constraints (especially for CoM, since that can be a very nuanced discussion).

I think if moving in this direction what I would do is:

• Call it CoW instead of CoM. (Or not, after doing more research, center of mass/weight/gravity is used more interchangeably even in educational sources than I would expect/like. Center of buoyancy is usually kept more separate because it is used for more specific situations)
• Have swim bladders simply move around the CoW in the opposite direction than what other types of body mass would do. That is instead of trying to modify what the mass around has as effect on the CoW. (Of course, this was assuming you control the size of the swim bladder independently. If this is just a trait you put on another body part, what you suggest sounds accurate)
• I think I would flip that relation to organism size around! Or at least, make it neutral. Buoyancy (like weight/mass) scales with volume. Square/cube law says this grows faster than surface area when scaling up. This was vary clear with zeppelin design. So that’s at the same rate as the mass itself is growing, meaning large animals get just as much effect of offsetting mass with buoyancy as smaller animals do. That’s a big reason why marine animals can grow much larger than terrestrial ones.

---

Admitting here: I got things a bit wrong on my usage of CoW before: apparently the term is officially used for the difference between CoWeight/Gravity and CoMass in the situation where the gravity field is non-uniform. As in, the situation of a moon orbiting close to a planet. So that’s clearly not what we’re looking for. While the concept of “Center of weight modified by buoyancy” originally made sense to me, I have not found this concept used anywhere. Rather, discussion focusses on the centres of buoyancy and mass separately, because what actually happens is (taking the average across the body) the CoM is pulled down while the CoB is pulled up. Thus ending up with the CoM directly under the CoB in a fully submerged object unless that object is for example actively using fins to maintain a different orientation.

Starting from scratch again: Maybe the easiest way to handle this is to just go with basic physics rather than trying to avoid it? Each distinct part has a density, based on its base traits and modifications. “Scroll wheel” directly increases volume of selected part. Mass of a part is density x volume. Then, you take all that Mass to determine the Center of Mass. Assuming we’re a normal living thing on land where buoyancy is negligible, that’s done.

Going underwater, I think we have two options:

• Go real. Take all the volume (ignoring density) to determine the Center of Buoyancy(or Center of Volume, I guess?). Then derive some things from the relative position of CoB and CoM, such as what the orientation of the body in the water is.
• For the purposes of CoM calculation only, subtract the density of water from the density of all the parts first, making parts with less density than water essentially have negative mass. But would that even change anything for the end result? I guess I am out of my depth (haha) with this physics calculation.

In either case, for any effects where the actual “weight” the animal feels matters, for example for animals walking on the sea floor in the same way that animals walk above land, or for whether an animal floats or sinks in general, I think we do need to subtract the density of the water from the density of (parts of) the animal before calculating a “weight”.

@Deus

Part of the reason why I wanted a parameter like CoM is that there would be some sort of relationship between where an appendage is on your body and the impact of that on various stats - being closer to your CoM favoring certain things, while being farther favoring others. Though if auto-evo still would find that difficult, there can be more rigid treatment of limbs in terms of maybe snapping onto a specific metaball for the AI.

Snapping appendages onto metaballs seems like a good option. I think there should be enough metaballs that it is not to restrictive, but it still provides a locked connection on at least one axis.

@Deus

That was me trying to find something that would work akin to the “wrist” or “joint” designation, which lets the system/auto-evo know “hey, the player/this AI is trying to evaluate this as a wing.” Cases like flying squirrels, sugar gliders, or the draco lizard honestly give me a lot of grief - could that potentially be a skin attribute? The answer there is pretty difficult to deal with; but hey, so is the topic of the origin of flight for paleontologists.

Fused joints could ideally be some sort of thing that signals the transformation of a limb the player was utilizing for unpowered flight/gliding into more powered forms of flight. It could maybe be dealt with like a special sort of digit/extremity that is applied at some point, though limiting when it can arrive would be an interesting question.

So for any of these that are ultimately limb-derived with a membrane (which includes the flying squirrel and sugar glider) I think should work the same as with bats. Though this does remind me that the membrane “Patagium”, should probably not only be selectable between segments of one limb back to the main body, but also extendable to metaballs further back and even to other limbs. Because that’s the case with bats and pterosaurs as well, it’s just more apparent with these squirrels. As for how to determine when to evaluate it as a wing:

• I think there should be an explicit option to add a small starting flight membrane (patagium) to a segment of the limb. This should trigger the “flight calculation”.
• As you expand the membrane, this would first just be “parachuting”, slowing your fall.
• Expanding it more gradually decreases fall speed, and increases forward speed at the same time. (gliding)
• If it’s big enough, you can make a joint change (?) at the shoulder that adds initially weak powered flight.
• You can then increase “flapping ability” by increasing the relevant muscle/muscle containing part.

Would that work?

As for the Draco lizard, I actually forgot these existed, and certainly never realised they were not using the limbs. Looks like they’re actually suspended on ribs? It’s rare enough that I would not put it at a high priority. Only other example I can find is… gliding snakes (what on earth…). But there are other lizards with less extreme types of body flattening for gliding, or skin flaps.

For skin flaps, I guess that’s just a flight membrane attached to a metaball without being attached to limbs. With probably lessened gliding ability but also no effect on normal limb function.

For the flattening body type: Ribs are probably something we want to represent, right? Also, I think you’ve discussed changing the shape of metaballs in the editor before. If so, this is a function for making the flattening of a metaball dynamic, which you can add if you have ribs. Would affect your temperature regulation, and have a small gliding ability attached that gets significant if you go very extreme with the flattening or in combination with membranes and other characteristics.

Then finally for the Draco… I guess it’s a metaball option for growing out your ribs into the skin membrane, letting you expand it more while remaining foldable and not taking up use of the limb? It would obviously come with the loss of many of the benefits ribs would normally give. And I guess this may not have an option to produce powered flight.

@Deus

There also was a bit of question in my head of “how do we represent the biomechanics and physics of how wings are usually evolved near the front rather than the back limbs?” But I think that can be dealt with by having flight benefit much more from a forward CoM (really important for stability).

I think position of the wings relative to the CoM should be a big thing here. Though technically we’re talking about the centre of lift here. Yay, more centres! A cursory search suggests for an aircraft the most important thing is for the center of lift (wings) to be just slightly behind the center of mass for stability (otherwise the plane has the tendency to flip). Though at least birds might be less stable, using active movements to balance things out, perhaps similar to fighter planes.

But overall having the wings close to the center of mass seems like it should be encouraged.

@Deus

Perhaps the thing with flight isn’t fully a matter of making it be “locked” until really late, but instead have it be something that requires an extreme amount of commitment; you need to make sure your organism has lower mass, has a forward CoM, your appendages have to be really oriented towards a specific parameter, etc.

Like I more or less started with: I do agree that we shouldn’t think about this in terms of “late unlocks”, but rather something that needs many focused steps to get to.