Macroscopic Editor, Progression, and Principles

[Deus]

I think that’s more a question specifically related to progression more so than the underlying mechanics of the macroscopic editor. After trying to make an editor concept while trying to keep progression (specifically, early eumetazoan evolution) in mind, I can say it’s pretty difficult to create a universally applicable editor by limiting focus to a specific era of evolutionary history while trying to extrapolate these findings to other eras of evolutionary history at the same time. Like Buckly has done, I think it’s better if we create general principles and envision general mechanics first, then think of specific case studies and refine the details as we go along, which is something I’ll be focusing on.

Also something of interest: Williston’s Law. A user on the community forums in this thread (Questions about the realistic implementation of repeating parts/segments (and Williston's law) - Multicellular Stage - Thrive Community Forum) put it this way:

“most organisms have ended up with their characteristic arrangement of parts by first evolving many similar parts and then specializing or losing those parts over time.”

Hence, for example, many types of bony fish having more fins than tetrapods have limbs, or the ancestor of arthropods tending to have many more limbs than current arthropods such as was seen in trilobites. Note that Williston’s Law isn’t necessarily canon - currently scientists prefer explanations of variances in evolutionary rates more than general principles of morphological complexity - but it could be a line of thinking which is implemented well in Thrive given the more artificial nature of our evolution. It also reveals that early on in metazoan evolution, experimentation with limbs was rather frequent; it was complexity which transitioned the focus more to tweaking existing structures rather than creating entirely new ones.

I think ultimately that we’d want to have a split between how we treat the creation of limbs (initial investment) and the modification of limbs. We’ll probably want the initial investment to create a limb be more expensive than the modification of limbs in terms of MP. We’ll also probably want to vary the cost of both of these depending on the player’s morphology; so for example, a vertebrate analogue will have to spend a lot more MP than an arthropod analogue to create or modify their limbs. We’ll also probably want to balance/calibrate states related to things such as movement speed or something so that as a player’s limbs get more complex (perhaps in joint count?), they’ll be encouraged to have different limb structures. So for example, vertebrate limbs would be most efficient in terms of speed with either two or four limbs on the ground, with 3 joints in each limb. Arthropod limbs will have slightly more leeway (ants have 6 limbs with 3 joints in each limb, whereas tarantulas can have 7 joints in 8 legs), with more joints and limbs reducing speed but increasing agility for example. These two factors combined should allow us to encourage players to prefer spending MP on the editing of limbs after a while.

But in regards to more specific features that showed up later in evolutionary history, such as the evolution of fur and the such, you have a valid point. We should probably think of a sort of unlocking method in that regard.

PS: I would also like to note that’s vertebrates fundamentally have inherited a development pattern from their ancestors that makes it genetically harder to coordinate the development of additional limbs too. So we do have some grounds of, after a certain point, abstractly bumping the costs of creating limbs for organisms with an endoskeleton.

[Buckly]

A bit late to the party, I know, but if it really comes down to it we could potentially end up hiding parts the player cannot utilize in later stages of the… stage.

Obviously we will need a way for the player, and autoevo, to create new limbs at some point, not to mention freebuild which should remain pretty unfettered. So I believe the overall features of the editor are fine, we just need to consider how it changes while the player progresses.

One idea of my own I’ve been toying with, is the idea of committing players to a sort of progression path tied to their choices. These would lock them out of certain parts, but unlock others. The first of which would arise in the transition between microbe and multicellular. Whichever membrane-type their cell possessed would become the defining type. They would no longer be able to alter their membrane type, but may gain access to new associated features. For instance, cellulose organisms would have access to bark and trichome coverings later on, but would not have fur or scales.

The development of advanced bodily support too could be a part of this. endo/exoskeletons would prevent the player from creating brand new limbs, forcing them to creatively alter the limbs they already have. It would basically be the crossroads between …whatever and a proper animal. Not sure what we could give in return though…

I’m sure we can all agree that it would suck if after progressing you just suddenly lose access to parts, it would be pretty jarring. But as organisms become more complex they can no longer throw new limbs and bones on themselves willy nilly, so we would need to make sure the player always has some form of tradeoff in return.

Whatever the case may be, it’s certainly a matter of progression that we need to consider. I think the editor concept I have outlined is fine for a general overview for the future.

[MirrorMonkey2]

I thought about Bucklys suggested macroscopic editor interface and overall I really like it. But I have one important gripe with the internals tab: In my opinion the left panel feels a bit empty and devoid of information when it only shows the tissue types. In my opinion it could be better utilized by integrating some information about the metaballs into it instead of displaying these metaballs data in a pop-up menu.
As I understand it, this proposed metaball context menu would pop up in front of the organism. imo this is suboptimal as I think it would be better if you see the metaball you’re editing while doing so.

I therefore propose that the left panel includes a category called “segments” (I think this may be a more intuitive term for metaballs to use in-game). This category contains all the metaballs which the player can name to keep track of their function/position. As you can see, in my example the player has named them Head, Upper Abdomen, Lower Abdomen and so on.

Each segment section, when opened in the left panel, would include a list of that panels organs, as well as the tissue types which are contained within that segment but aren’t part of an organ.
The left panel functions much like a set of spoilers within spoilers which can be opened and closed as needed, much like many of our menus function. But there is an alternative way to quickly jump from segment menu to segment menu: Clicking on a segment of the organism will bring you straight to that segments menu and close all other segment menus.

Clicking on “Add Tissue Type” would send you to the top of the left panel where you can select a type to place in this segment from a library of all tissue types in the organism.
Clicking on one of the organs would open an organ pop-up window. This organ pop-up would open to the right, in front of the organism. This is consistent with the idea I layed out before: When you click on the metaball on the right side of the screen, the corresponding menu opens next to it, on the left side of the screen. When clicking on an organ on the left side of the screen, its corresponding menu opens next to it, on the right side of the screen.

I hope that I explained my suggestion as clearly as possible. I will sketch up a organ menu pop-up if needed. If I have time I may also do a simple animation of how clicking on a segment would open that segments menu and so on. Some of these things may be more easy to explain as a series of moving images rather than some rambling paragraphs.
(Btw @Heath I borrowed your critter for this concept muck-up, I hope that’s ok)

[Buckly]

You raise a good point! Being able to avoid a popup menu would be nice as it clears up the player’s vision.

Using the left panel to display the statistics of the currently selected metaball is a pretty great idea, though I fear that listing all of the individual organ sets and such may end up feeling overly cluttered and messy.

I am personally in support of replacing the left menu with the selected part’s details whenever the user selects a part, but otherwise it would just display available tissues.

That being said, I am by no means an experienced graphics designer, so I’ll let the graphics team have the final say in the matter.

[MirrorMonkey2]

Thanks for your reply! I think I get what you’re saying and I’m going to make an alternative mock-up which takes these changes into account. I may not fully understand what you mean by “organ sets”, but I’ll just go with my interpretation of what that means:)

[Deus]

I had this thought train about how we can deal with developing playstyles in the late-multicellular/Aware Stage. I think this stage will be Thrive’s cool “gig” in a way, considering there are no similar games representing player-controlled evolution in as scientific of a way as possible. It is also the stage of life where evolution will happen the most quickly and lead to the most diversity of playstyles, so it is important to get it down right.

There isn’t much of a concrete mechanic suggestion here; rather, it’s a suggestion on how we can think about things going forward.

---

PHYLOGENY AND DEVELOPMENT

We would be interested in representing the evolution of metazoans (animals) and plants in this part of the game. Given just how much diversity there is in the body-plans of macroscopic organisms, this is a vast undertaking. So we need to be deliberate and methodical in how we approach the implementation of various unique adaptations. If we’re too shallow with what we implement, then there will be very little replayability in Thrive and many shallow mechanics - if we’re too detailed in everything we implement, nothing will ever happen.

In my mind, the best way to address things is by looking at phylogenetic trees and focusing on a specific clade as we work through upgrades.

(skip this paragraph if you understand the diagram above) Just to review phylogenetic trees quickly in case anyone in the larger community reading this is rusty on them, they basically map out the evolutionary relationship between different groups of animals. The number of “splits” there are between different groups indicates how closely related they are. So in this diagram, you can see the line leading to Cnidaria (jellyfish & coral) and Ctenophora (comb jellies) indicates that Cnidaria and Ctenophora developed pretty early in the evolution of metazoans, splitting off from other metazoans very quickly. Here is a basic introduction to the topic: Phylogenetic Tree Basics - YouTube

As far as I’m aware, this particular image isn’t necessarily the “definitive” phylogenetic tree of metazoans - there are various phylogenetic trees online, with various levels of detail. The important thing though is that these diagrams present us with a clear understanding of how different animals relate to each other.

There are also phylogenetic trees for each group of metazoans. Here is a phylogenetic tree for Cnidarians…

So essentially, by looking at the larger eumetazoan phylogeny tree, we have the complete tree of life in our hands. So, what I think will work best is to focus on a specific part of the tree for a specific series of patches. We can determine what to focus on first based on how early in the evolutionary history of eumetazoans a specific group appears.

We obviously cannot represent every single species within a family, so our job will be determining what collection of cool adaptations will best represent the phylogeny of a specific clade, and then choosing a collection of cool traits from the various subphylum within said phylum to adequately represent a given species.

So for example, this can be how we breakdown the Cnidaria…

---

Cnidaria

Cnidarians include Medusozoa, the group which includes all the” traditional” jellyfish and Anthozoa, which includes coral and other sessile organisms. We will likely want to focus most on Cubozoa and Scyphozoa (Medusozoans) to represent the two forms of major forms of jellyfish. We will also want to focus on coral, though they are more adequately represented by sessile gameplay and should be considered there.

Hydrozoans are the most numerous group of Cnidarians, though many are characterized by their tiny size (might not need many dedicated parts) and colonial nature (something we probably won’t simulate). There are also other forms of Medusozoans, though they are largely sessile, so there might be overlap with coral.

Medusozoa (Primarily Cubozoa and Scyphozoa)

Medusozoa tend to be motile, are radially symmetrical, and have nematocysts which allow them to sting. Some use their appendages to poison prey, though others have minimal predatory capacity and instead prefer filter-feeding using those appendages.

How to Represent Medusozoa

Their “floating” nature can be represented by allowing players to alter their mesoglea/buoyancy, and their stingers and tentacles can be represented by allowing players to develop appendages. Many of these appendages are like the familiar tentacles, though some are larger, expanding surface area.

How to Represent Scyphozoa

Scyphozoans are known as the “true jellyfish”. There are roughly 3 orders of scyphozoans, and perhaps up to 400 species. They tend to be larger than hydrozoans and contain a slightly more complex movement pattern which allows them to move at their size. Variance within Schyphozoa can focus on the presence or ratio of tentacles and oral arms. Some groups have many tentacles and no arms, some have arms and tentacles, others have no tentacles and only arms. Behavior variances also exist.

Thus, we can probably adequately represent Scyphozoans within Thrive by allowing variation in the number of tentacles and oral arms. Size will also naturally play a factor.

How to Represent Cubozoa

Cubozoans are box jellies. They are characterized by their potent toxicity and their more box-like shape. Cubozoans are known for having a rather complex nervous system and more capable sensory than other jellyfish. They can also swim pretty fast for jellyfish.

Thus, box jellies can be adequately represented in Thrive by allowing customization of the effects of jellyfish stingers (nematocysts). They will likely naturally emerge as players with Cnidarian-esque body plans enhance their nervous system and sensory capabilities.

Other

Hydrozoans exhibit a good amount of diversity in the capability of their appendages. For example, some projectiles are merely grabbing/restraining rather than poisonous. That could be a relatively simple inclusion to diversify combat, akin to the toxin system in the Microbe Stage. They are also known to be rather small at times, though this can vary.

There are various types of sessile Medusozoans. These can be used to diversify sessile gameplay, though they aren’t necessary in my opinion.

Here we have a pretty simple way of representing an entire group of animals in Thrive with just these steps…

1. Allow mesoglea and customization of buoyancy/density.
2. Include appendages akin to oral arms and stinging nematocysts.
3. Allow customization over the number of these appendages, the effects of these appendages, etc.
4. Implement other global mechanics, like the evolution of sense and such.
5. (Bonus) Implement some sessile gameplay capacities with Cnidarians.

---

That’s much more manageable than going through every single living jellyfish and throwing out some ideas, no? We can implement these and go on our merry way to represent other organisms.

I understand that doing this for every clade can look daunting, but we definitely can simplify things. For example, did you know that “worms” are represented across a huge variety of clades? There are mollusc worms, annelid worms, nematode worms, platyhelminthes worms, etc. Many shared traits exist between many groups of organisms, so we can oftentimes knock out various clades at the same time. Or atleast, be able to repackage various adaptations/mechanics for future traits. Jellyfish appendages can translate to octopi appendages eventually. It also helps to realize that players will have a lot of fun in combining various traits from various clades; we don’t have to necessarily think of things as being so specialized.

Of course, there are certain clades that will require a lot of focus. Vertebrates, Crustaceans, Molluscs, and Hexapoda as examples. But if nothing else, I think this approach to developing the macroscopic stages will be the best way to approach this daunting task from a design perspective:

1. Research a clade. Familiarize yourself somewhat with the orders of said clade.
2. Find out the defining traits of the clade and its various orders. There are many of course, but simplify your list to the least amount of traits for the most amount of diversity. Identify some traits which might be bonus objectives as well.
3. Then, we start developing this group of animals, focusing on them for a series of updates.
4. Once all “bottom-line” traits are implemented, repeat the cycle with a new clade.

[Buckly]

I think this is a great run-down of the process of accounting for potential variety in Thrive. Maybe I’ll post a link on our wiki page to this, or condense it into a paragraph to help prime new designers on finding inspiration for features.

That being said, we must be ever mindful of casting too wide a net when it comes to creature editing, lest players become rather overwhelmed.

[Deus]

Hello all,

As I’ve been getting more motivation to get involved with Thrive again, I’ve been dumping some thought into this topic just to get the creative juices flowing. I wanted a rough idea of the macroscopic stages - more specifically, I wanted to create an outline of how we could go about representing the most number of organisms with the least number of features necessary. So to go about this endeavor, I read a bit into phylogeny and taxonomy, and tried to characterize various groups of organisms I noticed.

I have a clade-by-clade breakdown below, but first, I wanted to note some general thoughts I’ve had as I went about this exercise…

1. Mechanics Over Parts - Thrive’s early macroscopic stages will likely be carried more by underlying mechanics shared by most organisms and less by unique “parts/traits” giving abilities relative to the later portion of the macroscopic stage. Before the arrival of the more complex vertebrates, arthropods, molluscs, and annelids, organisms were very weird structurally, but had relatively simple ecological niches. They were mostly filter-feeders, bottom-feeders, and very occasionally were limited predators. The first two niches will largely be influenced by fundamental mechanics, such as surface area-volume and organ systems. Furthermore, we want to make sure the player has a grasp of their basic macroscopic mechanics before throwing them to super-predators.
2. Progression Pipelines - I think there will generally be two “game progression styles” in the early macroscopic/late multicellular stages, which I informally/affectionately nickname the “Thrivian Jelly Pipeline” and the “Thrivian Worm Pipeline”. The Thrivian Jelly Pipeline covers clades like that of the ctenophora and the cnidarians, while the “Worm Pipeline” covers everything else. The Jelly Pipeline is more limited in progression, as most advanced organisms evolved from worm-like organisms; as such, it’ll act as a unique playstyle. The worm pipeline is likely more standard to most Thrive playthroughs, and more directly proceeds to more advanced morphologies. The two aren’t necessarily mutually exclusive by the way, but the more Jelly-Like you are, the harder it is to evolve advanced structures in your body plan.
3. Scope Limits - I think there are two things that we should declare not to incorporate within Thrive now unless implementation is very simple, and a third thing we should really think about. First, colonial macroscopic organisms, as these are a very niche and complex cases. Second, complex endoparasitic organisms, as it would be a nightmare to represent a microscopic representation of the inside of another organism. Third, we should really put some thought into the various scales we will represent. There will undoubtedly be times were we will have to cut between various “scales”, such as in microscopic multicellular organisms to the macroscopic world, and omit certain niches or organisms. Where will these cuts occur?

This post focuses on the “Thrivian Worm Pipeline”. I try to give a broad description of various clades, and infer some basic parts or mechanics we can implement into Thrive. As such, most of this will be focused on the early parts of the late-multicellular, probably before the playthrough’s “Cambrian Explosion” where more advanced morphologies appear.

By the end of this post, hopefully you guys understand what I mean, and hopefully we will have a slightly clear understanding of how we can define our scope for the early macroscopic stage.

Going through this has made me believe it is actually very feasible to represent a good amount of diversity with a large, but realistic amount of effort. I hope you guys emerge with the same feeling, and I promise that I will begin focusing on more immediate concepts soon again!

---

SIMPLE BILATERANS AND THE “WORM PIPELINE”

Xenacoelomorpha

Xenacoelomorpha are triploblastic and bilateral, meaning they are able to develop muscle-derived and more specialized organ systems, and are bilaterally symmetrical. They do not have a complete digestive system (their mouth filters both food and waste because they don’t have an anus).

There are two major clades within Xenacoelomorpha…

1. Acoelomorpha
2. Xenoturbellida

Xenacoelomorpha probably serves as the representation of what most macroscopic animals in Thrive will look like only a bit before they start specializing into more unique organisms. They don’t really have any unique characteristics to implement.

Xenoturbellida

Containing roughly 6 species within the same genus, Xenoturbellida represents a very small group of animals. I don’t think there is much we can derive from this clade. They notably have a mouth opening on the bottom of their body rather than on their anterior side. Above is a Xenoturbellida that looks like a churro; most Xenacoelomorpha look a lot like this, except less churro-esque.

Implications for Thrive

Churros. Having the ability to customize where a mouth part is placed would be an interesting characteristic for more simple organisms. However, if that interferes with the future parts of the multicellular stage with a more defined head and mouth at front of body, then that takes precedent.

Acoelomorpha

There are roughly 350 Acoelomorpha, representing a decently-sized clade. Being rather small animals, most of them registering on the centimeter range, they generally live either planktonic lifestyles or slither around on the benthic floor. A few of them have very simple sensory organs called ocelli, among the simplest of metazoan eyes. Above are mint-sauce worms, an example of Acoelomorpha.

Notably, some Acoelomorpha are able to integrate photosynthetic plankton within their epidermis via consumption. This allows them to benefit from photosynthesis; some of these organisms depend completely on their symbionts.

Implications for Thrive

As said above, there likely isn’t much to extract from Acoelomorpha; they just serve as a representation of what most players will somewhat look like at some point in their playthrough.

A unique ability we can implement is to get some photosynthetic capability from the food you eat. This would have to be balanced in some way to make it so that only very simple organisms with very thin membranes can possibly benefit from this adaptation. For example, reducing temperature tolerance ranges and health could work.

So, I guess the breakdown for this group after simple mechanics are implemented involves…

1. Implement a capacity for the player to absorb the photosynthetic ability of what they eat if they have sufficient adaptations. I would think this would be more of a bonus trait rather than a core requirement in terms of mechanics.

SPIRALIA - MORE ADVANCED WORMS AND MOLLUSCS (Not Covered Here)

From here, we can discuss Spiralia, a large group of metazoans including some more complex organisms worthy of attention.

Platyhelminthes - The Flat Worms

The flatworms. Triploblastic and bilateral, flatworms have no true body cavity, resulting in a rather simple body plan. They display cephalization (they have a true head) and have a more developed nervous system, though they don’t have a complete digestive system. Their high surface area allows them to circumvent the need for a elaborate respiratory or circulatory system, relying mostly on their digestive system for circulation. Most are rather small (the millimeter range), though some are rather visible benthic animals. Their mouth notably is found near the bottom of their body, which looks somewhat like a proboscis. This mouth can extend in some species, though not to a significant amount.

There are two major groups of platyhelminthes: the Catenulida and the Rhabditophora. The Catenulida have been rather difficult for scientists to distinguish due to their relatively small number of species and their similar morphology; meanwhile, the Rhabditophora are the more “iconic” species of flatworms. Rhabditophora include the notorious tapeworm, and many other parasitic species.

Implications for Thrive

To me, the flatworms represent another point in the “basal worm pipeline” that most players will likely end up a part of as they become more advanced organisms. They represent a “step-up” in terms of Thrive progression, with the advent of a more advanced digestive and nervous system. I think organisms such as these will emerge naturally in Thrive without the need to implement unique mechanics, and thus, gameplay for these sorts of organisms will depend on the fundamental game mechanics shared by all macroscopic organisms. I notice that this is a trend with many of the most basal, early-multicellular organisms - so we might want to pay attention to creating simple, but fun mechanics for the early stages of the late-multicellular stage.

I will say though that flatworms can be very colorful, so having nice customization options could be seen as a bonus for this clade. And of course, being able to “flatten” the metaball body plan of soft-bodied organisms would help visually represent these organisms as well.

Nemerteans - the Ribbon/Proboscis Worms

Nemerteans uniquely have a proboscis. This projectile proboscis can rapidly extend, capturing prey items and increasing surface area. They are rather similar to flat worms - however, they have a complete digestive system (the presence of an anus) and a closed circulatory system, representing one of the most basal organisms to develop such features.

The two major groups of ribbon worms include the Enopla and the Anopla. The most distinguishing feature between these two groups revolve around the presence/absence of a “stylet” in their proboscis, which essentially is a sharp needle-like structure. Enopla have stylets; they sometimes utilize it to grasp prey.

Implications for Thrive: Another point in the Thrivian “worm-pipeline”, nemerteans can be adequately represented with what has been discussed above upon implementation of a proboscis…

• Implement proboscis.
• Allow customization of proboscis. An “unarmed” proboscis can completely consume small-enough prey, but is rather useless against larger organisms. An armed proboscis can grab and inflict damage on larger prey items, but does less damage.
• Armed proboscis can be imbued with toxins.

Gnathifera - Jawed Worms

A larger clade rather than a phylum, this group contains many smaller clades. I think it’s worthwhile to discuss these organisms as a whole before individual diving in. Gnathifera all display various forms of chitin-derived mandibles. These mandibles come in various forms and perform various functions. As such, the most basal feature which can represent the jawed worms in Thrive is…

• Implement simple, chitinous mandibles as a very basal jaw structure.

Diving into each individual phylum of the Gnathifera will help us see some customization options for these jaws. We can’t really go into much depth here without a larger discussion of how mandible customization will work however, so this will likely be a rather brief section.

Chaetognatha - Arrow Worms (Gnathifera)

Placement of these organisms is a bit dubious within Spiralia, but these organisms represent a large percentage of planktonic biomass despite a relatively small number of species. These are very active predators, using their mandibles to prey on smaller organisms. They appear to be a very ancient bilateral phylum.

Arrow worms notably have bristle-like fins on the side of their body which lets them rapidly accelerate, though they do not have endurance. Many of them utilize the same toxins utilized by pufferfish in their bites. Arrow worm mandibles can likely be implemented with dedicated mandible customization. Implementing toxin capabilities to these basic mandibles should cover the rest.

• Implementing mandible customization. This would likely represent the advent of the arthropod-esque playstyle in Thrive, so it is a needed feature anyways.

• Implement basic fin customization for basal body plans. A lot of the uniqueness of the fins of arrow worms is their “cosmetic uniqueness”, so if it’s too hard to graphically represent such a feature without labor, it’ll worthwhile to skip.

Gnathostomulida - Lesser Jaw Worms (Gnathifera)

Gnathostomulida were recognized as an individual clade in the late 1960’s. They are a rather small group of organisms, and are also small in physical size. I don’t these organisms require a unique mechanism to be represented in Thrive as long as other fundamental systems are implemented. If anything can be jotted down…

• Jaw customization feature which allows organisms to “scrape” organic material off the ocean floor. There have been prior discussions about this, as this will serve as one of the first methods of gathering food available, so this should be implicit to the late-multicellular stage itself.

Rotifera - Wheel Jaws (Gnathifera)

Among the most numerous organisms on today’s Earth, Rotifera are most known for their jaws, which allow suction akin to cilia in Thrive.

Most rotifers are tiny, meaning their suction ability might not be adequately represented in Thrive at the macroscopic level if we must concede some scales of detail. As such, it might not be worth discussing this clade currently.

Brachiopoda - Asymmetrical Clams

Will not cover now; sessile gameplay and unique feature (clams)

Phoronida - Sessile Filter-Feeding Worms

Will not cover now; sessile gameplay

Bryozoa (Ento & Ectoprocta) - Colonial Filter Feeders

Will not cover; colonial gameplay probably outside scope of Thrive

Annelids - Segmented Worms on Crack

The annelids are an incredibly large and diverse group of animals known for their segmentation and relatively complex organ structures. They include leeches, earthworms, beard worms, and many other organisms. All are soft-bodied and have a complete digestive system, as well as a pair of nerves running throughout their body. They all have closed circulatory systems and features analogous to hearts.

Most annelids have setae, which are essentially tiny extensions throughout the skin of the organism. In some marine annelids, setae can look a lot like limbs, allowing benthic dwelling. For other annelids, such as the earthworms, setae are miniscule and assist with digging. Most annelids are detrivores, though some display predation and more active dietary habits.

I think annelids can largely be represented in Thrive as being the final, most complex form in the Thrivian “worm-pipeline”. Annelids have many diverse functions and forms, so allowing players creativity in customization their soft-bodied, wormlike organisms is the best way to approach this clade of organisms without killing ourselves.

It’ll be worthwhile to address annelids phylum by phylum, but here are some traits ubiquitous to most that can help distinguish annelid-like organisms from other Thrivian organisms. A lot of what distinguishes annelid phylums from other phylums are variations in the below features anyways:

• Segmentation. This will likely be a fundamental editor mechanic for soft-bodied and arthropodic organisms which distinguishes them from vertebrates.
• Setae, which can assist with burrowing or act like legs. Perhaps setae can be the simplest and first available limbs.

Polychaeta - A somewhat dubious grouping of largely marine segmented worms that are known for their distinguishable setae protrusions. Include the sandworms, bobbit worms, sea mice, and many other notable annelids.

• Because these organisms are very diverse, allowing decent setae customization is probably the best way to represent them. Some setae can be longer and have greater surface area, allowing swimming. Other setae can be shorter and can allow for crawling or burrowing. Other setae can have poison on them, and can serve as a defense mechanism.
• Several unique organisms here have features which overlap with other groups of organisms, such as jaws and burrowing.

Oligochaeta - A somewhat old-school grouping of Naididae, Aeolosomatidae, and Lumbricidae. Aeolosomatidae and Naididae are microscopic, and are outside of the scope of this document for now. Lumbricidae include 6000 species of earth-worms. This group of organisms will likely be represented in the switch to land. They depend on a mucous layer, as well as damper conditions, to remain moist.

• This group would likely be represented only when movement to land is implemented, which is in the distant future.

Hirudinea - The leeches. Implications for this group are pretty obvious, and will likely be the most defined and feasible “parasitic” niche in Thrive.

• Implementing an ability for simple jaws and proboscis to have a parasitic ability, allowing hostile resource transfer but minimizing opportunity to consume organic matter whole.

Annelids are honestly an entire beast of a clade to tackle, and will likely deserve their own post later similar to the other more complex organisms in the multicellular/aware stages. However, this provides a general overview that gives us rough ideas. I still stand by my statement that annelids represent the “pinnacle” of the Thrivian worm pipeline.

Priapulida

No.

Nematoda

Will not cover now due to microscopic scale. If nothing else, nematodes will likely serve to be microscopic food for filter-feeders and bottom-feeders.

Dicyemida

Will not cover now due to microscopic scale.

Orthonectida

Will not cover. Endo-parasitic nature likely outside of the scope of Thrive.

Kinorhyncha

Also known as mud dragons, this group of animals will likely be represented by the fundamental mechanics of the late-multicellular and aware stages. They are known to be able to burrow.

---

Look at that; in what we covered, we have addressed a great deal of metazoan diversity already! Here is a list of all features covered.

List:

• Surface-Area to Volume Ratio - This will be a very definitive feature of the early macroscopic stages, defining filter-feeding and buoyancy for organisms which do not have much morphological complexity. It will also directly feed into the metabolism of organisms, having direct influence on circulation, digestion, and respiration. Will become less important as organisms develop more advanced and thick skins, though will always have an effect. Individual discussion.
• Organ System - The fundamental feature shared by all organisms. Will most correlate to progression, and will serve as the basis of metabolism for organisms. The late-multicellular stage will represent the advent and acquisition of initial organ parts, allowing players to get familiar with the system as a whole.
• Mesoglea - Representing Cnidarians and Ctenophora, this will represent an immediate way for organisms to increase buoyancy and float, but will make it difficult to evolve advanced organ or membrane structures.
• Nematocyst/Celloblast Appendages and Customization - Representing Cnidarian and Ctenophoran appendages. Have limited control and advancement, but allow for basic grappling, filter-feeding, and stinging.
• Surface-Area/Volume Increasing Appendages - This appendages will be simple ways to increase surface area or volume, thereby increasing specific characteristics. Will be especially important in the early macroscopic stages, but less important as SA:V becomes less important. Will provide customization and flair options.
• Easy Access to Bilateral Body-Plan - This will represent the “worm” body plan, and will be the basal body plan for more complex organisms. Probably a discussion of how the editor will look in general.
• Burrowing - An important feature for more advanced playstyles. Should probably be discussed later.
• Proboscis and Customization - Probably the simplest mouth part to be offered to the player. Allows for bottom-feeding, as well as some hostile resource transfer, filter-feeding, and limited predation
• Basal Mandible/Mouth Customization - Requires its own discussion later in all likelihood.
• Basic Fin Appendages - Requires its own discussion later in all likelihood.
• Segmentation - As discussed in earlier posts, segmentation would likely be represented as an inherent part of the body plan/metaball editor. For certain organisms, players can group metaballs together to form a “segment”, which will be important for arthropods especially. Likely requires its own discussion, though mechanisms wouldn’t be that influential in soft-bodied organisms and basically non-existent in vertebrates.
• Setae And Customization - Represent more advanced limbs with diverse functions, allowing swimming, crawling, and digging.
• Bioluminescence - A notable feature of various worm-like organisms.

---

Doesn’t sound too bad when put like this, right? A lot of organisms can probably be represented with a combination of various organisms if we offer a decent amount of customization.

Images are important, but I didn’t want to spam them throughout the entire post as that could hurt readability. Here are images of various organisms.

Ctenophora

Scyphozoa (Cnidaria)

Cubozoa (Cnidaria)

Hydrozoa (Cnidaria)

Xenoturbellida (Xenacoelomorpha)

Acoelomorpha (Xenacoelomorpha)

Platyhelminthes - The Flat Worms

Nemerteans - the Ribbon/Proboscis Worms

Chaetognatha - Arrow Worms (Gnathifera)

Gnathostomulida - Lesser Jaw Worms (Gnathifera)

Polychaeta (Annelids)

Oligochaeta

Hirudinea

These organisms didn’t have a description for various reasons, but I’ll list them here still.

Brachiopoda - Asymmetrical Clams

Phoronida - Sessile Filter-Feeding Worms

Bryozoa (Ento & Ectoprocta) - Colonial Filter Feeders

Rotifera - Wheel Jaws (Gnathifera)

Priapulida

Nematods

[MirrorMonkey2]

Very evocative and sensible post. It does a good job of not making the early multicellular stage seem like an impossible thing to implement, but rather like a huge but doable task.
Since gameplay at various scales is one of the principle topics regarding the 3D stages from a graphical perspective, I wanted to ask you some more about these statements:

@Deus

Third, we should really put some thought into the various scales we will represent. There will undoubtedly be times were we will have to cut between various “scales”, such as in microscopic multicellular organisms to the macroscopic world, and omit certain niches or organisms. Where will these cuts occur?

@Deus

Most rotifers are tiny, meaning their suction ability might not be adequately represented in Thrive at the macroscopic level if we must concede some scales of detail. As such, it might not be worth discussing this clade currently.

Which scales would you have in mind when thinking about scales which can possibly be omitted? Are you mainly thinking about a jump in scale that happens immediately after the 2D-3D transition or do you think there are other gaps afterwards which you would consider?
Personally, I’m in favor of making the transitions from scale to scale as smooth as possible. But I’m aware that this will be an issue which will be determined to a large extent by the technical possibilities.
I’m inviting you all to branch out the discussion about the technical and graphical aspects of this consideration of scale into this thread: https://forum.revolutionarygamesstudio.com/t/depicting-the-3d-environment/888https://forum.revolutionarygamesstudio.com/t/depicting-the-3d-environment/888
This way we can keep the discussion in this thread more focused on the editor and organ progression.

[Deus]

This is far off still, but I put a lot of thought and effort into this (even my own handmade paint concepts!) for two reason…

1. Implementation of 3D membranes is sure to draw more attention to that topic.
2. I’m not preparing for a tidal wave, but I’m predicting a good amount of hype being generated as we begin blazing forward and wrapping up the microbe stage. If this attention grabs the attention of More people with useful skills (thinking of animation especially), it would be nice for them to have a more developed conceptual base to work with.

I think we have a solid “base” from @Buckly’s work revolving around how sculpting the organism can work, but I want to dedicate a bit more thought to limbs, graspers, and mandibles. If these areas, which are typically brushed over and towards a future time, are discussed a bit, we’ll have a solid understanding of how exactly “sculpting” will work, which is foundational to the editor and later stages as a whole. Internal organs and the such can be informed from these larger layers of detail.

A link to the post from Buckly: Macroscopic Editor, Progression, and Principles - #19 by Buckly

Which I will likely be tweaking a bit in some descriptions I have here, but the post essentially is what baseline I am thinking of currently; particularly, with the idea that there are “central metaballs” and “limb metaballs”, and potentially other branching features.

I also want to clarify that I will give extensive commentary on what should be done with metaballs which isn’t necessarily something I am advocating for in the immediate future; in other words, this isn’t me saying “we need to change the prototype into this this and this for it to be fun”, and is more me saying “this is what we will probably need to consider when we get to this stage of development”.

---

EDITOR STANDARDS AND IDEALS

The macroscopic stage is where a bunch of hype has really centered in the past, and with that, a lot of Thrive’s most ambitious and dream-like concepts focus on. There have been a lot of ideals and sentiments surrounding the editor, the most prominent being…

• A Focus on Freeform Sculpting: Similar to Spore, a central idea is that the player will be able to stretch, shrink, expand, and define the torso and limbs of the organism, and will be able to similarly manipulate graspers, pads, mouths, sensory organs, etc. This sculpting will need to accommodate a bit more than Spore did though - I think more specifically, better deal with sculpting creatures with exoskeletons.
• Parts Only When Necessary: As a reaction against Spore, Thrive is immensely wary of dealing with things by offering an immense selection of different, pre-made models which are progressive upgrades on related parts. We don’t want to place a premade lobster claw, that looks different from a premade crab claw which has stats that are a downgrade from said lobster claw; we want to place down a grasper/claw, and dynamically warp that generic, basal claw into a lobster claw. In other words, there is a premium placed on variety through customization, not necessarily on variety through various assets.

Various ideas have emerged from these two dominant ideals, and a lot of them on the community forums - as well as previous broad and generic descriptions from the development team years and years ago - of an extensive, free-form metaball sculpting tool in the editor [mind that I am not saying that anyone is explicitly stating this is the de-facto concept, it just might be something that community members might perceive due to the language we use around this topic].

But there are some problems with a very free-reign, sculpting-based editor, which we are seeing currently in the editor prototype itself (obviously unfinished and unpolished, but still useful as a tool to illustrate these points) as well as several previous concepts.

• Heavily Dependent on Artistic Capabilities - In order to make a good-looking creature, the player would need to have previous experience with sculpting programs, such as Z-Brush, Blender, and other programs. These programs are either very technical, very simple, or very expensive.
• Hard to Nail Down Exactly What You Want - Relating to the above, how can the player create exactly what they want if the tools they are given solely revolve around sculpting metaballs? If they have to use negative metaballs to carve in features like mouths, eyes, etc. how can we offer decent customization without literally giving them a sculpting program to work with?
• Impossible to Account for in Development - Furthermore, how can we possibly accommodate all possible wishes and desires on behalf of the player?
• Issues with Membrane, Skin, Texture, etc. - Sculpting programs also come with various brushes to create topology textures, which will likely be limited in a game such as Thrive.

It is just really difficult to offer robust game mechanics by just offering sculpting tools, which is why I am very wary of concepts which fully rely on metaballs. We do really need “parts” and rules related to how these parts interact with metaballs, and I do think that isn’t a “restrictive” thing at all to take away from the notoriously unambitious macroscopic stages (/s). In fact, conceptualizing part behavior can really make Thrive pop, while allowing fun gameplay and good looking creatures to emerge naturally.

What Makes a Good Editor?

Contrary to what our immediate gut feeling will tell us, a great editor does a lot of hand-holding in a way that is subtle, intuitive, and flowy enough to allow for players to actually achieve their creativity. So in creating a great macroscopic editor for Thrive, we need to think: how do we give players the tools they need to have direction, and how do we design these tools and rules to provide a good amount of customization?

As much belgium as we give it, and as much as we aim to improve upon it, Spore did a really good job at creating a player-friendly editor. It allowed casual or new players the ability to create something that they have in mind while allowing more capable and skilled players the ability to create art pieces. Some things that come to mind which we should keep in mind in Thrive…

• Clearly Defined Torso - The spinal column is the root of everything, and there is nothing which can be placed away from it. This spinal column is easily manipulatable.
• Clear Boundaries and Standard - You can obviously rotate the camera, but the creature is always oriented the same direction. There is a clear forward, and though you can make your creature face backwards with mouth placement and limb rotation, the direction of your creature’s movement was always clearly marked.
• Everything In Relation to an Axis - You could move the torso along the x and y-axis, but it was always stuck on the same point of the z-axis. This helped center the player. Limbs and other parts always related to this exact point on the z-axis. You may think to yourself “man, I wish I could make my creature wider at some points”, but you never think to yourself “man, I wish I could drag the torso sideways and personally organize all the metaballs to be going sideways”. Note that this doesn’t mean that we shouldn’t offer tools to, say, widen/flatten/round an organism.
• Clearly Defined, Yet Versatile Limb Behavior - You could place a segment of a limb and sculpt it however you want, making it a part purely for decoration; and you could make a limb, well, a limb, with a grasper or foot on it. But once you placed a foot or grasper, the limb always acted in a consistent way. Similarly, a limb without a foot/grasper always acted in a consistent way as well.
• Set Manipulation Tools Designed to be Approachable - You changed the shape of a limb by moving specific metaball joints. You changed the length of the torso by grabbing at the end of the torso and adding more metaballs. Limb metaballs snapped to other metaballs, and had to be rooted onto the torso. Several things are so on-the-rails, that they end up actually giving the player the stability needed to experiment and customize things.

Though we don’t want an exact replica of Spore’s editor mechanics for various good reasons, I think all the above guidelines are great for usability.

---

HOW THINGS CAN LOOK IN THRIVE

Assumptions I Am Making

• We can make it so that attaching a certain part designates a metaball into a specific “type” of metaball. So for example, we can make placing a grasper on a metaball extension from the torso designate said extension as a limb.
• Different designated metaballs can have different textures and graphics applied to them. For example, metaball group A will have a more natural, fleshy connection between different metaballs, while metaball group B will have sharper angles and more shaped lines between segments to give the impression of a exoskeleton

The Main Idea

In as concise a sentence as possible: placing parts will allow metaballs to be designated for specific functions.

The player will start with a slug-like torso, composed of some metaballs locked along a specific z-axis. From there, players will be able to sculpt their organism, apply different membranes, apply metaball appendages onto the torso, and put parts on the torso or the appendage to create specific structures.

By structures, I mean physiological features that we will group together. Structures are related to functional pieces of organisms, and are designated by the placing of specific parts. For example, a “mouth” is a structure designated by, well, the placement of a type of mouth part. An “arm” is a structure designated by the placement of a grasper. A “leg” is a structure designated by the placement of a foot structure.

I think this is inherently a part of Spore as well. Placing a foot on an appendage instantly roots that appendage to the floor and applies animation to it. Placing a mouth steadies a specific part of the organism, generally making the torso less flabby (which is why placing a mouth on your tail makes it much less mobile).

---

Torso

Your torso will be the default metaball status, locked to a central z-axis akin to Spore. All other parts and segments must attach to a torso. Your torso will also allow space for organs that are found within an organism’s central segment.

---

Mouth & Head

Placing a mouth on your creature turns the metaball it is placed on into the “head” metaball. Biting, eating, and other functions related to the mouth are related to that metaball. So that is where damage comes from, and where you need to orient yourself to “eat” and such.

• You can place it on the bottom or top part of the metaball, or the ends of either your rear or front, or in the center of your body. This won’t really matter to the metaball logic/functionality related to eating and directionality and such. Perhaps placement can affect stat efficiency in eating - for example, a downwards oriented mouth increases the amount of ingestible matter gotten from bottom-feeding at the cost of filter-feeding - but again, functionally, the mouth’s role is to designate a mouth metaball and orient damage and eating.
• The placement of a mouth on the posterior end of your creature does not make your creature’s posterior the front (in the editor); in other words, placing your mouth on the metaball farthest from the “forward direction” in the editor won’t flip the movement of your creature.

There will be a few basal mouths to place on your organism to represent different strategies that organisms have. The types of mouth you have available will depend on certain conditions; for example, you will not have access to a jaw if you do not have bones, or having an exoskeleton will be the condition for unlocking arthropodic mandibles. Variations on mouths will all emerge from these basal parts.

• Oral Cavity - A literal hole in your creature corresponding to a mouth. The most basal and default mouth. The first mouth to be implemented, which will cover a lot of the earliest lifeforms. Accessible to all life forms
• Suction Mouth - Jawless, corresponding to organisms such as lamprey.
• Mandible - Arthropodic, locked behind exoskeleton.
• Beak - Correspondent to molluscs and some insects.
• Jawed Mouth - Correspondent to vertebrates. Locked behind endoskeleton. Versatile vertebrate mouth allowing numerous structures correspondent to other types of mouths, such as beaks.

Presenting a very basic and artistically perfect metaball concept creature with an oral groove; the red designates a metaball designated as a head. Not so disimilar to an Arandapis, a primitive jawless fish.

Oral cavities will be available to all organisms. A suction mouth, jawed mouth, and beak will not be available to organisms with tough other layers, though they will be able to put on mandibles, which can have an immense amount of customization options.

---

Plating

This mechanic corresponds to membrane selection in the Microbe Stage, and will allow for the creation of features like shells, exoskeletons, and protective bony armor.

Organisms will be able to place hardened plates on their organism through two mechanisms - an individual plate or part, providing some protection, or by designating a certain length of metaballs (or individual metaball) as being completely incased by plating. Part placement allows for decoration and customization and will offer some limited protection. “Brushing” plating on metaball segments will provide insulation from any damage taken from said metaball segments.

I think there can be three types of plating:

• Chitinous - This will be a plating option representing arthropodic evolution. Chitin will be the only plating option that allows segmentation, allowing for greater mobility and customization options.
• Calcium Carbonate - This will be a plating option for soft-bodied organisms (maybe vertebrates if it doesn’t cause too many issues?). It will create shells akin to those of a mollusc, such as snails, squid, and cuttlefish. Calcium carbonate plating cannot be applied to the head of an organism.
• Bony Plating - This will be a plating option available for vertebrate organisms, allowing the creation of features like turtle shells. Customization options can make this more mobile, representing the armor of organisms like crocodilians, or more rigid, representing the armor of organisms like turtles.

Different stats can be applied to each version of casing, with different possibilities. All forms of casing will generally act similarly, just with different appearances and different effects on mobility and protection. But generally, bony plating will offer the least protection but be the most mobile, calcium carbonate will offer the most protection but be the least mobile, while chitinous membrane will be moderately protected and offer average protection.

In the above, light green colored metaballs indicate a regular torso, while the dark brown indicates a metaball painted with calcium carbonate. The lighter brown connections indicate parts around the metaballs which appear as shelled, while the darker green areas around the torso metaball is regular flesh.

The above demonstrates chitin’s segmentation ability - more mobility can result from more segmentation, though it can result in less protection. Note that the lines in the middle segment are just representing the ability to apply different textures to different segments. Chitinous membrane would probably require the most unique handling out of all these proposed features.

Brushing is separate from skin rigidity, which will also make a return. Rigidity when applied to plating will make said plating either more or less nimble/protective.

---

Limbs/Appendages

Players will be able to place appendages on their organism, similar but broader than the pre-defined legs in Spore’s creature stage (it could literally be placing floating metaballs if that is fine). Appendages by themselves can be utilized to increase surface area, decoration, or very simple weapons, such as stinging parts on a jellyfish.

Placing a foot, fin, grasper, claw, or tarsal claw turns that appendage into a limb, either a foot or an arm (or both depending on the part, but that’s very situational).

The above photo illustrates a fin on the left and an arthropod limb on the right with a tarsal claw; grey indicates the metaballs, green indicates the links between metaballs and decoration, and red indicates the actual parts. This is to illustrate that different types of limbs can have different looks applied to them.

• Fin
• Tarsal Claw

---

Sensory Organs

I think sensory organs should generally be parts. The placement of eyes, ears, noses, antenna, etc. can interact with the “mouth” metaball, where placing certain sensory organs closer to it enhances the sensation.

---

CONCLUDING THOUGHTS

There honestly is a lot more I could go into detail about, but I think the basic idea is present: we can have various types of metaballs, depending on pre-defined groups or the parts placed on the metaballs, and from there, structuring the editor and creating decent organisms is much more feasible for the player.

This is already long enough and I’ve worked on this for a few days - my thought train is starting to fall off the track [apologies if there are incomplete thoughts I forgot about at any points, I jumped around a lot and am quite exhausted!], so before I decide to expand on things, I want to make sure that the base of this idea seems okay to others.

Again, I don’t expect these things to occur soon; I just think this presents an easier way to deal with the macroscopic editor, for reasons listed at the beginning of this post. It would be really nice if we have concepts for what is, in my opinion, the most unique gameplay experience Thrive will provide.

And it would be nice to have actionable concepts instead of broad principles, which allow interested programmers to think “Okay, this entire thing is overwhelming but I can try to program torso behavior, or limbs, or etc.” That way, we can get to a point where the editor seems more like a large task that is a lot to deal with, but atleast we can tackle it methodically, rather than an endless wishlist of our dreams to put all of life into a game. It would personally mean a lot to me if we can get to that point, and I am sure such a feeling would reverberate throughout the community.

If nothing else, hopefully this allows us to further clarify what concepts don’t work, and spring forward from there. If these principles are solid, then I will go further into talking about how part customization and progression can actually look like.

So I would love to hear you guys’ thoughts - after I wake up.

[hhyyrylainen]

@Deus

We can make it so that attaching a certain part designates a metaball into a specific “type” of metaball. So for example, we can make placing a grasper on a metaball extension from the torso designate said extension as a limb.

I’m having a hard time picturing how this would work. How would the feature know where the limb starts? Would it try to estimate the joint position when it starts to see many metaballs next to each other? I’m seeing so many weird edgecases where ether a limb is really short or ends up controlling like half of the creature. This is why I think it is better to designate where the joint is, rather than trying to automatically detect where to place the joint.

@Deus

Different designated metaballs can have different textures and graphics applied to them. For example, metaball group A will have a more natural, fleshy connection between different metaballs, while metaball group B will have sharper angles and more shaped lines between segments to give the impression of a exoskeleton

Probably possible but needs to make the SCALIS algorithm parameters change dynamically based on which metaball is being processed.

@Deus

The player will start with a slug-like torso, composed of some metaballs locked along a specific z-axis. From there, players will be able to sculpt their organism, apply different membranes, apply metaball appendages onto the torso, and put parts on the torso or the appendage to create specific structures.

By structures, I mean physiological features that we will group together. Structures are related to functional pieces of organisms, and are designated by the placing of specific parts. For example, a “mouth” is a structure designated by, well, the placement of a type of mouth part. An “arm” is a structure designated by the placement of a grasper. A “leg” is a structure designated by the placement of a foot structure.

I think this is swinging too hard in the direction of just cloning what Spore did but with slightly more central mody shape customization. I’m much more in favour of requiring all placed parts to be really small, like just a single eye or central part of a mouth (so excluding any mandibles etc.).

@Deus

And it would be nice to have actionable concepts instead of broad principles, which allow interested programmers to think “Okay, this entire thing is overwhelming but I can try to program torso behavior, or limbs, or etc.” That way, we can get to a point where the editor seems more like a large task that is a lot to deal with, but atleast we can tackle it methodically, rather than an endless wishlist of our dreams to put all of life into a game. It would personally mean a lot to me if we can get to that point, and I am sure such a feeling would reverberate throughout the community.

I think this is “giving up” a bit too early, in my opinion. I don’t like how many things are purely just about placing the right parts, which I think causes our editor to fundamentally be just a rehash of what Spore had. Instead I think we should try to achieve the original vision of being much better editor than Spore’s without premade parts (though stuff like eyes and other small details is starting to look like it’s maybe in the end better to make those as placeable parts, but full limbs and graspers is definitely something I’d draw the line before allowing)

I say we should first get the basic metaball shape making done with good editing tools like symmetry and potential shape guides. Shape guides could work like if the player wants a limb they can place a phantom guide that then snaps the metaball placement to the recommended positions. Or maybe placing a “limb” would place just a tiny stub that the player could progress each editor cycle and the editor would automatically place new metaballs and position them. This would be kind of a hybrid approach between placing premade parts in a single editor cycle and gradually building everything manually from metaballs. After this is done and released I think then we can re-evaluate the plausibility of making limbs from metaballs. At the same time we should also investigate animation for creatures. My idea here again is that the player would designate where they want their joints so that any joint placement algorithm doesn’t do something completely silly (though I now realize that for auto-evo we either need this or much more controlled limb generation algorithm). With joints defined I think we could have a system where the player then designates that limb as what they want. Initially we’d want limb types like legs and arms (and probably decorative?). Once all of those parts are done I think then we can have this discussion fully, because at this point we don’t have all the necessary information to make any hard decisions.

[Deus]

I just have a really hard time seeing how proper structures and shapes could be made through a predominantly sculpting basis in players who do not have sculpting experience - which is probably the vast majority of the community. Though I do acknowledge that you are typically the one telling me that something is too ambitious, so me being on the side of “we should simplify things” and you saying “we can be more ambitious than that” makes me reconsider a bit.

I can atleast envision your point about limbs working I think, where a player decides an optimal length for their desires, and experiments with placing joints to see what gives them the speed, mobility, or agility needed in their use case.

Thinking about it more, I can see things working more in a more freeform editor, though we’d need a lot of guiding tools to assist players in making decent looking creatures. I’ll sit down soon and try to think of that a bit more to see if we can have actionable concepts. I know you mention that this is something that will probably be decided once we actually get to this point in development, but again, I would like for there to be something that we currently say “okay, this sounds good enough for a try.” That way, if someone on the team currently or a future applicant reads it and wishes to, they can tackle a part of the issue, perhaps reducing the awkward development time between the macroscopic and microscopic phase.

[hhyyrylainen]

I think we are talking about slightly different things. When I talk about like the freeform editing, “sculpting”, I mean just placing metaballs wherever the player wants to define the structure of their species. This isn’t full on talking about implementing a sculpting system like actual 3D editing software has.

Still I agree that it is a potential issue that placing metaballs to define a fine shape may be too difficult for the average player. But I think that making big parts is the wrong solution because that breaks the core idea that Thrive is trying to simulate evolution by only allowing the player to make gradual changes. So we avoid the unrealism of Spore where you can slap on like 4 arms in a single generation of your species.

@Deus

I know you mention that this is something that will probably be decided once we actually get to this point in development, but again, I would like for there to be something that we currently say “okay, this sounds good enough for a try.” That way, if someone on the team currently or a future applicant reads it and wishes to, they can tackle a part of the issue, perhaps reducing the awkward development time between the macroscopic and microscopic phase.

Quite a lot of future stuff is actually problematic because earlier game is either not complete or not even designed. This means that even if a later part is fully planned out, it might be impossible to fit the pieces together once the earlier part of the game is complete. It will help a lot once we have quite fleshed out all the stages so that only more depth and content is required instead of needing to work on the core systems.

In this case that doesn’t fully apply as I don’t think the way the editor is made will make it incompatible with the game, but what I think does apply is like an overall complexity / difficulty curve of the game. Depending on how complex the early multicellular editor ends up being, it might prime the players to be fine with much more complex editor than we currently think. This is because the early multicellular editor is pretty bare bones right now and not fully done.

[Deus]

Here is a more free-form interpretation of the editor.

Constants from Prior Concept

• The torso should be a central axis and the beginning part, with the organism starting as a soft-bodied slug-like mass with metabolisms inherited from the Microbe Stage.
• I still think that the “Plating” Section would be the best way to demonstrate shells, different skins, and exoskeletons.
• Symmetry on by default to make the player - the player would specify which parts are asymmetrical, or what form of symmetry they want if it isn’t bilateral.

Main Issues I See With Freeform Organisms

• A distinction between the structures of an arthropod - with more defined edges and skinnier segments to their body - and other organisms could be difficult to represent, though might be solved with handling.
• Creating very fine parts, such as fingers, jaws, etc. would still be very difficult with just metaballs. In Spore, you can see issues of creating things that are too narrow in that surfaces just blend together or animate weirdly (such as not having enough space between the limb and the torso, thereby creating what is essentially a skin flap). Even the current metaball structure does seem pretty high resolution and capable of doing that, but would it animate and move in a way that is sufficient?
• Uniting how more free-form tools operate and how stats interact could be very difficult. I’m sure there are creative solutions to some problems, but what if the player wants to create something specific but isn’t being rewarded statistically the way they think they should be? For example, the player adds what they think should be armor to their limbs, but the algorithm disagrees and wants them to create a shape that is entirely against what they have in mind?
• How would auto-evo consider all this while still creating organisms that appeal to our sense of logic? I do understand that “logic” isn’t necessarily objective and limited to Earth’s evolutionary sense, but nonetheless, the majority of players will have a very Earth-based view of what makes sense. Again: Thrive is meant to represent what we know of evolution dynamically, not discover entirely new dynamics of evolution. As such, we as developers and players won’t know when something is a legitimate evolution to a novel situation or a weird tendency that auto-evo has.

Issues We Have With Spore’s Part-Based System

• Spore’s parts are incredibly rigid, meaning that what parts are offered are essentially the only thing that is possible in the game. Sure, there might be customization of parts, but the part ultimately looks the same regardless of what arrow you pull and how much you scroll the mouse wheel. We would desperately need much greater options when it comes to shaping the structures on your organism.
• Spore overtly makes parts superior than other parts in all aspects, implying a very engineered form of evolution with there are flat goods and flat bads. This is a pretty big no-no in Thrive, as it doesn’t represent various niches well.
• There ultimately was not much variety to the metaballs offered in Spore. Organisms all generally looked like vertebrates - there were arthropod-themed parts, but limbs and the torso ultimately assumed the presence of a endoskeleton.
• The community has demonstrated that they really are interested in defining their own parts, which is something that we must consider.

Solution

In essence…

• Parts will be present, but will be extremely minimal, more like shape guides than actual pre-made assets. Players will alter the shape guide to alter their stats, and will add metaballs to configure the form of the structure from this shape guide. This will allow us to understand exactly what the player intends to do, attach stats to the part, and still allow players generally create what they wish.
• Limbs can be defined by the placement of joints. Stats will be effected by the placement/number of joints, as well as the proportions of the limb. Graspers and feet will be dealt with the same shape-guide part principle.
• Different guide shape templets will be used to allow players to create what they wish - for example, more arthropodic appendages and mandibles, etc.

Here are some examples…

Mouth

A mouth part will allow the player to direct where exactly abilities related to an organism’s mouth are, including biting and grabbing. Players will place shape guides demonstrated by the top row of the below photo, which represents a top-view outline of an arthropodic mandible shape guide. Placing a shape guide automatically indicates where an oral opening is meant to be.

Players will stretch, widen, shrink, and increase the size of this shape guide, which adjusts stats - for example, stretching a jaw will generally weaken the bite, but increase range. Then, based off this shape guide, players will utilize metaballs to define the shape of the jaw, allowing them to design their organism’s features with flexibility. The shape guide will provide some hard limits on exactly how long, big, narrow, and wide a jaw can be, but within these bounds, the player has complete control over the shape of the jaw, as demonstrated by the bottom row of the image above. And if a player isn’t confident applying metaballs themselves, the shape guides can be automatically filled, providing them a base to work off of.

Another example below, showing organisms with an endoskeleton having different structures with respective shape guidelines.

The shape outline will allow the modification of certain fine features - for example, the number, form, and diversity of teeth, which will automatically fill out the shape outline’s guide, or the addition of storage pouches on the face.

Limbs

Limbs will be defined by the placement of a metaball extension from the torso. The player will then be able to define the motion of a joint (ball-joint vs. directional vs. general flexibility) The below concept indicates the treatment of an extension before and after the placement of a joint, going from a more decorative and flowy appendage to something that more resembles a fin.

The proportions and placement of joints will dictate player stats, as well as the thickness between each joint. Here is a reference to a website looking at biomechanical differences, and a concept below indicating a sprawling vs. vertical gait: GEOL431 - Vertebrate Paleobiology

Note that the placement of a “joint” doesn’t indicate the presence of a skeleton - i.e, placing a joint on a soft-bodied extension can result in a mollusc-esque tentacle. Though joints will behave differently depending on the characteristics of an organism. For example, an organism with an exoskeleton will generally have skinnier joints that cost a bit less to produce and have different stats/proportions when compared to organisms with an endoskeleton.

Placing a joint on a torso indicates the presence of a motile element. For example, placing a joint on an extension of the posterior body for an underwater organism will indicate a tail used for propulsion, and directing the tail will determine whether the organism flaps its tail vertically or horizontally to propel itself.

Graspers will work similar to mouth parts, with a shape guide utilized to define stats and general characteristics. I will go into them in more detail in a future point if this concept sounds okay.

Lingering Questions

Looking over this doesn’t seem so bad, though obviously we’ll have to see what the person programming and animating things says. I think we can make this functional, though two questions exist.

• Exoskeletons - Exoskeletons have a distinct carved look to them. How well can the player represent this, and can we offer tools to create this effect for the player to design themselves? Or will the presence of an exoskeleton change the behavior and graphics applied to a metaball?

Auto-Evo - How will auto-evo meaningfully create organisms that seem logically appealing and aren’t just blobs with a mouth attached to it? If we apply dynamic stats to the shape guides and the shape of the torso, perhaps auto-evo can have some direction if it automatically fills in the shape guide. But how do we ensure that organisms visually don’t look bland and repetitive if they do fill in shape guides? How will it know when to evolve decorative curves, structures, and other dedicated structures without the presence of defined parts?

[hhyyrylainen]

@Deus

But how do we ensure that organisms visually don’t look bland and repetitive if they do fill in shape guides?

I think the shape guides maybe need to be optional. I foresee that being very hard to do with auto-evo but, if the player is also required to use shape guides for functional parts, we are in effect requiring this visual similarity rule to player creations as well.

@Deus

Creating very fine parts, such as fingers, jaws, etc. would still be very difficult with just metaballs. In Spore, you can see issues of creating things that are too narrow in that surfaces just blend together or animate weirdly (such as not having enough space between the limb and the torso, thereby creating what is essentially a skin flap). Even the current metaball structure does seem pretty high resolution and capable of doing that, but would it animate and move in a way that is sufficient?

I feel like this is not going to be much of a problem. Thanks to the metaball structure we’ll know exactly what is part of an arm for example thanks to setting the joint on a metaball that it rotates around. If visually the metaballs don’t cause the arm to blend into the body skin, animating the skin with bone skinning weights applied to the vertices just on the arm should be fine. The harder part with animations is generating the actual animation motions in a way that they look good, and try to avoid intersecting other parts of the body when animating an action.

[Deus]

I haven’t had much downtime to sit down and create a concept on an extremely focused topic, but I’ve been jotting down some thoughts on a potential breakdown of function for our macroscopic editor in the meantime. This can hopefully allow anyone with the skills and desire to contribute to a specific part of the editor functionality rather than content with the entire monolith that would be our macroscopic editor.

The following post describes the basic fundamental mechanics that will likely be present in editing limbs and torsos. Part editing isn’t currently discussed with the same sort of formality because concepts there are ambiguous - but we can reasonably assume several fundamental characteristics of editing torsos and appendages.

Torso

Fundamentals/Ease of Access

1. Should be locked along an X axis, not moving in the Z direction (side-to-side).
   a. Ensures that a frame of reference is maintained, making sure the player doesn’t misjudge their organism’s positioning. Similar to Spore.

2. Should be symmetrical by default.
   a. Some form of axis should be granted. Bilateral is needed; additional planes of symmetries are appreciated but aren’t necessary as a base.

3. Should be able to add metaballs along X axis, and have each metaball be related/connected to the other.
   a. Allows the presence of a continuous center/mass.

4. Some sort of Undo function.
   a. Quickly allows reverting changes the player didn’t intend or doesn’t like.

---

Customization

1. Frontward and backward extension of the torso allowed by the addition of more linked metaballs.
   a. Allows for increasing and decreasing the length of your organism.

2. Scaling of a metaball’s size to make part of the torso larger.
   a. Allows variability in mass/structure of torso.

3. Allowing for independent scaling/lengthening in the X and Y axis.
   a. Allows for a flattening or widening of a certain area of the torso in a specific section, allowing for the creation of tails, organisms similar to flounders, greater customization, etc. This should probably be behind a specific key rather than a default function; in other words, scaling will default.

4. Ability to move metaballs to create different alignments of torso.
   a. Sort of like dragging the torso in Spore, which allows for the torso to be shaped in a way that is desired.

5. Toggleable ability to very finely adjust scale or movement of a metaball.
   a. Kind of like a “finetune” button, which slows down the mouse so that very precise movements are easier.

Appendages/Extensions

Fundamentals/Ease of Access

1. Metaballs can be placed on the torso, and can be moved around alongside the torso.
   a. This opens up the capability of placing down limbs, as well as decorative metaballs if we desire to implement them.

2. You can move your mouse to a point on the metaball segment to add another joint/metaball.
   a. This will allow for the creation of joints, and will allow for further decorative control over decorative metaballs.

3. Removing a metaball can be done by dragging it off the torso. Dragging a metaball that is not attached to the torso but is instead a segment removes only the child metaballs/segments (the metaballs further down the appendage).
   a. Allows for removing metaballs easily from an established limb. Also allows for removing one segment of a metaball without getting rid of the entire appendage/limb.

---

Customization

1. Ability to drag limb metaballs to create different configurations.
   a. Essentially like a move tool in Spore, allowing different orientations of limbs and metaball appendages.

2. Ability to scale metaballs.
   a. Allows for creating differences in the size of joints and segments.

3. Ability for independent scaling/lengthening in X and Y axis.
   a. Allows for flattened appendages.

---

Future Considerations

This is for features that aren’t fully conceptualized or configured, but I foresee as being potentially needed eventually based on prior conversations. So they aren’t necessary or finalized for any sort of implementation, but are important to bring up incase anyone has some ideas, or incase the underlying software needs to be adjusted to allow for these future possibilities.

• We would probably need an approachable mechanism that allows players to customize the appearance of their organism’s skin. A “brushing” mechanic directly akin to sculpting programs is probably too detailed to serve as the basis of this mechanic (though it may be useful as an additional customization tool), but a basic way to create different layers of a coat, scale texture, skin, etc. with the ability to color these layers differently has obvious uses.
• The type of skeleton an organism has - hydrostatic/soft-bodied, exoskeleton, endoskeleton - has an impact on the way limbs and torsos look. For example, organisms with exoskeletons generally appear more streamlined and sharp, while soft-bodied organisms can look very loose and floppy. So I can foresee needing to have some way to tell the editor, “hey, this is an exoskeleton torso, so apply these different rules in how segments align/scale/are manipulated which make the body look more solid”. In other words, an ability for us to apply different cosmetic appearance rules depending on the choices of the player.
• A prior concept I had deals with “shells” and other hard-bodied coverings/platings by treating it similar to a texturing/brushing mechanic, where players designate segments of their torso to have the shell texture/behavior be applied to. The concept isn’t legitimate at this point, but it might be how we deal with such cases in the future.

Keep in mind that “soft-bodied” in the second bullet-point is in reference to organisms without a skeleton, not necessarily any sort of soft-bodied physics that would be applied to the organism. Soft-bodied physics would obviously make the game look much better, but considering their immense challenge of implementation under current Godot, they aren’t necessary; what is necessary is some sort of organism body plan which doesn’t have a skeleton.

[Deus]

Freeform Function, Parameterized Structure

Concerns with Metaball Sculpting

A lot of developers have expressed their concerns with a metaball brush/sculpting editor. I discussed some concerns above and am not fully able to articulate the perspective of others, but the essence of some concerns involve…

• Auto-Evo having very little go off in creating optimal organisms. If our primary sculpting tools are essentially placing metaballs to create shapes, how could auto-evo possibly be tasked to create capable organisms? @Thim and @GameDungeon express strong doubts here, with GameDungeon calling it impractical.
• Even beyond Auto-Evo creating “functional” organisms, how could we trust it to create organisms which are visually appealing? Spore’s Creature Stage, which was a lot less procedural than we intend to be and more on-rails, already can result in some wacky-looking creatures - how would Auto-Evo be able to create organisms which aren’t globs or lines with odd protrusions and a misfigured mouth slapped somewhere?
• Concerns for gameplay. Even if we have tools like shape guides and phantom limbs and the such, sculpting via adding metaballs is a really intensive process, requiring a lot of finetuning, detail work, and precision (especially in mouths, limbs, graspers, and more intricate parts). Many minutes would be spent trying to make something look decent or the way you want it, which can take away from the more plus-minus, mechanic driven gameplay we would be offering.
• Progression becomes really hard to pace. Evolution was obviously a very iterative process, but it had no foresight, and as such, was largely limited to what was possible in the moment. Players on the other hand know what a functional mouth, limb, grasper, or other structure looks like and might gun towards creating such structures, in turn skipping eons of evolutionary history.
• Conceptually, it’s just really difficult to understand what is possible and anticipate player decisions if the editor is metaball-creation heavy. Dynamism and a degree of unpredictability is always beneficial to emergent gameplay, but this goes beyond that and more into a question mark of how multiple complex body plans could possibly be represented.
• Issues with player approachability and optimization. We can offer some shape guides, but if their creation isn’t behaving the way it should in some capacity - perhaps it’s too slow, not light enough, not strong enough, etc. - having tools be very free-form results in a lot of confusion. How might a player with no idea on what makes a good wing a good wing be able to alter their limb structure? We would likely have to loosen up our evaluation of different functions, which results in a loss of depth and realism.

---

What Exactly is “Free-Form”?

A major ethos of the macroscopic editor is the ambition to be “free-form”. That’s a very broad and undefined ambition of course, so we tend to default to the idea of free-form translating into morphing your organism into whatever you want, with as little restriction as possible placed on you.

That isn’t a bad thing at all to place a heavy emphasis on - but by naming this as our ultimate goal, are we thinking incorrectly about how to make the macroscopic stage editor be as innovative and as engaging as possible? That sounds weird to say, but I’m going to use a favorite and recurring example of mine to present a point: Kerbal Space Program.

KSP is lauded as having among the best editor-based gameplay in the industry, praised for its depth, polish, and room for creativity. However, if you look at the editor itself, a lot of the mechanics related to player control aren’t very freeform. You place pre-defined parts from a solid, but not at all extensive catalog of items, which have seemingly limited customization options (no length/width, sliders, or extensive details on most, if not all, parts). These parts generally snap on in a rigid manner to certain positions on an aircraft. And a lot of missions generally involve relatively simple controls and abilities, often accomplished by getting to a zone and clicking buttons at the right time.

What makes the editor phenomenal in KSP is how dynamic and freeform stats and “functions” can be. By emphasizing dynamic stats such as center of gravity, aerodynamics, structural integrity, and mass, and by deeply connecting editor functions and tools to these mechanics, a relatively simple toolkit turns into an incredibly engaging experience - iteratively improving your craft into whatever function you attach to it. Certain purposes benefit more from certain tools - a weaker rocket probably won’t get you into space, but it’ll offer you a level of control that a gas-guzzling, atmosphere-exiting column won’t.

Had KSP focused more on a much more free-form editor - perhaps, drawing and designing your aircraft’s body and wings, focusing more on allowing the player to create a ship that visually looks the way they want - I think KSP would have suffered a bit in the depth of its editor gameplay. Having defined units, structures, and mechanics gave them a backbone to attach really fun and engaging mechanics to. Having those base parts allows newer players with very little concept of space travel and aerodynamics the ability to get something functional and somewhat decent-looking up in a air; simultaneously, the depth of the mechanics allows players who know what they are doing to really get down to the nuts and bolts of things, creating beautiful ships and efficient spacecrafts. Had they focused instead on having a very complex and free-form editor, I’m sure the developers of KSP would have struggled to create this level of interaction and detail.

Now, this isn’t me saying that Kerbal Space Program’s editor design is a 1-to-1 example of what would be the best for Thrive. We represent a much more iterative process, while KSP is focused more on technological jumps; I don’t think Thrive should focus on having a catalog of parts similar to, or to the extent of, KSP; KSP’s editor represents mechanical creations, Thrive biological; and KSP has a much more intricate and involved physics system than Thrive should.

But I do think there are things to learn from KSP’s approach.

---

FREE-FORM “STRUCTURE” vs. FREE-FORM “FUNCTION”

I think of our current approach to the editor as being very free-form in structure - being able to create what you want, and having this creation be rated. In this interpretation:

• The player is able to create whatever they want, with as little limitation as possible. They can create graspers, mouths, limbs, and torsos which look as close to what they envision as is possible.
• The challenge placed on the player will likely involve creating ideal shaped tools to tackle their environment. Physically sharpening, widening, lengthening features alters stats, and finding new ways to create this effect is the crux of player innovation.

On the other hand, I think something like KSP emphasizes free-form “function” - having defined tools to deal with open-ended and complex constraints. In this interpretation:

• Players are given tools and pre-made assets with limitations and rules. Tools themselves have pre-defined stats, but their use and application is diverse.
• The challenge placed on the player involves using those tools to solve constraints which aren’t necessarily linear. The “stat” associated with the tool is often secondary; the composition of the whole, and applied circumstances are much more important to performance.

Free-form Structure Doesn’t Solve Spore’s Issues: The Nature of a “Part”

Spore’s Creature Stage editor, though a technical marvel, presents a gameplay experience which serves as the opposite of what Thrive attempts to be. With linear stats and tiered parts, players reflect traditional leveling-up progression rather than evolution itself. Appropriate and fun for the game that it is, but not for our own ambitions.

We’ve obviously taken a look at Spore and decided to go in a different direction: which, for a lot of our development history, involved dismissing defined parts and structure, opening up an organism’s structure to the player’s mind. A lot of our community has also associated this part component of Spore’s editor as being a vice.

KSP, however, presents a direct counterargument to this perspective. Here, we have what is likely the industry’s benchmark of what a well-done editor in a simulation-focused game looks like - and the entire editor is based on parts. They are parts with defined stats and tiers, like the Creature Editor of Spore: however, KSP manages to take those parts and apply them in an incredibly engaging way.

Why is that? The biggest reason: emergent complexity through influential constraints, and orienting tools towards solving those constraints.

By and large, KSP’s challenge focuses around dealing with the constraints of your ship’s composition as a whole rather than problems of stats. You can slap a more powerful rocket on your cardboard box ship pretty easily or add more fuel if necessary, but those rockets weigh a ton, which affects your ship’s integrity and profile. Similarly, a ship with a weaker rocket, but much better structural integrity, would have a much better time getting to space.

HyperbolicHadron brought up this point as well: Spore’s mechanics aren’t designed to host this sort of approach to editing. You place better graspers on your limbs, and your strike stat goes up: that’s it, you’re better at damaging other organisms. The only decision you had to make is forgoing some social stats, but beyond that, you didn’t have to think about your composition and body plan at all; you just placed down a part.

Solving problems in Spore involves waiting to unlock a specific, more advanced part, and placing down that part. KSP’s approach to problem-solving goes beyond the stats of your parts, and into the integrity of your creation as a whole.

That is essentially the flaw of Spore. It isn’t the mere presence of parts: it’s the fact that the underlying mechanics of those parts are so shallow. With everything else being constant, Spore’s issues wouldn’t have been solved if metaball sculpting and creating your own parts took a bigger emphasis.

Spore shows how parts can stifle editor-heavy game design:

• Stats brought by parts are king, and the immediate concern.
• The type of part you have is entirely consequential for success.
• Limited decision-making outside of what part to place.
• Limited general constraints, outside an abstract “complexity meter”.
• Heavily stylized, limiting creativity outside of immediate options.

KSP shows how parts can enhance editor-heavy game design:

• Battling constraints are king, and parts don’t immediately answer those constraints.
• Part choice is important depending on circumstance, but constraints are universal.
• Decisionmaking related to parts is straightforward, decisionmaking on composition and organization of parts is majority of challenge.
• Accessible way to tackle incredibly engaging and complex constraints.
• Solid ability to create aesthetically-pleasing crafts, with a smart selection of parts to provide the ability to recreate real crafts.

To sum it up: if done well, providing standardized tools in the manner of “parts” is not an inherent limit to creativity or ingenuity at all. In fact, if well thought out and optimized, having parts with a purposeful focus on larger editor design questions - those holistic stats which go beyond the sum of your parts - results in incredibly emergent and creative gameplay.

And, to clarify: metaball sculpting is not entirely exclusive of this ability to create meaningful decisionmaking. It’s just much, much, much harder for a game like Thrive or KSP, for many of the reasons I previously mentioned above. And it makes it much harder to focus on ensuring the constraints a player faces are challenging enough.

---

WHAT THIS COULD MEAN FOR THRIVE

We’ve established that standardization via parts isn’t an inherent vice to good game design. What ultimately does this mean to how we approach the design of Thrive’s macroscopic editor?

First, some immediate benefit of allowing parts, and general structural rules, to be involved in the macroscopic editor:

• Easier for Auto-Evo to track. Auto-Evo would have something more established to go off of in determining fitness. Having this ease of access allows for more complex and emergent mechanics to be present in Auto-Evo, such as parts with multiple uses. It also makes it a bit easier for Auto-Evo’s creations to look somewhat decent.
• Less complicated development. As @HyperbolicHadron puts, parametrized parts can start off simple, then more easily evolve into something complex. Metaball sculpting would inherently start off with a lot of complexity, and would require an intensive effort upfront to get it to be usable for many dependent mechanics.
• Easier for design. Having parameterized parts allows for some standard units of design and progression, which makes designing things more straightforward. This being easier opens up room for more intricate mechanics.
• Easier for the player. Metaball sculpting, even if assisted and guiding, is a really intensive process.

Second, some commentary on why KSP isn’t an apples-to-apples comparison:

• Thrive would need more sliders, and probably less parts. A big part of evolution is small tweaks to previously existing structures. Whereas engineering, and thus, KSP, involves replacing parts and units, Thrive should involve more tweaking options to what should generally be a smaller catalogue of parts. Note that a smaller catalogue of parts - especially if those parts are able to be manipulated, and are selected to represent a good amount of options - still provides a great amount of customization.
• Placement of metaballs does have a place in Thrive. Appendages and limbs in particular, as well as some customization of the torso for shaping. But we’d need to offer some structure to these tools to easily parametrize them.
• Thrive requires more abilities than KSP. Thrive involves reacting to other threats in your environment, while KSP focuses more on dealing with your environment.

With that established, what are some implications for Thrive’s macroscopic stage editor?

• Dynamic constraints, beyond stats, should be king. Great editor gameplay involves solving problems which do not have an immediate parameter-based solution. We should probably offer physiological challenges which real biological entities have to solve, and orient many of our editor tools towards affecting those stats, as KSP does. And those constraints should be complex, in that one “end” of that constraint isn’t necessarily bad - just as a high center of gravity in KSP is useful and detrimental in circumstance, high mass in Thrive is useful and detrimental in circumstance.
• Parts can be good! We need to seriously consider our selection, however. As was established, parts can be a great way of offering robust gameplay experiences, and aren’t inherently flawed. However, we would need to put serious thought in offering a selection of parts which adequately presents life’s diversity without implementing hundreds of different structures, and set up sliders to allow for the majority of diversity in parts.
• Holistic composition presents most of the challenge, not individual parts. Better adapted mouths or teeth are seriously beneficial, but strapping a bone-crushing bite to a feeble body will make any fish top-heavy and slow. Players should face the implications of their decisions in the editor, and must ensure their body plan as a whole is well-designed.

SOME PROPOSALS

• Define constraints players will have to keep in mind, and have those constraints have a strong impact on gameplay. These constraints should generally be related to ensure we aren’t tasking the player to keep track of 50 different things. (aerodynamics, center of mass, weight all being related in KSP as an example). I’m thinking of Mass, Surface Area, and the Square Cube Law most immediately.
• Define general rules for how the big constraints will work. For example, mass/SA:V/Square Cube Law increasing with x action, decreasing with y action.
• Define stats which aren’t necessarily constraints. Agility, speed, HP, defense, etc. Have these stats be heavily influenced by our general constraints.
• For aquatic gameplay, have a simple representation of biofluid dynamics. It by no means has to be as advanced as the physics simulation system of KSP - I think having turn speed, top speed, and ease of ability to sink or rise up in the water column and tying those stats to our constraints will result in spectacular gameplay.
• Define the impact of different structures on those constraints. A longer, skinnier spine results in higher surface area compared to volume, a stockier, shorter spine resulting in less surface area compared to volume and higher mass, etc. Apply this thinking to limbs as well, which, combined with your torso, defines the “base” of your body plan.
• Define tools and parts with a direct relation to these constraints - appendages for the purpose of improving surface area as an example, such as those on early soft-bodied organisms. Then, design other tools which have a more direct impact on the non-constraint stats, and have those “stat-tools” be more or less influential depending on the constraints and circumstances of a build.
• Design future concepts - such as those for plating/skin, combat, etc. - with those constraints in mind.

---

Thrive’s editor, and gameplay as a whole in the macroscopic stage, can really be a delight if we look at examples provided from us in the industry. It can be really rewarding - wow, I finally got this high mass organism to float! It can be really challenging - my high surface-area organism is too flimsy, and I keep getting torn apart by my predators. It can be really funny - this thing’s head is too big, it keeps sinking!

That is the benefit of really good editor mechanics. Even if there is a challenge, that challenge creates great experiences. Just look at an average YouTube video of KSP: a great mixture of joy in seeing your craft succeed, comedy in seeing something whacky happen, and occasional frustration in seeing your mission fall apart. Because the editor is so well made, players accept even frustration - even though the mechanics can be difficult, players perceive them as well designed, and trust the game to reward actual engagement with the core mechanics of its editor.

---

As a bonus, here are some recreations of vehicles in KSP’s editor, using standard and generic parts offered in the editor:

An SR-71:

Apollo Saturn V:

Orion Mission:

F-22:

[HyperbolicHadron]

I think bringing up KSP is a very good comparison. I think all of the points you made create a good case for why having more premade parts could still work well with Thrive if we are able to create more compelling dynamic gameplay using them.

However, I don’t think we will need to have too many premade parts if we are able to design a good parametric parts system. KSP has a lot of premade parts, but I think this might be partially because it was simpler to create the game that way in the beginning when it was barely more than a tech demo and since then has stuck with it. A more modern, designed from scratch equivalent would be Juno: New Origins (Renamed Simple rockets 2) which has a far greater focus on parametric parts. Even KSP2, which had perhaps too great a focus on being simple and accessible from the start, was also going to have more parameterized parts as well ; so it isn’t just KSP’s style or simplicity making it focus on premade parts. (Though I think it was mostly just parametric wings if I remember right. It was a pretty neat system anyways.)

@Deus

For aquatic gameplay, have a simple representation of biofluid dynamics. It by no means has to be as advanced as the physics simulation system of KSP - I think having turn speed, top speed, and ease of ability to sink or rise up in the water column and tying those stats to our constraints will result in spectacular gameplay.

While I don’t think we would have anywhere near as detailed of a physics simulation during gameplay as KSP does, I think that we can have a detailed physics ‘assessment’ phase to evaluate the properties of an organism in the editor. We will have to figure out a lot of similar stats as KSP does. The Hydrodynamics of an organism in water, Aerodynamics of an organism in air, center of gravity of creature, etc. If we need to use a complex aerodynamics simulation in order to properly evaluate effectiveness of a creatures wing, or how nimble it should be able to move in the air then this would only need to be simulated once in the editor, then those results could be used by the animation system and organism statistics out in the world. Though a more expensive aerodynamics system could slow down auto-evo if it needs to run it many times, it should still be easier than having to optimize for a dynamic system when in the world. Also, auto-evo might be able to make more accurate guesses about how a change would affect the properties of an organism with a parameterized system, like increasing the size of a limb that is a wing will likely help it glide more effectively, without having to re-run the full physics simulation each time it makes a change.

Another note is that a fully free-form editor might be able to work ok for the player when designing a full creature from scratch, able to edit as much as wanted to get the final result they want. But normally the player won’t be making large changes; as an example when creating an arm they would only make small additions and tweaks over time, adding a joint one session, tweaking the length another session.

I think that having to design a 3D organism by incrementally sculpting it could be very difficult and frustrating, much more than sculpting it all at once. You would have to retain the vision and precision of your sculpting abilities over the course of many generations, and if you change the idea you have for what you want your creature to be, it will take a lot of effort to change it.

Think of evolving a fin from a hand: in the entirely free-form editing, you would have to add in metaballs or some similarly detailed change in order to join the digits together, which would likely require a lot of precision to do, and could end up being annoying if you have to do it multiple times over a couple of editor sessions. Whereas with a parameterized limb you would be able to change the ‘webbing’ parameter to gain a bit more webbing on the hand and this change could be repeated and tuned over multiple editing sessions instead of having to manually place down new metaballs or adjust each individual metaballs’ stats to get webbing to be added correctly. This ‘webbing’ parameter could be used from things as varied as fin webbing to bat-like wing webbing.

I think that the small incremental changes that the player will be doing should be fantastic for a parametric editor UI as well by being able to start with a small list of options, and growing over time as more changes are unlocked. For example, when starting off with a mouth part, it might just start out as a simple hole in the creature, and you would only have the option to change its size and perhaps the opening shape some. The player should get used to the editor starting with simple options, then as the player becomes more experienced as the game progresses, they also unlock more complex parameters to change.

If you do jump in the deep end and start off in the 3D organism Editor (perhaps you start a save in aware stage) then you might run into an issue of being hit by a massive wall of parameters if we can’t make the editor intuitive enough. However in that case we would be able to easily create preset ‘parts’ to use in the editor by just setting the parameters to different standard configurations. Like making a ‘fin’ preset, or ‘arm with hand’ preset. But these would only be used when creating an organism from scratch, without prior history.

We might even be able to take a newly created organism by the player, and ‘reverse-generate’ it’s history by extrapolating from the current parameters backwards in complexity. It wouldn’t be as detailed or have as many changes as a real history made by players, but it could be an interesting solution to dealing with later stage save starts. This would also potentially allow for auto-Evo to make fake ‘last common ancestors’ of your organism and auto-evo organisms, and use devolved versions of your organism to generate different organisms to populate the world as if auto-evo was able to evolve from the players organism as it was created. This could be especially useful in Space stage as you could create different sapient creatures for different space civilizations, and then create related devolved organisms to make a realistic history for their world’s organisms. (This could be be done as-needed, if the player never visits or observes a different civilizations organisms and only interacts with the sapient organisms, then it would not need to spend time generating a wide range of unnecessary organisms)

It would also potentially open up an ability to create a life-cycle system automatically, where juvenile organisms are less developed in certain ways, such as the complex life cycle of a crab or insect. This could be done without the player having to entirely model a new organism for each life cycle stage, generated semi-automatically by varying the parameters. I think that a life-cycle system is probably nearer to the end of the roadmap if we do it, but it is worth considering. And a simple version of it could be used for a more moderate change for juvenile organisms earlier in development.

@hhyyrylainen

I think the shape guides maybe need to be optional. I foresee that being very hard to do with auto-evo but, if the player is also required to use shape guides for functional parts, we are in effect requiring this visual similarity rule to player creations as well.

I also want to clarify something: the reason that auto-evo is able to reason about how to evolve upon the player’s organism is because the parameterized part system is the same for the player and auto-evo’s creation abilities. I think of it less that a parameterized system would limit the player’s design freedom, but instead it would give auto-evo as much freedom as it possibly can in its ability to modify the player’s design. As more abilities and design freedom are added into the parameterized parts system over time those improvements would be able to be used by both auto-evo and the player, improving both the 3D organism design experience as well as auto-evo generated/modified organisms.

Notice how Juno:New Origins is able to create very realistic looking matches of real world rockets with its parametric parts system, where KSP would require more effort to do so with its stock parts and look not as similar. Now, they likely did have to work to get the parametric parts to be able to match real-life rockets as well as entirely novel ones, but I am sure we could do the same for our parts as well to match real-life organism configurations.

Also, this is a neat video showing someone creating a 30 second, 5 minute, and 30 minute rocket, showing a parametric parts system working on different timelimits in the editor. (Though again, the best equivalent for one editor session in Thrive would not be an initial session designing a whole rocket in KSP or Juno, but would the the subsequent rocket tweaks changing the design in later sessions)

Building Rockets In 30 Seconds to 30 Mins In Juno: New Origins...!

I do have more to say about the specific design of parametric parts, but I wanted to respond to the overall idea first as it is currently framed by Deus.

[HyperbolicHadron]

I will give some examples of how some parts would be defined using a parametric parts system in more detail. But first, I thought it would be good to distinguish between three different kinds of parameterized part:

Parametric Part Types:

Pre-Made Parametric Parts:

These are parts that are 3D modeled by our graphics team, and will be morphed between different versions of the parts depending on the parameter configuration. This is ideal for parts that are unable to be constructed using metaballs, either because of geometry problems or because of how detailed the parts need to be.

Procedurally Generated Parametric Parts:

These parts are generated completely from scratch by the parts system. They could be thought of as computer assisted generation of the parts, as they would be visibly similar to a construction done manually by directly placing metaballs with a free-form sculpting system. The generation of these parts will typically be done using the metaball system but some parts may benefit from other systems to generate their features, such as L-Systems for feather or leaf generation for example.

Hybrid Parametric Parts:

Many parts will be able to incorporate pre-made assets into the core procedurally generated part. For example: teeth or claws could be pre-made elements that are applied to the metaball based surface of the part. This results in hybrid parts, created from both procedural and pre-made assets.

Part Complexity Comparison:

Simple parts are those parts that do not have a large amount of customization options, and as such should be simpler to design, evaluate, and use. These are the only type of parts that will be pre-made parametric, though many simple parts could also have some elements of procedural generation as well. This category will contain most of the parts with a more typical upgrade path, though even they will still have tradeoffs.

Medium parts will have a lot of configuration options and tradeoffs to consider, but most of its configuration will be localized to the part itself. These parts will be Hybrid parametric.

Difficult parts will not only have a large amount of configuration options, but these parts will also affect neighboring parts. This will create a much more difficult parametric system that interacts with other parts, and players will need to take into account any cascading affects that result from modifying these parts. These parts will be Hybrid parametric as well.

I will go over some examples of these different part categories here:

Simple Parts: Eye

The eye is a simpler part to design, as it seems to have a fairly simple progression with a couple of extra paths. It is also more of an “increasing complexity is pretty much always an upgrade” kind of part. A more developed eye is nearly always better than a simple one if you have the brain power to use it. (This is as opposed to something like a limb, where a hand is not necessarily an upgrade compared to a fin. An organism might even change back to a fin like cetaceans did.) Most of the player’s decision making with these parts comes with developing the prerequisites for effective use (brain/neuron count) and the alternate paths or minor adaptions that can be taken for the eye. Eye placement is also a good idea for functional differences, though figuring out how to translate that to in-game visual ability could be more difficult to figure out.

The standard eye progression goes like this for typical vertebrate eyes:

Alternate paths include compound eyes:

Some modifications to eyes would include different pupil slits, code/rod density, color vision, size of eye, or even telescopic eyes like jumping spiders have.

Medium Parts: Limbs

These are perhaps the most important part to focus on, and is responsible for a large part of the design of an organism. Limbs can develop over time and get more complex, but more complex limb features are not always an upgrade. Instead, almost all limb modifications are a tradeoff of various different goals.

Construction of a limb would involve:

• Adding joints
• Changing lengths of limb segments
• Duplicating or removing digits (like fingers)
• Increasing or decreasing webbing between segments
  • Internal-Webbing between digits, like fin webbing
  • External-Webbing from limb to body or other limb, like bat or flying squirrel wings
• Changing digit endings, adding or adjusting claws or nails

These and more adjustments would be internally represented as parameters, and a user friendly version of these parameters would be made available in the 3D editor. Some parameters will be affected by the adjustment of others, like much more powerful muscles might result in a joint having a smaller range of motion.

Limbs can be used as fins, wings, legs, and arms. Limbs would not be fixed to a specific use, but instead evaluated dynamically for how well it functions at each task. How good it would be when used as a fin would depend of surface area of the limb, how well it would be for support as a leg would depend on the range of motion of the joints to be able to plant the limbs on the ground as well as their strength at lifting the organism, how well it could be able to grasp/manipulate an object would depend on its digits flexibility and range of motion, how well it would function as a wing would be similar to the fin calculations but using aerodynamics instead of hydrodynamics.

For example, a human arm also works a ‘fin’ when in the water, it just isn’t adapted to be particularly good at that task, and useless as a wing (Except maybe on a planet with extremely low gravity and thick atmosphere?).

We could have some possibilities for great emergent gameplay here: imagine the case of the flying fish. If the player has incidentally designed their creature in a somewhat aerodynamic way and they try to jump out of the water to escape a predator, they might discover that their organism can glide for a surprisingly long distance. They might then decide to intentionally adapt their creature to being more focused on its gliding ability. Or perhaps the player never realized the latent potential in their design, but auto-evo does and splits off the player’s organism to a more flying-fish like organism by adjusting its fins. Specifically, this could be done by adjusting some of the limb’s size attributes that correspond to increasing the surface area of the fin or rotating the fin to be more useful in a glide. Auto-evo would be able to select the correct fin to modify by checking which limb(s) contribute most to its aerodynamic lift by checking the surface area and orientation.

If we did not use a parameterized limb system, how would auto-evo know how to modify the organism’s fin to increase lift? I can imagine auto-evo being able to determine that the organism is currently decent at gliding, but how would it determine where to place metaballs or which ones to modify and then how to modify them if it was using a completely free sculpting system? Perhaps we could figure out a solution for a free sculpting system for limbs with enough effort, but then we would be left with an even more difficult area to figure out—Mouths.

Difficult Parts: Mouths

The mouth is particularly difficult because it is tightly integrated into the head of a creature, and an articulated jaw can change the shape of neighboring surfaces on the face quite a lot.

Simple mouths could likely be made fairly easily, just being mostly a hole. Later on it could have some control over opening and closing, and eventually teeth would need to be added as a possibility. After that point though, it gets more difficult to reason about, as jaws get involved, face muscles are tightly integrated with the mouth, and more. This will be difficult enough to figure out how to parameterize this system, trying to figure out how to evaluate and design this as a completely free sculpting system seems near insurmountable.

Some aspects of customization would include:

• Mouth shape
  • Aspect Ratio
  • Length
• Internal symmetry
  • Radial- Most basic, a lamprey mouth for example
  • Mirrored- Has two planes where teeth can be attached
• Tooth Parameters
  • Count
  • Size
  • Material Type
  • Shape (Useful for defining herbivore vs carnivore teeth, or more advanced options)

These parameters would adjust the placement and generation of metaballs for the mouth shape as well as placing individual features such as teeth. While inverse metaball placement could be used to create a simple open mouth hole, a more complex closed mouth would likely involve some other method to create the mouth opening. You can imagine the mouth of a crocodile for example being essentially a bisected muzzle, which seems like it would involve creating the mouth by dividing the mouth related metaball surface in half instead of adding holes to it.

Another important aspect of mouths involves mandibles and other mouthparts of arthropods. These features likely could be added in later if arthropod-like construction is put later on the roadmap, but is worth considering its distinctive features.

Note that insect mandibles are thought to be evolved from leg limbs, so some of the complex arthropod-like mouthparts might involve integration with limb modification somehow. Look at Anomalocaris for example, it had two limbs that it used to grab prey similar to how the large mandibles in insects work. So these mouth features might be best represented by having specific limbs able to be grouped with the mouth, which would enable compound actions of those limbs and the mouth to be synchronized. (And so that the animation system would know what to do with those limbs and relate it to the mouth movements and actions)

As an aside, remember that it is the animation system that is likely to be the most difficult area of all, and that generating the organism in a fixed position is only the beginning of the challenge. A major benefit of a parameterized system is enabling an animation system to have much greater insight into the nature of the organism’s construction, with the animation system knowing how to relate changes in different parameters to changes in how the animations should be handled. For a simple example, limb joint maximum angles of rotation and rotation speed are parameters that are extremely useful for the animation system even if they are not the parameters that are directly shown in the 3D Editor, perhaps instead giving a ‘joint range of motion’ or ‘joint flexibility’ parameter.

[Deus]

Very interesting points brought up. There’s a lot of content there, and this topic is all-encompassing, so I won’t be able to respond to everything here.

First, I’m not very familiar with the game, but Juno: New Origins’ does seem more comparable to our aspirations with Thrive’s editor than KSP due to its customization options. KSP is more complete and has a longer development history, so we probably have more “lessons” to draw from there; but I’ll check out the newer game for sure as a direct reference.

---

Overall, I think if we establish a decision making process and shared understanding of what exactly we wish to represent in the macroscopic and aware stages, our game design will be incredibly solid. There’s obviously a lot going on those stages, and a majority of attention of Thrive is, in my opinion, centered on Thrive’s analogue to Spore’s Creature Stage. So we need to find a way to create “cut-off” points, a bit similar to what we have in the Microbe Stage roadmap. I’m not arguing for creating a road-map - especially not now - but understanding what we want to represent will help us think better on designing concepts and the editor itself.

Top-Down Part Implementation Approach - Fundamental Taxonomic Characteristics

One thing that has helped me approach conceptualizing the macroscopic stages is to approach things from a top-down approach - in other words, conceptualizing features and parts which can cover as much diversity with as little direct implementation as possible. This naturally lends itself to fundamental mechanics such as surface area, aerodynamics, etc., but has also been useful for “parts” and mechanics we should prioritize.

One way I’ve approach this is by looking at phylogenetic/taxonomic groups, identifying their defining/unique traits, and finding ways to represent those in Thrive [phylogenetic groups help us understand how we can progress things, but taxonomic groups are useful for a general survey of diversity imo]. If the universal stats and constraints all organisms face are dynamic enough, and if we implement one or two mechanics from the most major clades of life, we’ll end up with an excellent mix of features in my opinion. That one-to-two mechanic per clade goal is going to end up being incredibly ambitious by the way, but you get what I’m trying to say - look at important groups, find important features, represent them, move on.

That way, we’ll end up with a bunch of diversity just by allowing these traits to be combined. I know that sounds like it could lead to Frankenstein-esque mosh-poshes, but trust me: if you can think of a random animal in your head, it probably lived at some point soon after the Cambrian…

Cothurnocystis

Vetulicola

The Tully Monster

I did this a bit in this post above, where I catalogued a significant majority of soft-bodied, simple organisms: Macroscopic Editor, Progression, and Principles - #28 by Deus

If we do this for a bit, I think we can end up seeing patterns and understand what tools are needed in the macroscopic editor, and when.