Macroscopic Editor, Progression, and Principles

Deus · March 10, 2025, 8:52pm

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: