Gestation and Maturity

[EricL]

Thought I would have an explicit topic for this subject.

The ability for bots to reproduce every cycle and to do so immediatly after birth can lead to organisms mutating towards a strategy of explosive cancerous growth in certain evo sims, particularly those using dynamic costs, as a means of swamping competitors and spiking CostX for shorts period of time (amoung other things, killing performance).  While on the one hand this can be consdierred a viable competitive adaptation and there are certainly some parallels in the biological world (bacteria, locusts maybe) the current lack of restrictions allows for much more rapid and explosive reproduction than biology allows and discourages the evolution of long lived, complex macro behaviour, something I think most of us are focused upon.  

Configurable options for gestation and maturity periods would allow for the simulation of the morhological and physical processes inherent in biological reproduction which naturally put a lower limit on generation times.  Options of 0 would likely be the default for both, which would be indistinguishable from today's settings.

[Sprotiel]

I say : let them die Félix Faure-like!

My solution would involve 2 simple changes:
* If a bot wants to repro, just let it do it! If the energy cost kills it, tough luck!
* Assume that the machinery that allows a bot to function (I.e. its CPU, locomotor apparatus, etc.) is made of a certain fixed amount of Body (say 100) and that when it starts to eat into that it dies. There are 2 ways to implement this : either we say that a bot dies when its body falls below 100, or we say that a bot's "body" value means useable body (in addition to the machinery) and charge them 100 body when they repro.

The first fix alone will eventually kill off cancerous strains, though with a large population spike. With both, the problem will be solved quickly, but it may require all bots to have some minimal body regulation code.

[Numsgil]

There are dangers to arbitrary fixed cycle refractory periods.

For instance, in real life some organisms would have litters of several kids at once.  The only way to do this at present is to reproduce a bunch of times at once.  This is especially important in the production of multibots.

Any fixed cost (be it time or body) is going to not change the problem, but just spread it out over multiple cycles.  Which is fine if all you're going for is sim speed, but I think we can do better.

Let's have a stored up refractory index that decreases each cycle, down to a minimum of 1.  This would represent something like the number of organelles that have been pre-duplicated, the stress on the reproductive machinery, etc.  Everytime a bot reproduces, charge it something akin to log(refractory index) to do so.

Bots that reproduce only when their refractory period = 1 don't have to pay any extra nrg.  Bots that reproduce when their refractory period is quite high have to pay log (refractory index) * some constant that's user set (probably needs to be a real instead of an integer) nrg.  Every time a bot reproduces, its refractory index increases by some user set constant (which should probably be a real instead of an integer)

This encourages bots to follow a natural rhythm with reproduction while still allowing them explosive reproduction if the moment so suits it.

There are all sorts of modifications that can be made to this idea as well.  Maybe bots that reproduce constantly can eventually achieve a lower cost to do so in exchange for something else.

[Zinc Avenger]

There is already a mechanism in place for "stress" that hasn't been mentioned in this thread so far - waste.

How about making reproduction generate a little waste in the "parent"? That way we can still have the good old cancerous explosions but the bots will find themselves crippled by waste unless they can evolve some way of dealing with the by-products. I always think it is best to use existing mechanisms in novel ways rather than arbitrary UI impositions.

[EricL]

Well, I guess won't be adding simplisitc universal gestation and maturity periods then...  

I did think about adding an optional, configurable cost that would only be accessed at reproduction.  That would address some of the concerns while still having the potential to stem runaway reproduction since reproduction would no longer be free, but as below, this is too simplisitc.  Besides, I don't think we want a single sim wide reproduction cost for all species.  Rather, it should be something that is highly dependent on an individual species specific morphology, evolutionary niche and reproduction strategy.  Generation times should subject to selection based on costs.

The waste idea might serve to deal with the gestation side of the issue, but it doesn't do anything for the maturity side of things.  Cancerous growth through binary fan out would still be possible.  Also, anything that requires that a waste removal gene evolve scares me since evolving such a gene is non-trivial.  You'd have to have a way to ramp up the waste 'cost' over time in an evo sim to evolve such a thing I would guess.  I beleive this is why most evo sims simply turn off the waste threshold or set it so high as to not get triggerred.

