Building Microbe Stage

Ok for me. Just one thing i would like to add:

• Hitting a microbe smaller than you (rate depending on the organelle) will make it stick to you, slowly extending your membrane around the other cell to assimilate it and obtain all its compounds.

Yes, engulfment, very good. But to make that more challenging and less passive, I have an idea that involves some changes to the microbe editor. It may also simplify the animation for engulfing a cell. And it's very possibly a disrespect for the actual biology involved, so if it makes our biologists too uncomfortable, please say so.

• Engulfing another microbe requires a specialized organelle at the point of engulfment (both external and internal, but see below for why this might not matter anymore)
  
• To swallow another cell, the attacker must keep that organelle near the victim for a short amount of time
  
• The engulfment organelle must also match the size of the victim for swallowing to be possible
  
• After successfully assimilating the victim, its interna are visibly "sucked" into the engulfment organelle to be digested
  
• To support organelles that have both an external and an internal part, remove the distinguishment between those in the microbe editor
  
• Formerly external organelles now occupy their own hex grid cell(s) and are "external" by virtue of being placed at the edge of a cell
  
• Some organelles (for example, the engulfment organelle) can only function properly if at least part of their edge is along the microbe's border. Placing them completely internal results in a warning being displayed to indicate that those organelles will be useless
  
• Organelles that change the surface texture of the microbe (e.g., spikes protruding from the cell) should only display those surface graphics for edges that are adjacent to another occupied hex cell
  

Ok, so I'm going to be 'that guy' whose uncomfortable with that. IRL, similarly sized cells don't engulf each other. Phagocytosis (cellular eating) involves extending the cell membrane around the other object until it forms a vacuole around it. This means that normal sized cells will only be able to wholly engulf small cells, and so on and so forth. The whole use of another organelle to allow engulfment has no base in science as far as I know, and seems confusing as well. The only real way for two similarly sized cells to kill each other are to either puncture the other cell's membrane or to secrete a compound that will kill the enemy cell without killing yourself as well.

Anyone with more biological knowledge please feel free to edit/correct me here, but I think this is correct.
Let's keep refining this. we are getting close to a final concept!

True, yet it is a game the guys are trying to make and organelle for phagocytosis would make animating it convenient. As far as i know i don't remember cells killing each other with spikes the only weapons cell are using are chemicals but again its a game so spikes are to be added and such organelle doesn't have to be even visible to the player just some kind of cytoskeleton upgrade in a place near the membrane would be kinda scientifically correct and would look good ingame too.

Although I wholeheartedly agree with Nimbal on the implementation of an engulfment surface organelle, I disagree on the issue of health. The hitpoint system is neat and tidy, and will be easy to implement, especially in the first few releases, I'd like a more interesting system.
Here's how an alternate, compound management-based system for health would work:

• Each organelle is constantly processing compounds, whether it be to produce energy (mitochondria, chloroplast), store energy in fats and sugars, regulate protein synthesis, etc.
  
• Each organelle processes compounds at a certain rate (given that it has enough of the original compounds that it requires), dictated by how it has been upgraded in the Editor.
  
• Toxins can be emitted by cells. These toxins affect organelles directly in specific ways. For instance: Toxin A decreases mitochondria efficiency by 70%:the effect is that your cell loses energy. Toxin B decreases flagella efficiency by 90%: the effect is that your cell's flagella can no longer propel you away from a predator. Toxin C dissolves your cell wall, exposing your fragile outer membrane to the environment.
  
• Toxins don't need to be bad or aggressive. Other toxins could have positive effects. Toxin X could increase chloroplast efficiency by 10%. Toxin Y Repels predatory cells. Toxin Z is a food product with 1.3 times the energy of glucose that other cells can ingest for energy.
  
• Toxins will work just like other compounds in the environment- they will be represented by a specifically colored and shaped particle and will float along through the environment until they decay (their rate of decay can be modified in the Organism Editor)
  
• Toxins are emitted by a "toxin vesicle", a bubble-shaped organelle that can be placed inside your cell. The behaviors of the toxin that vesicle contains can be modified in the editor (What the toxin affects, how the toxin affects it)
  

Why do I think this is a good idea?

• It may seem complex, but the system relies completely on Organelles and Compounds, systems which we are already going to implement and which we know a lot about.
  
• It creates a new dimension of gameplay, where the focus is on chemical warfare rather than ramming into other cells with a sharpened appendage (though you can still do that if you want to)
  
