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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.