Multicellular Stage: The Beginning

Should every membrane type be able to bind?

If some membrane type couldn’t bind, it would make it quite an useless choice, as the player would need to pick another membrane type to advance in the game.

1 Like

Over the last days I have been sporadically working on a simple concept of how the very early multicellular editor might look. Since my concept shows the multicellular editor before the dimensional shift, I figured this would probably be the appropriate place to post it instead of in the „The Aware Stage and Mechanics“ Editor thread.

As there are up to 3 year old posts in this thread, my concept might not be 100% in sync with all of the ideas layed out above. But it seems to be largely congruent with the draft @Buckly recently posted in the „Cell Specialisation and the Dimensional Shift“ Thread.
I also included the copy and edit buttons posted by @Narotiza in the Aware Editor thread.
The icons for the cells on the left might be a bit large. Maybe there should be three in one row to make things more compact? I‘d apprechiate feedback about that specifically and about everything else in general.

6 Likes

Putting three in a row might help with organization at the multi-cell stage in my opinion. That way with specialization cells and basic cells the player might more quickly or easily be able to create a multi-cell creation more freely and be able to create future/further cell specialization. This could then in turn influence or aid in future mechanics further into multi-cell life.

I think we need to think some on what kind of creation abilities we are going to allow the player to have when they pass a certain variation of cells (3,5,8,etc) in this stage of evolution for their creature to introduce some more complexity to the game in terms of difficulty. Thoughts?

Overall I do like the UI and the editor design and feel we can keep it into later stages of the game until we possibly branch fully into a 3d editor if we are still taking that route.

1 Like

It’s been some time now since I’ve last discussed the multicellular editor and it’s workings, and I apologize for my late continuation. To help out those who may be a bit behind, I’m going to write a recap below to explain the overall idea we seem to have settled on, before I present my ideas.

Multicell Editor Recap

The multicellular editor is going to be accessed immediately after the player evolves from a bound colony of 8 or so cells via either the normal evolve button or a new separate one used to represent a transition.

Once within the multicell editor, the player will be presented with a single starting cell, and a “parts” list from which new cells can be selected and placed. The player may now place cells adjacent to the original to assemble their multicellular organism.

An additional feature is the presence of a specialization editor, where players can edit their cell type to create new specialized variants of their cell. This editor behaves identically to the original cell editor, except that it is accessed temporarily through the multicell editor by clicking the associated buttons located on the cell selection.

Once the player has assembled their organism, they are now ready to proceed into the brave new world of multicellular life, and with that, you are now caught up!

As it is currently planned, Thrive is going to feature a transitional 2D or 2.5D stage between microbial and multicellular proper. My intent is to discuss our options of how to proceed with the design of the early multicell editor, and hopefully address some of the logistical problems we face.

