Building Microbe Stage

@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.

Wow, you guys are doing fantastic work.

Quote :

allowing the player to adjust his microbe's metabolism on the fly

What do you mean by this exactly? Do you mean that the player adjusts the efficiencies of organelles in their cells whenever they like?

Quote :

Spoiler:

This is excellent. We can discuss it more in an art/interface thread at a later date.

I should have mentioned my desire for a less serious death mechanic earlier, I'm partially to blame for that confusion. I agree with the model where you switch to another member of your species from before your last mutation. Consider that all cleared up?

Quote :

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.

Ok, I like this, here's an interpretation of how it would work:

• Every cell has an endoplasmic reticulum (ER) organelle. This organelle is what essentially runs protein synthesis- this isn't a new idea, the ER is a standard starting organelle for your cell, and again, all cells must have one.
  
• The ER produces a compound (let's call it reproductase [RpAse]) whenever your cell has enough energy for it to do so (pretty much all of the time, unless you're starving. [RpAse] is made directly from ATP, and no other products.
  
• When you have enough reproductase [RpAse] (amount needed should be the number of tiles in your cell), you can reproduce.
  
• The size of your population earns you extra mutation points to use in the cell editor.
  

This system is good because:

• It's simple, easy to understand. I personally don't like the idea of adding multiple currencies: I want to focus the game on simple mechanics that can be used to produce complex results.
  
• It sets a farily regular lifespan for a cell in a resource-rich environment
  
• Once you have enough [RpAse], it can never go down again.
  
• Population size is taken into account.
  
• You can make your reproduction happen faster by upgrading the efficiency of your ER. Now the ER has a defined ingame function and you can use the system to your advantage.
  

Disadvantages to this system:

• Population size affects the size of mutations, not the breadth of mutational possibilities. This could be dealt with but would probably require rewriting a bit of where mutations come from.
  
• Doesn't specifically incentivize anything other than ER upgrades.
  

Sound good? Did I miss anything? We seem to be getting very close to a concrete current concept.

~sciocont wrote:

Quote :

allowing the player to adjust his microbe's metabolism on the fly

What do you mean by this exactly?

The simplest version of my idea would be the ability to temporarily "deactivate" organelles. Inactive organelles would consume little or no resources, but wouldn't give any benefit. Activating them should take some time and / or cost some resources to discourage high-frequency micromanagement. Once they are activated, they consume resources just as normal and provide their benefits.

Interface wise, this could be as easy as clicking an organelle in the microbe with the mouse. If we go with that, a zoom function (mouse wheel, most likely) would be nice to give the player an overview, but make it possible to accurately click a small organelle if necessary.

Activating and deactivating organelles to save on resources is something i believe most cells do. Even more, we could put some parameters so they are automatically turned on and off, to save on some of the player's micromanagement.

That would be for example, turning off sugar production if the sugar count goes above a certain thereshols (80% capacity) or current energy goes below a certain value (less than 10% ATP). All that parameters could be set up in the microbe editor.

Nimbal wrote:

~sciocont wrote:

Quote :

allowing the player to adjust his microbe's metabolism on the fly

What do you mean by this exactly?

The simplest version of my idea would be the ability to temporarily "deactivate" organelles. Inactive organelles would consume little or no resources, but wouldn't give any benefit. Activating them should take some time and / or cost some resources to discourage high-frequency micromanagement. Once they are activated, they consume resources just as normal and provide their benefits.

Interface wise, this could be as easy as clicking an organelle in the microbe with the mouse. If we go with that, a zoom function (mouse wheel, most likely) would be nice to give the player an overview, but make it possible to accurately click a small organelle if necessary.

Ok, this is fine. I'd rather have a "pause the game and look at a model of your cell cell close up, along with compound levels" but that's not something we need to discuss currently, I'll just leave it as a note for later.
I'm assuming you have an opinion on the interpretation of Seregon's reproduction model?

I like the idea of being able to deactivate some organelles. We could go into more detail by prioritising some systems over others, but that's probably not necessary.

Automatically deactivate (e.g.:) sugar production once sugar is near 100% is actually built into the compound system. A process' rate falls when one of its outputs is plentiful, or one of its inputs is lacking, although it will never actually stop (unless something reaches 100% or 0%, which should almost never happen). We could add hard cutoffs when a process stops completely, but that gives us more parameters to tweak, so I'd suggest not doing so yet.

I agree with scio's simplification of the reproduction/mutation system (simpler than I'd like, but close enough), except on one point. We need some sort of seperate pool for different traits, primarily becuase it prevents players (or AI) from repeatedly mutating the same traits one generation after the next. The alternative is a common pool for all mutation points, but some sort of cooldown on how much you can spend on each group of traits.