I think Nums has the right idea, a 'gestation/maturity period' countdown timer of some sort that counts down from birth and from reproduction.  There is an associated user-settable cost that when a bot reproduces, gets multiplied by the log of the timer's value (or potentially, some other definable curve).  If the bot waits long enough, the act of reproduction is free (it still must provide nrg to it's offspring).  Reproducing before the timer hits 0 has some cost.

Note that we could decide the two cases - gestation and maturity - should have different initial timer values, say the timer has a longer period for maturity (bots have to grow up before they can cheaply reproduce) but a shorter time for gestation (once mature, I can repeat reproduction at the same cost in less time than it took me to grow up).

Bots will need to have access to this information to make reasonable decisions about when and whether to reproduce.  But instead of just making the timer value available - a value that gets magically multiplied by a user specified cost value bot's can't access - I think it would be better if the bots knew exactly how much nrg it was going to cost to reproduce in any given cycle.  So, I suggest a new read-only sysvar called .reprocost whose value in any given cycle will be a function of the individual bot's countdown timer, a sim-wide user-supplied cost for reproduction and CostX (if using dynamic costs).  Thus bots can evolve effective strategies for reproduction based on what it is going to cost them, for example, taking advantage of low CostX periods to reproduce more often.

I would suggest we want the initial value of the timer for any given individual (and for that of newly born offspring) to be based to some degree upon it's physical and morphological elements - it's mass and size for example.  (The value for newly born offspring would be a function of the parent's morphology.)

At first blush, I am tempted to say the larger and more massive a bot is, the higher the timer value should be.  After all, it takes a mommy elephant 22 months to gestate a baby elephant, but bacteria can divide in hours, but I think this may be too simplisitc.  I think we do want bots to be able to evolve different 'natural' generation times through selection pressure on their morphological elements.

I will probably implement this pretty soon.  If any one has refinements or critisisms , please offer them up!

[Numsgil]

Sounds like a plan.  My only addition would be that the countdown timer should probably be passed on to both child and parent.  It doesn't make sense in the world of vertebrates, but for bacteria it's far more common for both to effectively be child bots of the same ancestor.

And while I'm thinking about it, perhaps it's less stressful to reproduce in a 95/5 split instead of a 50/50 split.  The more evenly the divided the parent and child, the more involved the preperation for the split.

[Testlund]

I can't make up my mind what to vote here. If you could add a function to simulate a "natural" way to make it more difficult for a bot to reproduce early in it's life, it whould be a good idea. I see that when running with corpses on the bots allways evolve to be passive and tiny to just floot around and pick up energy shots and slow down the program.

[Zinc Avenger]

How about limiting the number of birth ties a bot is allowed to have at any one time to one each? So a child cannot reproduce until it has been untied, and a parent can only have one child at a time.

[Anonomous Guest Person]

How 'bout we force bots to reserve energy torwards reproducing. The more cycles they do this, the less mutations will occur... however each cycle they spend on this will also decrease the amount of energy stored that'll actually go to the bot.

Perhaps while they're doing this, they're more suspectible to damage as well... or maybe shots will merely damage the amount of energy/body that's already stored for the offspring as well as the parent.

This allows some bots to hastily spit out offspring, while other bots can spend cycles and cycles working on their children. The latter would of course be more convenient for multibots or bots with a lot of DNA.

Alternatively, we could just weaken a bot temporarily right after giving birth/being born, making them more suspectible to shots and tie drainage, plus reducing the effectiveness of any materials they have boosting their abilities (such as body, shell, slime, etc)

[Numsgil]

I implemented something similar to what you suggest AGP in the C++ fork.  mrepro now acts to modify the mutation rates of the bot being reproduced using repro.

mrepro now acts as a multiplier for mutations during reproduction.  Negative values increase the cost per BP to copy but increase accuracy.  Positive values decrease the cost per BP to copy but decrease accuracy.  These trade offs are non-linear

[Testlund]

How 'bout we force bots to reserve energy torwards reproducing. The more cycles they do this, the less mutations will occur...

Sorry, but I don't think that makes any sense.   It shouldn't affect mutations imo. I think Eric is heading in the right direction though with that timer thing. Maybe a timer that counts down how much energy the bot will lose if it reproduces. The longer it waits, the less energy it will lose. It could simulate that a bot's body needs some time to replenish itself (or how I should put it) to get all body functions ready for reproduction. It should be more costly for a bot to reproduce often.