Cell Placement
An important thing to consider is how we intend to handle cell placement, as placing cells will be a bit different than placing individual cell parts.
I present two options:

  1. Hex grid
    By continuing to use the hex grid, we can effectively reuse a large amount of code and features that we already have. Since cells are already made of hexes, placement will be identical to the microbe editor, but with bigger parts and maybe a couple more placement rules.
    However, this system restricts part placement to limited angles, which might be somewhat unappealing. (Refer to MirrorMonkey’s concept for an example.

  2. Free placement
    By removing the hexgrid, we can grant players a far greater degree of flexibility for part placement and organism customization at the cost of much more development work.

Players would be able to rotate and flip their cells at any angle, as well as potentially even resize their cells if we so chose to include such a feature.
However; free placement would require lots of work to implement for something that is only intended to be transitional.

After some consideration, I feel that sticking with the hex grid might be our most realistic option, as much as I would love free placement.

Cell Specialization
The creation of new cell variants is arguably the most important part of multicellular, and so we need to carefully consider how the player accesses the editor window for individual cell types, as well as how we shall handle cost of mutation, and updating already present cells with new layouts.

It has been established that clicking the edit buttons placed near or on the cell icons will grant access to the cell editor. But how the editor window will reveal itself is a matter that we have not yet considered in depth. Below are two different concepts on how the window might change.


This concept effectively replaces the entire editor with the unicellular equivalent for the selected cell type. It is also functionally identical save for the preview window used to view the entire organism for reference purposes.


In this (admittedly messy) concept, the part selection window is expanded into a miniature portal within which the cell editor is displayed. This concept would allow for smoother transition between editing parts, without changing scenes entirely.

In addition to editor windows, we must also carefully consider how changes should be applied to presently placed cells in the event that the player edits them without creating a new variant. The problem posed by this situation is that when cells are edited, their size may change which will undoubtedly create positioning issues within the organism. Note that this problem is specific to the transitional stage, and won’t be applicable to the 3D editor. Below are a few options that I have considered to remedy this problem.

  1. The previously placed cells must be manually updated by the player, requiring them to reposition surrounding cells.
    Nothing necessarily appealing to this option other than the lack of programming involved.

  2. Cells are resized or otherwise don’t change size/shape but still effectively inherit changes made to them in order to fit.
    Instead of cells having unique shapes in multicell, we could potentially get away with them all being generic save for some visual changes and external organelle placement. That or we automatically resize cells to fit, but that would not work well with the hex grid.

  3. Surrounding cells are automatically pushed/repositioned to make room for edited cell types.
    This is probably a nightmare to program without creating all sorts of bugs and issues, as well as potentially alter the organism’s shape in unwanted ways.

I don’t know if there is any perfect solution to this, I would greatly appreciate input from our programmers about how this might be solved.

Finally; We need to decide on how we want to handle the cost of editing cell types in the organism, this is very important as it sets the pace of player mutation and customization in the game. The expanded depth of customization brings some added difficulty to this endeavor, as more things to change in the organism means slower evolution per generation. Below are some proposed methods for handling this.

  1. Per-Cell MP Pools
    By granting each cell type their own MP pool, we can allow the player to make small changes throughout the cells of their organism without having to focus on any particular one. This could be balanced by altering the cost of individual cell parts, or by decreasing the amount of MP granted to each cell so less can be changed in each cell at once.

  2. Divided MP Pools
    By having two separate MP pools for cell specialization, and cell placement, we can allow players to tweak one or two of their cell types without sacrificing options for placing new cells on their bodies.

  3. Dynamic MP Exchange
    A bit of an unusual take that is difficult to explain, but by granting each cell their own MP pool, and then an overall MP pool for all changes, we can allow the player to make limited changes to many of their cell types at the cost of spending some MP they could use to place new cells.
    (Ex: The player spends 90 MP to place 2 mitochondria in a cell, which then deducts 45 MP from their overall MP pool, leaving them with enough MP to make the same change to one other cell).

  4. Standard MP Pool
    All changes cost MP from the same pool, preventing the player from making very many changes to their organism at once.

Personally, I would prefer some variation of 3, but perhaps there are better solutions out there.

Dimensional Transition
Another highly important aspect is how we intend to translate the player’s 2D organism to 3D. My only idea so far is that we essentially utilize something akin to @Nunz’ 3D membrane generation methods to similarly generate a solid body from the player’s component cells.

The resulting body would act as the torso section for the fully fledged 3D editor, upon which the player would begin to place limbs and other parts. I would like to hear what everyone has to say about this, as well as Nunz’ own opinion on the plausibility of this method.

I hope that by bringing up these issues and their potential solutions, that I can promote fruitful discussion through which we may decide on our course of action. Once we have decided, we will be largely free to move on to charting out early multicellular gameplay mechanics.

Let me know what you think!

Edit: I forgot to bring up placement rules for external cell parts. Obviously, placing cells where external parts collide with or clip through other cells and their parts is bad, and should be avoided. So we should consider options on how to prevent this from happening.
If we go with the hex based, I suppose we should make the external organelle hexes check for adjacent hexes and prevent them from being placed if the check is triggered. With free placement, we would need for them to have some manner of collision check.

2 Likes

Great overall summary of our current ideas about the early multicellular editor!
I have a crucial question regarding the dimensional transition: In the concept art of the multicellular editor you posted, the organism consists of only six cells when the transition to 3D happens. Is this on purpose?
This question is also adressed to the creator of this concept art (I assume it’s @Narotiza since he made most of the interface concept art).
In my understanding the transition would be easier to implement and make more sense from the players point of view if it happened once the players organism reached a scale which feels noticably different from the scale he was playing in as a single cell.
If the transition happened at around the size this concept art seemingly proposes, the single-celled organisms around the players organism would still be visible in all their detail, with all their organelles being discernable. If the transition happened at a size of for example 25+ cells, the unicellular organisms could be represented as simple semi-translucent sprites or maybe as extremely simplified 3D models without all their organelles being visible.
The transition happening at a size of 25 or more cells would

  1. save a lot of computing power, as in a 3D environment with the same density of microbes and the same rendering distance a lot more microbes would have to be rendered.
  2. negate the need to rework the current membranes to be visible from all sides. As far as I have in mind atm the membranes only look right if you view them from above.
  3. make intuitive sense from the players perspective. Why would you be able the see the same cells you saw before with the same amount of details, but now in 3D rather than in 2D? If the player is gradually introduced to a new sense of scale the intruduction of 3D makes sense to him when he looks back at how the world now looks different from his organisms point of view when compared to the view it had when it was a tiny microbe.
1 Like

It’s just intended to demonstrate how the game might trace the overall shape of the player’s organism to generate the torso, the cell count is simply the same because I was too lazy to make a different organism.

The art is not indicative of the requirements to reach late multicell.

Nah I made it, I can understand the confusion, but Naro’s would probably be much better quality. (I mostly make my concept art by haphazardly assembling and editing screenshots from the actual game.)

I’ve been thinking about something similar, with the organism’s individual cells gradually becoming less individually discernible via shader or something else as they progress. I am not aware of the specific feasibility however so I would very much like some input from our programmers on the matter.

1 Like

That adds complexity to the game.

I think something like 20-25 cells should be the limit when you unlock a button to become macroscopic. When you do each cell is converted to a metaball of tissue of that cell’s type and your entire species is basically scaled up to represent that each cell has now turned into like billions of cells and you are a big creature now.

I went ahead and created some polls for quick feedback since not everyone is willing to try and discuss the post in full detail on the spot. I hope this helps.

Which placement method should we pursue?

  • Hex Grid
  • Free Placement
  • Other

0 voters

How should we handle updating edited cells that have already been placed?

  • 1: Manually update and relocate each cell
  • 2: Resize cells to fit
  • 3: Push away surrounding Cells
  • Other

0 voters

Which method of MP cost should we implement?

  • 1: Per-Cell MP Pools
  • 2: Divided MP Pools
  • 3: Dynamic MP Exchange
  • 4: Standard MP Pool
  • Other

0 voters

I like how this approach radically simplifies everything by not having to deal with everything in between “each cell is placed individually” and "tissue is so macroscopic that you can’t see individual cells at all.
But if each cell is suddenly replaced by billions of cells of their kind, we’re talking about a drastic jump in scale.
The jump from 2D to 3D will already drastically change the ratio between surface and volume of the organism. This could confront a lot of organisms with sudden problems, especially photosynthesizers. If I’m not mistaken (and I very well may be), scaling up the body plan of an organism by a factor of 1000 or more (as you seem to be suggesting) can give rise to similar problems. If we go this route of suddenly scaling up the organism like this, we’ll have to stay aware of such problems.

I think the approach of scaling up each cell to be a ton of cells at once is the best of the options we have. I think we will hit a performance issue with more than a few hundred cells existing at once. Meaning that it is simply impossible to let colonies get into thousands of cells and having multiple of those on screen. The only doable thing I can think of is to just make the jump from less than a 50 cells to a macroscopic organism where we can stop rendering individual cells.

1 Like

Only way this 100-1000 cells stage could work is if we simplify the Microbe class( or create a cell class) and have one shape per microbe. Just my 2 cents.

1 Like

I’m also thinking that rendering the individual organelle models is a pretty expensive operation (I think there must be some kind of frustrum culling or instancing option in Godot we aren’t using that would improve the current performance with many cells as a lot of players have low FPS problems).

What if we actually switched to metaballs, but applied a skin texture that looked like discernible cells? Like a bumpy texture. I think we actually have a concept of something similar from an artist that came and disappeared somewhere in these forums…

Edit:
I found it

1 Like

Now the question remains of, how would the tissues look like and how would the player decide the function of the tissues?

I guess we can do that. As long as the texture can be made that looks like cells, it should probably be about as easy as making the feature itself at all.

1 Like

Thinking a bit more about the early transition, maybe we could make the cells have visually the organelles that they contain but only have one shape containing them.
So maybe we could transition to the tissue thing after 50-100 cells, then we could transition to the tissue texture, which would represent the >100 cells.

2 Likes

I’d love it if someone would look into improving the rendering performance of the organelles. Because I might have to do it myself otherwise (or limit the active alive cells a lot) as many players get single digit FPS in the later game, and from my profiling it seems to be about 60% native code running in Godot even on my computer, which I guess would be a rendering bottleneck.

Yeah this image from the concept art library is exactly what I had in mind in as an alternative for a less sudden jump in size.

Yeah, I was thinking this not only regarding the multicellular organisms, but also the unicellular ones which would still be present in the 3D environment. This is what I meant when I said this:

Fulstrum culling is active by default. There’s no occlusion culling. According to the docs the high amounts transparency would be the prime suspect along with Godot’s mesh instancing. The only recommendations given for instancing were using multi-mesh or using Servers rather than the Node system.