• It makes gameplay more diverse. Since the toxin is based on just a few factors [(target organelle, efficiency change) or (target cell, behavior change)] it is very easy for many different toxins to be generated, each with interesting effects.
  
• This system also implies the implementation of Toxin resistance, where a separate organelle would produce resistance to specific toxins [(target organelle, toxin effect resistance) or (behavior change resistance)]
  

That would really be something great, ~sciocont , would give a huge strategy element to the game but lets say a player wants to wage spikes wars he would be frustrated to die instantly from one puncture. Maybe some kind of health bar at least to the cell wall so it can tank few hits?

Hi, i'm new to the forums but i've been following this game for a while. First I wanna say that i'm only a freshman in high school, but i'm taking college level biology classes, so I could probably help with the scientific knowledge bit. I was wondering, could we use perforin? It would be like puncturing cells without actually needing to use spikes

Welcome to the forums, Atrox! I too am a Freshman in high school (for two more days anyway) so we are probably taking the same level biology. Thats a really interesting idea, but I've actually never heard of it. It seems plausible to add that, but I'd probably need world from either the programmers or ~sciocont. (He's in charge as you probably know.)

Again welcome!

Thank you WJacobC perforin is pretty much a protein released by natural killer cells (i think it's natural killer cells...i always get mixed up) that pretty much punctures an "enemy" cell. It could be released as a cloud or something and I'm guessing that it would be a one hit kill since it is allowing for water to enter the cell which in turn causes it to pop ._. though mybe that would be a bit over powered...maybe it's encountered later in the microbe stage?

Why is everyone so afraid of insta-deaths? As i said, its the way it works in nature, all the time. Anything else would mean the predator organism would lose their food.

@Daniferrito well i for one am okay with instadeaths. im just saying that it could pose a challenge if you had just started a new game

I completely agree with Scio's suggestions for toxins, that's very close to how I imagined they'd work, though I never developed the idea that far.

However, it does still leave the issue of how 'physical' combat would work unsolved. I'm in favour of something a little more black and white, as scio suggested, rather than a health bar and the possible slog fest that would result in. That said, insta-death on physical contact (with a sharp implement) would get frustrating, so maybe we need to find a middle ground - either require a minimum impact speed for insta-death (which is unrealistic, but then so is mounting spike on a cell), or allow a cell to expend (large quantities) of energy and compounds to try and repair breaches to it's membrane, allowing it to survive minor hits.

Daniferrito wrote:

Why is everyone so afraid of insta-deaths? As i said, its the way it works in nature, all the time. Anything else would mean the predator organism would lose their food.

Completely agree. We have to realize that in a microbial world, death comes much more often than in a macroscopic world. The goal of the game is not to survive, it's to evolve and flourish as a species. You'll be dying a lot, and we'll try to make it a fairly small setback. You won't be punished for being in a competitive and dangerous environment.

Ok... 4 posts in the time it took me to write mine. It may be worth implementing the insta-death to see just how annoying it may or may not be, rather than discussing it much further here.

Quote :

allow a cell to expend (large quantities) of energy and compounds to try and repair breaches to it's membrane, allowing it to survive minor hits.

This would most likely be a good idea, especially as your cell gets larger. I'm also against rhino-style spikes, but we will in all likelihood have a predatory pilus organelle, which is essentially a hypodermic needle through which you suck out another cell's cytoplasm.
Let's keep discussion to a minimum for now. Please, only post if you have a distinct disagreement or highly novel idea. I don't want to discourage discussion, but I also don't want for any of the big players here to have to read through three pages of thread every time they come back here to confirm the concept.

Daniferrito wrote:

Why is everyone so afraid of insta-deaths?

I am certainly not everyone, but I can tell you why I am wary of such a mechanic. The current specification in the git repository says that death is pretty much game over. I realize now it may not have been clear, but I thought this implies that the player has to start fresh again. Losing an hour of progress because of a minor mistake in maneuvering the microbe is a surefire way to a ragequit, which we should avoid.

~sciocont wrote:

You'll be dying a lot, and we'll try to make it a fairly small setback.

Now, here's something that makes insta-death a viable alternative to a health pool. If we can make deaths small, but meaningful, I could warm up to the idea. How about this as an alternative to a simple game over:

• When the player dies, he sees his microbe burst, giving him some time to recognize what killed him
  
• After a few seconds, the camera zooms to a new cell that is the version of the player's microbe before the last reproduction
  
• Care must be taken that the player is relatively safe in the new location. For at least a few seconds, nothing should attack him, lest he tumbles down the evolutionary ladder without a feeling of control.
  

So, on death, the player loses some mutations. If we make those mutations small enough, this shouldn't be too hard on the player.

By the way, since it's closely tied to the above suggestion, have we come to a conclusion on the reproduction / mutation issue? As far as I can tell, these are the options presented so far (please speak up if I forgot one):

Spoiler:

Personally, I gravitate towards the last option. It's a little bland and overused, but I think the novelty of the cell editor should make up for it.

~sciocont wrote:

alternate, compound management-based system for health

I like it! What would you say to allowing the player to adjust his microbe's metabolism on the fly, setting priorities for the toxin organelles? It would give the player something to do besides moving around. And in the cell editor, he could decide between having a few very good toxins (we may need a better name for those, if they can also be beneficial) and many different, but weak ones in his arsenal.

The major problem I see with such a system is the visuals. It should be relatively easy to recognize and distinguish toxins floating around. At the very least, it should be quickly apparent what a toxin does once the microbe touches a cloud of it. How about this:

• Toxins are clearly distinguishable from compounds, and, to a limited point, from each other
  
• Touching a toxin cloud causes the microbe's organelles to indicate the toxin's effect. If the toxin is harmful to an organelle's effectiveness, the organelle glows red. If the toxin is beneficial, the organelle glows green.
  

Note that there are probably more appealing effects than a red and green glow, but I'll leave that to the artists. Anyway, the above visual cues would require the player to carefully "taste" a toxin to determine whether it's harmful or not. Especially when low on energy, it could be a thrilling decision to either hope for nutritious stuff, but risk further harm, or moving on and trying to find less risky food sources.

Edit: Added Seregons mutation model

Nimbal wrote:

I like it! What would you say to allowing the player to adjust his microbe's metabolism on the fly, setting priorities for the toxin organelles? It would give the player something to do besides moving around. And in the cell editor, he could decide between having a few very good toxins (we may need a better name for those, if they can also be beneficial) and many different, but weak ones in his arsenal.

Enzymes? Then the chemicals you would use to bond to other cells of your species could be incorporated as one of these.

Excellent discussion guys. I've been reading through this whole thing, and I didn't want to not have said anything.

Nimbal wrote:

The current specification in the git repository says that death is pretty much game over. I realize now it may not have been clear, but I thought this implies that the player has to start fresh again. Losing an hour of progress because of a minor mistake in maneuvering the microbe is a surefire way to a ragequit, which we should avoid.

Does it? I dont think dying should be game over at all. Extintion probably will mean game over, but a single creature dying shouldnt matter too much. Anyway, as scio said, and you quoted him just in the next line, with deaths being not too hard on the player, a more realistic insta-death isnt bad at all (you would just need to run away inmediatly, not after recieving six hits from the oposing creature)

Ok, to clarify: at the time you asked why everyone is against insta-death, nobody has explicitly pointed out that it should come with only a small penalty for dying, while the specification I posted explictly stated that death means game over, which is a pretty harsh penalty. Then, finally, scio suggested a lesser penalty, which I agreed to. Oh, and before you point it out: yes, I know that something akin to a respawn was suggested before, but no, it wasn't in the specification. Thus, it should have been mentioned as an additional requirement to make instant death work without being too punishing.

This is really exemplary of a real problem that is apparent throughout the forums. Someone makes a suggestion, but doesn't care enough to go over the current concept and make the suggestion work in that context. Instant death with a simple game over on death is a bad idea, period. Coupled with a mechanic for demoting death to a minor inconvenience, it can work.

Sorry, I suspect we've all been working off what has been agreed elsewhere, that death of your individual organism simply results in you taking over another member of your species. I think the specs on the previous page also mentioned that perma-death was only for convenience, and that we would work towards a better system later.

Back to mutation, I prefer the second third option, mainly becuase it's the most realistic, but I can also address a few of your concerns and provide other advantages:
- It could actually give you more freedom to experiment with your playstyle and your organisms metabolism, as the amount of mutation you can do is no longer tied to how often your cell can reproduce, or how quickly it can gather resources.
- Instead, mutation rates go up based on how succesful your species, rather than the players individual cell, is. I realise the current spec doesn't include modelling populations, but it's something we will have to do eventually, and can be done more simply, and computationally cheaply, than you might be worried about.
- Having mutation based on population introduces a bit of a metagame, so that the player has to try and evolve not only a single cell which is good at collecting resources, but a species which is capable of surviving in its environment. This needs some thought, but if the player only has to worry about their own cell, then we're building something very similair many other games out there (osmos, asteroids...).
- We've already agreed on nuclei drops granting new organelles, or possibly other upgrades. To keep the player connected to their mutation rate we could offer other sorts of drops which boosts the MP/genetic diversity gain, though I can't think of a realistic counterpart just now (apart from radioactive or other mutagenic substances...).
- I know we're not evolving the AI species yet, but when we do, this system will be the easiest for them to work with, as they don't have a single 'player' cell to gather mutation resources or to level up. As mentioned above, this way both the player and the AI are working at the population level, rather than that of individual cells, which makes auto-evo significantly simpler.
- Finally, to encourage experimentation, from the genetic diversity perspective it's quite reasonable to refund some genetic diversity if you undo a previous mutation.

Seregon wrote:

Sorry, I suspect we've all been working off what has been agreed elsewhere

It's ok, but the specification we are discussing and developing here should be seen as "complete" in the sense that anything it doesn't explicitly mention won't be part of the game. Of course, the specification is far from complete in the sense of "done", for example, I don't think it mentions sound effects anywhere. As I said, it's important to communicate a suggestion clearly and with context, so that the overall effect on gameplay can be gauged.

Seregon wrote:

Back to mutation, I prefer the second option,

I'm not sure I understand. The second option is the one with "high energy leads to mutation". How is the player's energy related to population?

Hmm, maybe I'm getting this wrong, but I interpreted the second option as similair to what I suggested on the previous page:
- Mutation points / genetic diversity accumulates over time, but not (primarily) by being collected by the player.
- The player is able to mutate when they can reproduce, which happens when they have sufficient energy/compounds in storage.

It's not that their ability to reproduce is linked to population, but the level of genetic diversity available to use for mutation is.

I've updated my previous summary about the suggestions for the mutation system so far with Seregon's proposal (third one from the top in the summary).

While dissecting Seregon's model for mutation, I also had an epiphany about coupling reproduction to energy. In the past, I always understood that as "keep your energy above value E for a total of X seconds, and you get to reproduce / mutate". That sounds passive and indirect, because the player already has to wait for the energy to top up (assuming that organelles take time to do this), and then has to wait for some kind of reproduction bar to fill up.

The other interpretation of "reproduction requires energy" somehow never crossed my mind until now: the player has to fill up the energy to at least, say, 80%, then the microbe can immediately reproduce, but "spends" energy in doing so. An intuitive and (to my limited biology knowledge) realistic cost would be that the parent and the offspring would each get half of the total energy the parent had at the time of reproduction.

The main advantage I see over the first interpretation is that reproduction is almost independent from the rate of energy change. If someone wants to build a microbe that quickly depletes its energy resources, they can do so, as long as they also provide a powerful digestive system to top their energy back up when they find a rich cloud of nutrients. The other way around, a more peaceful and relaxed player can build a microbe that is very conservative with its energy, and can sustain itself on nutrients that float by in the current.

The first player will take some time to find enough usable compounds close together to achieve reproduction, the second one just has to wait and deal with the occasional attacker.

If some of you meant this second interpretation of "reproduction requires energy" all along and I responded with reluctance, my apologies. I would actually support a mechanic like this.

Thanks Nimbal.

For the energy -> reproduction, I think what you just wrote is pretty much what we had in mind. You need some level (be it 80%, or 5 nanograms of ATP) to reproduce.

There is an alternative, which is a hybrid between the two interpretations. I'm a little cautious about introducing too many new ideas at this stage, but it may be the best of both worlds:
We have a seperate reproduction bar, which would be coded as another compound. Once this is 80% full you can reproduce. Energy/compounds are used to fill this bar up gradually, the more you have available/surplus the faster it fills up. The bar shouldn't go down (unless you suffer some traumatic injury), only up, though it may freeze below a certain threshold (why worry about reproduction when your starving?). This should be less frustrating than the alternatve, as you don't need to worry about getting your energy above a certain level, only keeping it relatively high for a reasonable amount of time, although your still rewarded for getting it higher.

Since nobody has objected to them so far, I incorporated the changes to the microbe editor into the specification. You can see the changes here.

Also, I think I have to apologize to Daniferrito. In this post, I incorrectly stated that sciocont~ was the first one to explicitly couple insta-death with only a minor penalty for dying (at least the first one since I started the specification document). Obviously, I can't read, because Dani did exactly that here, right in the first sentence.