Code center > Suggestions
.sexrepro reimplemented in 2.43.1
EricL:
.sexrepro has been (re)implemented for the next buddy drop (2.43.1).
DNA may now be decorated with a new command "cross" which is subject to mutation, etc. like all DNA. This command does nothing other than to define crossover points for when DNA is combined during sexual reproduction.
Currently, the only way to sexually reproduce is for both parents to be near each other at the same time. Down the road, other methods may be defined where fertilization by one or both parents can be time shifted (e.g. egg laying, shot-based fertilization, etc.).
Currently, there are number of requirements to sexually reproduce:
1) The two bots must be looking at each other with their focus eyes. That is, each bot's refvars must represent the other.
2) They must both store a positive value (that is not a multiple of 100) into .sexrepro during that cycle (as with .repro, the value gets MODed down the line to determine the percentage of resources to give to the offspring).
There is no requirement that the two bots be of the same species. Species recogninition and mate selection are and should be a function of the morph and are totally outside the scope and jurisdiction of the simulator code.
The bot with the higher .sexrepro value (before the MOD) is designated the female, the other the male (if they both have the same value, one is chosen as the female randomly). There are ramifications of this, the most important being that all the nrg and other resources for the offspring are provided exclusivly by the female according to her value in .sexrepro. The male pays no nrg or other resources for reproducing sexually. The idea here is that as in nature, reproducing sexually is expensive for females and cheap for males. Perhaps one day this may lead to male-male competition and sexual selection.
The bot designated as female also plays an important role in many other ways akin to asexual reproduction including:
1) She must have .body > 2
2) There must be space for the offspring to materialize in front of her.
3) The offspring is born with a birth tie to the mother and inherits her velocity.
4) Genetic memory is inherited from the mother only.
5) Custom defined sysvars (e.g. user-defined memory location labels) are inherited from the mother only.
6) Mutation history is mother's side only.
7) "species" level info such as disabled visioin, disabled mutations, etc. are mother side only.
8) offspring inherit their mother's color.
Veggies may reproduce sexually but veggy reproduction limits are respected (and reproduction may be prevented) when the female is a veggy. Note that veggy males may reproduce sexually with non veggies independent of veggy population limits. The mother must be a veggy for the offspring to be a veggy.
Crossover is performed by taking alternating sections of DNA from each parent deliniated by cross commands, first one parents DNA and then the other's. Switching between parent genomes is performed whenever a "cross" is encounterred at that bp location in either parent's DNA. Which parent the process begins with is chosen at random. If one parent's DNA is longer than the others, the offspring may or may not inherit the DNA from the longer genome (that DNA which extends beyond the length of the shorter genome) depending upon whether or not the longer parent is providing DNA at the time the end of the shorter is encounterred. Crossover does not respect gene boundaries. Crossover points may occur mid gene and/or in non-coding areas.
2.43.1 should be out in a day or two.
Numsgil:
Other than the issues I have with using a crossover command (I think the whole methodology is overly complicated and can be done in a far more robust manner without using any new commands), I think when a sexual reproduction event happens, the two bots involved should each get a strand of DNA in a buffer. The bot would be "fertilized". Either bot could then either do nothing (ie: behave like a male), or produce a child with the given buffer DNA.
This way you could do hermaphroditic sex (like earth worms), homosexual sex (ie: neither parent produces offspring), or the more traditional male/female sex, with each bot controlling wether it wants to behave as a female or male.
EricL:
I fail to see how the crossover command is overly complicated. In fact it strikes me as the epitomy of simplicity as it eligantly allows the the number and position of crossover points to be subject to and exposed to selection as well as forming the basis of a natural species definition. That is, the probability that an offspring will be viable (contain a well cooridinated set of operating genes) decreases as the difference between the genomes and the relative positions of the crossover points of the parents increases. IMHO, this creates an effective but natural barrier to sex between greatly disimilar organisms in that the DNA of their offspring are highly unlikly to code for a well adatped organism. It also has other side effects such as making virus infected bots less likely to produce viable offspring via sex.
My choice of the terms male and female is perhaps unfortunate and you may be reading more into my use of those terms than is warrented. My thinking was thus: for this kind of proximity-based sex (as opposed to egg based or other time-shifted reproduction) I thought it best that the offspring be "birthed" from one or the other of the parents. The species level information (as we currently use the term) as well as genetic memory, space for the offspring and so on needs to come from only one of the parents, otherwise many things (such as graphs) will break or require significant changes. I also thought continuing with the birth tie concept was appropriate in this case. So, I'm using the term female for the parent from which this information comes. I like my implimentation as I think it encourages some interesting dymanics w.r.t. sexual selection, but I'm open to discussion on what specific mechanism we use for choosing which parent this info should be based upon as well as the nrg/resoruce contribution split between parents.
shvarz:
Sounds good to me. I'd suggest that "cross" command would not signify a required switch, but rather be a "possible switch" site. Say a 50/50 probability. This way multiple reproduction events between two identical (not identical to each other, but the same for all repros) bots would give a whole range of possible off-springs. Some of them might turn out to be viable even if bots are very distantly related.
EricL:
--- Quote from: shvarz ---I'd suggest that "cross" command would not signify a required switch, but rather be a "possible switch" site. Say a 50/50 probability.
--- End quote ---
Sounds good to me. It shall be so.
Navigation
[0] Message Index
[#] Next page
Go to full version