Seregon wrote:

I agree with scio's simplification of the reproduction/mutation system (simpler than I'd like, but close enough), except on one point. We need some sort of seperate pool for different traits, primarily becuase it prevents players (or AI) from repeatedly mutating the same traits one generation after the next. The alternative is a common pool for all mutation points, but some sort of cooldown on how much you can spend on each group of traits.

Why not introduce some sort of rotation on available mutations?

That works too, but could get really annoying if you need a particular mutation (e.g.: more speed after meeting a new predator) but have to wait several rounds before it comes up.

Seregon wrote:

That works too, but could get really annoying if you need a particular mutation (e.g.: more speed after meeting a new predator) but have to wait several rounds before it comes up.

Actually, why not use populations to solve this? Make it so that after you mutate a specific organelle, you have to make it to some population milestone before you can do it again. The problem, I guess would be for species at a carrying capacity which isn't about to change. Hm. That's probably not the best idea.

I seem to have missed alot of conversation (finals) , for a guy who was writing/wrote a microbe stage prototype, sorry. please forgive me.

I read through the last few pages, and it appears the death mechanic is being discussed along with reproduction and evolution (which I thought we already had conceptualized)

Like we discussed in an earlier topic, death and permadeath are issues that we will have different difficulties for. Permadeath only happens in a sort of hardcore mode in which you have a population number and once it hits 0 you are dead, permanently).
When one dies:
We switch to a cell of the species (apparently from an earlier) mutation I do not agree with this little part, what if the player just had bad luck and got murdered by chance and what they did was a perfectly viable mutation.
I say we have a counter, a sort of life counter and once it hits a certain point then it goes back to an earlier mutation. 3 seems like a good number for this. I feel going back to an earlier mutation is very punishing and should be at least negated.

I like the current idea for reproduction.

Evolution, I feel we should be mutating/adding different organelles, I like the idea of doing it based on a population level however, we need to add another factor to this, like the competition or how well your creature is competing (which we will be keeping track of anyway).

For we will be upgrading parts procedurally (at least this is what we discussed in the organ thread)
------
edit: is this post seriously being looked over as a side note, we don't want to punish the player too much.
We need a death counter so that we only take away mutations once you die a fixed number of times.

~sciocont wrote:

I'm assuming you have an opinion on the interpretation of Seregon's reproduction model?

I'm a little skeptic, to be honest. The most glaring issue is that (in its current form) it requires the simulation of populations, but nobody has spelled out how we should do this. I have some superficial knowledge of the math behind population dynamics, but how does it fit into the gameplay of the microbe stage? What kind of data do we feed into the equations? How will the player's actions influence that data?

Second, as I've noted before, I'm not convinced that having reproduction coupled to "high energy over an extended period of time" will be better (as in "more fun") than just requiring high energy at the time of reproduction, if coupling it to energy at all. It would probably be best to decide that through playtesting, though.

~sciocont wrote:

Doesn't specifically incentivize anything other than ER upgrades.

Making upgrades to any one organelle progressively more expensive should take care of that.

Slightly unrelated, but since you brought up an organelle that every single cell has, there's a small issue with the microbe editor right now. It would make implementation a little easier if there were always a "kernel" to the microbe that the player can't remove. That way, we don't have to worry about what happens when player removes the last hex or, conversely, adds the first hex to the shape. Those are edge cases I'd like to avoid since they pose some challenges both in the user interface and in the implementation underneath.

So, could we use the ER for that? That would also be an elegant solution as to how the player selects it for upgrading. It would just be another organelle, the only difference being that it can't be removed.

If you have other ideas for a fixed microbe kernel, just keep in mind that it should be relatively small and circular in shape, making it easier for the player to build the shape he wants around it. I'd say one central hex and all 6 of its neighbours should be the limit. As long as we make them fit, we could also add multiple organelles to the kernel (nucleus / nucleoid come to mind).