Author Topic: Block coding  (Read 4985 times)

Offline strangers

  • Bot Neophyte
  • *
  • Posts: 37
    • View Profile
Block coding
« on: October 24, 2007, 04:51:01 PM »
Well, as I was staying up last night watching Transformers, I got to thinking, how could one organize bot code and enable sexual reproduction?; and so I thought of block coding, rather than explain I will show:
Code: [Select]
/initialize block
cond
*.robage 0 =
start
200 rnd 55 store
.eye5 .ploc store
256 41 store
7 989 store
stop

cond
start
stop

cond
start
stop
/end block

/search block
cond
*.eye5 0 =
start
mult 50
stop

cond
*.refeye *.myeye !=
*.eye1 *.eye5 >
start
mult -140
stop

cond
*.refeye *.myeye !=
*.eye9 *.eye5 >
start
mult 140
stop

cond
*.refeye *.myeye !=
*.eye3 *.eye5 >
start
mult -70
stop

cond
*.refeye *.myeye !=
*.eye7 *.eye5 >
start
mult 70
stop
/end block

/movement block
cond
*.refeye *.myeye !=
*.eye5 0 >
start
*.refveldx .dx store
*.refvelup 30 add .up store
stop

cond
start
stop

cond
start
stop
/end block

/shoot1 block
cond
*.eye5 40 >
*.refeye 0 =
*.robage 0 !=
start
*.refxpos *.refypos angle .setaim store
.shoot dec
16 .shootval store
*.refvelup .up store
*.refveldx .dx store
stop
/end block

/shoot2 block
cond
*.eye5 40 >
*.refeye *.myeye !=
*.refeye 0 !=
*.refpoison 0 >
*.robage 0 !=
start
*.refxpos *.refypos angle .setaim store
-6 .shoot store
16 .shootval store
*.refvelup .up store
*.refveldx .dx store
stop
/end block

/shoot3 block
cond
*.eye5 40 >
*.refeye *.myeye !=
*.refeye 0 !=
*.refpoison 0 =
*.robage 0 !=
start
*.refxpos *.refypos angle .setaim store
.shoot dec
32 .shootval store
*.refvelup .up store
*.refveldx .dx store
stop
/end block

/shoot4 block
cond
*.shflav 0 !=
*.shflav -2 !=
start
*.shang .aimshoot store
64 .shootval store
-6 .shoot store
0 .shflav store
stop
/end block
See, with each set of genes having a "block", during sexual reproduction the computer could look at the parents blocks and genes and randomly choose which to give to the offspring, and if one has a certain block and the other doesn't it would have a 50/50 chance of receiving the block or not. This would make sexual reproduction les likely to break a bot.
 Each block type would have a gene limit, if your under the limit just add a blank gene:
Code: [Select]
cond
start
stop
or for evolution sims:
cond
00000000000
start
00000000000
stop
This would also open up oppurtunities for new viruses such as:
Code: [Select]
/virus block
cond
*.nrg 1000 >
*.eye5 20 >
start
100 .vshoot store
*.thisblock .mkvirus store
stop

cond
*.myeye 20 !=
start
80 .repro store
300 .vshoot store
stop

cond
*.myeye 20 !=
*.refeye *.myeye =
start
-1 .shoot store
32 .shootval store
*.refxpos *.refypos angle .setaim store
stop
/end block
stop
Block viruses could be limited to just 3 genes, anyless and they'd be no different than regular viruses, possibly even specific block virus sysvars like .bvtimer, .bvshoot, and .mkbvirus.
Any questions, or does it need further explanation?

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Block coding
« Reply #1 on: October 24, 2007, 05:08:51 PM »
The problem is that there's a lot of hard-sets everywhere.  There's a limit on the size of blocks, how many genes they can have, the insides of genes won't get shuffled with the mate's genes, etc. etc.  

Ideally the sexual reproduction would treat the DNA like a long "tape", or string of commands.  It shouldn't have any knowledge of, or respect, genes.  There's a lot involved with sexual reproduction but basically the mechanism most important is "crossing over".

Crossing over shuffles DNA by lining up two like strands and "zipping" them up together as long as they're identical.  If you have enough of these "zipping up" points you'll get all of the DNA except for a few mutation spots.

Then, the strands are swapped in a couple of random locations where they're zipped up.  This helps ensure that the insides of genes can get crossed-over and shuffled, too.

The primary thing preventing it from being coded in the VB version at the moment is that the DNA is built as a flat array, and shufflign two strands together is a headache-prone mess.  Still, we might be able to convince Eric to try if we ask reeeeaaal nice

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Block coding
« Reply #2 on: October 24, 2007, 05:29:36 PM »
The main argument against implementing sexual reproduction in the simulator to date hasn't been about creating descendants with broken DNA or block size or implementation difficulty or anything like that.   It's been that we don't want to hard code anything about mating choice, species determination, DNA structure, cross over points, crossover granulatiry, etc. into the simulator.  How bots chose to reproduce and co-mingle DNA between individules should be evolved.  That has been the argument.

Bots could evolve (or be hand authorred for) sexual reproduction today with no improvements in the simulator.   I've posted about this before here.

The idea is that bots take over their own reproduction using viruses to propagate DNA into their offspring.  New offspring either delete all (or perhaps only half) their DNA at age 1 or do nothing for a long time waiting for a parent to delete it for them using a virus.  The parent(s) then use a different virus (or the same one) to inject whatever DNA (or portion of DNA) they want into the empty husk.  It is not difficult to imagine bots only injecting half their DNA, for offsping to be non-functional until they get injected from two parents, for mechanisms to evolve for parents to chose random (or non-random) portions of their own DNA to inject, for sexes to evolve based upon which DNA portions get injected or which birthed the empty husk (egg) and which provided the virus injection (sperm) , etc.
Many beers....

Offline strangers

  • Bot Neophyte
  • *
  • Posts: 37
    • View Profile
Block coding
« Reply #3 on: October 24, 2007, 06:01:41 PM »
Well, I get the biology stuff, I understand about bots evolving their own repro methods, could you atleast try it for viruses?

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Block coding
« Reply #4 on: October 24, 2007, 06:31:37 PM »
Quote from: strangers
Well, I get the biology stuff, I understand about bots evolving their own repro methods, could you atleast try it for viruses?
I am all for allowing for multi-gene viruses and will be happy to add the necessary code to the simulator.

That said, the work is not trivial and may have some far reaching consequences, so I think a little further discussion of the subject is warrented.

Personally, I think we should allow for viruses to be arbitrary contigious sequences, gene aligned or not.  That is, instead of a virus being a single gene or block of genes, it is a contigious DNA sequence of a given length, which coudl be a partial gene or contain multiple genes.  I suggest modifying .mkvirus to be the starting bp of the sequence to be made into the virus.  I further suggest we add .vlength which would be the length of the sequence to make into the virus.  For completeness, we could add .genenum, .genestart, .geneend, which could be used to find the beginning and ending bp numbers for a gene whose number is stored in .genenum.  We already have .dnalen.

Additionally, I think we should add a mechanism for sequence matching to determine where in the infected bot the viral sequence gets inserted.
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Block coding
« Reply #5 on: October 24, 2007, 07:37:55 PM »
Quote from: EricL
Personally, I think we should allow for viruses to be arbitrary contigious sequences, gene aligned or not. That is, instead of a virus being a single gene or block of genes, it is a contigious DNA sequence of a given length, which coudl be a partial gene or contain multiple genes.

I am for this, too.  Gene boundaries should be incedental to most operations.  Or even eliminated entirely and we could go with a gene-less architecture like I have going on right now in the DB 3 code.

Quote
I suggest modifying .mkvirus to be the starting bp of the sequence to be made into the virus. I further suggest we add .vlength which would be the length of the sequence to make into the virus. For completeness, we could add .genenum, .genestart, .geneend, which could be used to find the beginning and ending bp numbers for a gene whose number is stored in .genenum. We already have .dnalen.

I don't like this.  Not to beat a dead horse, but I don't like giving DNA controls to examine itself.  It just opens up a whole conceptual can of worms, double especially when viruses get involved in the mix.

Another option might be to add new flow controls called virusstart and virusend., that do nothing but control what code gets packed into a virus when some code inside them calls mkvirus.  It's not a great solution, though.  Alternatively, .mkvirus could trigger the creation of a virus from then on, as you suggest, and instead of specifying a length, you could specify a .finishvirus or something similar.

The hard part here is that you need the code that creates the virus to be potentially inside the virus, to create a self replicating monster .

Quote
Additionally, I think we should add a mechanism for sequence matching to determine where in the infected bot the viral sequence gets inserted.

I prefer to think of viruses as self-contained modules.  They contain the code to reproduce themselves, plus whatever baggage they want to carry.  In a scenario like this viruses should either be inserted randomly into the host's genome (maybe upsetting an existing gene, maybe not), or stored in a seperate "strand" and have its effects averaged with the native DNA's.
« Last Edit: October 24, 2007, 07:38:49 PM by Numsgil »

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Block coding
« Reply #6 on: October 25, 2007, 12:21:39 PM »
Quote from: Numsgil
...I don't like giving DNA controls to examine itself.  It just opens up a whole conceptual can of worms, double especially when viruses get involved in the mix.

I don't share your reversion to creating the primitives to allow for self DNA inspection or manipulation.   In fact, as above, I think it is critical to someday allowing the evolution of reproduction and mutation mechanisms outside the simulator.  IMHO, we want an organism to at least have the capability to copy thier own DNA, to copy it inperfectly if selection favors this, to perform their own error analysis or virus infection analysis, to self correct, to evolve virual resistance and so on.  IMHO, the genomorph should absolutely be a battle ground over which evolution presides.

As in nature, there will be good reasons for organisms not to get too crazy with self DNA modification.  Afterall, you can't predict the future.  Pheneotypic selection for reproductive success will still be the prime actor.  Nature could and has evolved DNA inspection and manipualtion machinery yet it is used judiociously and primarly for perserving DNA content over time by improving copying fidelity.   Why?   Because the vast majority of DNA changes are bad for an organism, even if when it is the DNA itself making the changes.    

Quote from: Numsgil
I prefer to think of viruses as self-contained modules.  They contain the code to reproduce themselves, plus whatever baggage they want to carry.  In a scenario like this viruses should either be inserted randomly into the host's genome (maybe upsetting an existing gene, maybe not), or stored in a seperate "strand" and have its effects averaged with the native DNA's.

I disagree here too.  The whole concept of a virus is of a bit of essentially pure information that hijacks the machinery of more physical organisms to do its dirty work, replication cheif amoung that.   Isolating viruses into their own module or thinking of them as somehow self contained and distict of otherwise "different" from the host DNA cuts against this IMHO.  Viruses should be able to hijack existing DNA sequences inside the genes or even hijack entire sets of genes of their host, redirecting that logic to their own ends.  Selection will favor shorter viruses, ones that can take advantage of more existing host DNA so as not to contain that logic themselves.    Many biological viruses do this including HIV, the Flu and all the Herpes variants.  To this end, viruses need some some sort of fine grain mechanism to control where they get inserted in the host genome (a mechanism subject to mutation and selection) and what's more, host organisms must have some way to combat virual infection I.e. to evolve resistance to specific virus strains.

I sugggest sequence matching.  A virus should (perhaps optionally) cotain a taget DNA sequence of arbitray length that the simulator matches to the infected organism's DNA.  If a match is found, the virus is inserted at that point in the target organism.   hHe longer the sequence, the more specific the targetting and the more the virus can assume that it will get inserted in a known species and amoungst DNA it is familar with and can successfully hijack but the easier it is for a mutation in the target species to convey resistance by changing the sequence and foiling the match.
Many beers....

Offline shvarz

  • Bot God
  • *****
  • Posts: 1341
    • View Profile
Block coding
« Reply #7 on: October 25, 2007, 01:50:04 PM »
Quote
viruses need some some sort of fine grain mechanism to control where they get inserted in the host genome

Well, formally that is not correct. Most viruses don't insert their DNA into host DNA at all. Most of those that do - insert almost indiscriminately. What is correct is that viruses "insert" their own instruction in a certain place of host's overall protein machinery. But since in DBs DNA is the machinery, then I guess that sort of qualifies the statement as being largely correct

On the other hand, there are plasmids, which are fairly independent entities in bacterial cells and can duplicate themselves to huge numbers within each cell. So Nums idea is somewhat closer to truth in their case.

I like the sequence-matching idea (in fact, I argued for it for quite some time myself). It also allows natural resistance to viruses (when no match is found).

Quote
Nature could and has evolved DNA inspection and manipualtion machinery yet it is used judiociously and primarly for perserving DNA content over time by improving copying fidelity.

I agree with that - I don't see anything wrong with DNA looking at itself, correcting itself, modifying itself. Our own DNA does it and we are still alive
"Never underestimate the power of stupid things in big numbers" - Serious Sam

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Block coding
« Reply #8 on: October 25, 2007, 02:04:46 PM »
Quote from: EricL
I don't share your reversion to creating the primitives to allow for self DNA inspection or manipulation.   In fact, as above, I think it is critical to someday allowing the evolution of reproduction and mutation mechanisms outside the simulator.  IMHO, we want an organism to at least have the capability to copy thier own DNA, to copy it inperfectly if selection favors this, to perform their own error analysis or virus infection analysis, to self correct, to evolve virual resistance and so on.  IMHO, the genomorph should absolutely be a battle ground over which evolution presides.

My main concerns are:

1.  Bots will be able to effectively eliminate or destroy foreign DNA in a more effective and cheap way than using slime to prevent virus infection, or whatever methods we care to add.  Right now, slime costs a great deal more energy, and is far less effective, than delgene'ing a virus.

2.  Self policing DNA protecting itself against viruses will tend to get shorter over time.  The less to patrol, the easier the job.  This shortening effect will reduce the "wiggle" room for new adaptations.  Real DNA is huge.  Gigabytes and gigabytes of data, a large percentage of which is just along for the ride, and doesn't really do anything one way or another.  That is, self policing DNA creates an implicit cost for DNA length, wether we like that or not.  And costs generally have a simplifying effect on complexity.

3.  Viruses end up with too much power.  Whatever tools we give DNA to police itself, we have to give viruses too.  The result is a powerstruggle between native DNA and viruses where huge swaths of DNA get deleted.  The whole process is destructive, but struggles like this in nature tend to be constructive.  The large sections of dead viruses in our DNA are evidence of this.  Things don't get deleted very often.  Usually they just get turned off.

Quote
I disagree here too.  The whole concept of a virus is of a bit of essentially pure information that hijacks the machinery of more physical organisms to do its dirty work, replication cheif amoung that.   Isolating viruses into their own module or thinking of them as somehow self contained and distict of otherwise "different" from the host DNA cuts against this IMHO.

This I agree with.  Viruses need to be undifferentiated from any native DNA.  Or that should be the goal at any rate.

Quote
Viruses should be able to hijack existing DNA sequences inside the genes or even hijack entire sets of genes of their host, redirecting that logic to their own ends.  Selection will favor shorter viruses, ones that can take advantage of more existing host DNA so as not to contain that logic themselves.    Many biological viruses do this including HIV, the Flu and all the Herpes variants.  To this end, viruses need some some sort of fine grain mechanism to control where they get inserted in the host genome (a mechanism subject to mutation and selection) and what's more, host organisms must have some way to combat virual infection I.e. to evolve resistance to specific virus strains.

The problem with existing DNA is that it's very serial.  Gene A is executed before gene B, resulting in a long assembly-line like progression from the start of the DNA to the end.  The problem with this structure is that problems up stream can totally break things downstream.  And anything at the very end of the DNA can override anything done earlier in the process.  The whole genome is so tightly coupled that changes, from viruses or mutations, cause catastrophic failures in any but the simplest DNA.

Jaron's world (seriously read this article if you haven't before continuing my post) recently talked about synthetic biology's potential, relating it to software and hardware.  I've been thinking a lot about this recently, and the conclusion I've come to is that the reason software progresses so slowly is that it's so tightly coupled.  You can't grab microsoft word and throw it into world of warcraft to make an in-game text editor.

So what I'm trying to suggest for DNA is that we move away from the serial strand and move towards a more parallel structure, where genes form an interconnected web, communicating with each other only indirectly through the byproducts of their actions.  I don't know if a purely parallel structure is even possible, but it's an ideal I'd like to move towards.  By specifically limiting what a gene can know about other genes, we force them to decouple.

In such a system, the idea of coupling a virus to a set of genes is bogus.  Genes are always in a state of flux, potentially changing from organism to organism through mutations, or whatever.  Genes are black-boxes to other genes, and don't know or care about each other's existance.  Instead, the virus can hijack existing pathways by meddling in the same collective soup that other genes use to communicate.  If gene A produces X, and gene B regulates body growth by a feedback with X, a virus can cause mischief by metabolizing X, or producing more X.  The virus *might* be somewhat coupled to the pathway, but it neither knows nor cares about what genes use X.

The way I'm presently imagining such a system working is to have several strands that run in serial inside the strand, but that communicate with each other through this web structure of ins and outs in parallel.  A virus would just be a strand that can build a virus shot for itself and climb inside.
« Last Edit: October 25, 2007, 02:08:06 PM by Numsgil »

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Block coding
« Reply #9 on: October 26, 2007, 12:59:33 PM »
Quote from: Numsgil
1.  Bots will be able to effectively eliminate or destroy foreign DNA in a more effective and cheap way than using slime to prevent virus infection, or whatever methods we care to add.  Right now, slime costs a great deal more energy, and is far less effective, than delgene'ing a virus.
I don't see this.  If a virus need not be its own self contained gene, if it can be inserted inside an existing gene, of be a set of genes, then it becomes much more difficult for the host organism to isloate and remove it than today with .delgene, even if it has the DNA inspection and manipulation primitives to theoretically do so.  Knowing you are infected through a checksum or similar mechanism is one thing.  Knowing where, how and being able to reverse it is entirely different.  Viruses can work to actively prevent this, deleting protection machinery, chanign their sequences, etc.  I used to work in the anti computer virus space.  Detecting is relatively easy.  Reversing is difficult to impossible if the virus got even a single cycle of execution.

Slime would still work.  Think of it as skin.   It's expensive but important.

Quote from: Numsgil
2.  Self policing DNA protecting itself against viruses will tend to get shorter over time.  The less to patrol, the easier the job.  This shortening effect will reduce the "wiggle" room for new adaptations.  Real DNA is huge.  Gigabytes and gigabytes of data, a large percentage of which is just along for the ride, and doesn't really do anything one way or another.  That is, self policing DNA creates an implicit cost for DNA length, wether we like that or not.  And costs generally have a simplifying effect on complexity.
I'm not sure I buy this.  I could make the opposite argument I.e. having a larger genome with a larger number of decoy sequences increases the chances that if and when an infection occurs, the virus will be inserted into a nonfunctional psuedogene.  I'm also not convinced that self policing/correction logic is worth it the cost of that logic.  It may be that once infected, organisms are doomed and instead selection favors an arms race on the battle front of mutations changing the matching sequence.

Quote from: Numsgil
3.  Viruses end up with too much power.  Whatever tools we give DNA to police itself, we have to give viruses too.  The result is a powerstruggle between native DNA and viruses where huge swaths of DNA get deleted.  The whole process is destructive, but struggles like this in nature tend to be constructive.  The large sections of dead viruses in our DNA are evidence of this.  Things don't get deleted very often.  Usually they just get turned off.
Slime still works.  We could enforce a minimum legnth on the matching sequence if we wanted to reduce the probabiltiy of matching anything and everything.  There are still details to be worked out to be sure and you may be right in that we will need to counterbalance the strength of viruses with other mechanisms.  But I do think it's an interesting battlefront for evolution to play on.
Many beers....

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Block coding
« Reply #10 on: October 26, 2007, 01:36:37 PM »
Quote from: Numsgil
Jaron's world (seriously read this article if you haven't before continuing my post) recently talked about synthetic biology's potential, relating it to software and hardware.  I've been thinking a lot about this recently, and the conclusion I've come to is that the reason software progresses so slowly is that it's so tightly coupled.  You can't grab microsoft word and throw it into world of warcraft to make an in-game text editor.

I read the article.  I disgree with many of his statements and conclusions.  Typical of many science writers, he has a niave view of the realities of software development.   New word processors on new computers open new documents at about the same speed as old word processors do on old computers because they are doing so much more on that open then the older code did (new features, new content types, etc.) and also because engineers don't focus on the performance of a certain task once that performance becomes acceptable on the hardware the typical customer is expected to use for that release.  It has nothing to do with "software getting worse over time" or any other such nonsense.  The hardware performance may have increased a thousand fold (not the disk seeks per second though, which is a main aspect of program and document load time) but the software has similarly increased it's functionality over the same time period.

He also misses a huge point in that the complexity of software does not necessarily improve with time, size, increasing hardware speed or number of programmers.  It gets bigger, wider, but not necessarily more complex.  The human brain is the limiting factor.  We don't build sofware the way nature builds things.  It's highly compartmentailized, not nearly as interconnected, etc.  We do this for many reasons not the least of which is that without compartmentalization, it would be impossibile to support or to transfer code ownership.  But the main reason is that the human brain isn't good at thinking about things that have thouasands or tens of thousands of interconnections (like neurons).  The human brain is good at thinking about things that have about 7 parts or connections and if it has more than 7 parts, we break a part down into 7 subparts and so on.

Software progresses slowly not because it is tightly coupled as you say.  Software progresses slowly because it is written by humans with human brains.  Being tightly coupled is a side effect of this.  There may be problems whcih cannot be solved by typical human programming methods.  This is a theme in my book actually adn one reason why I find breeding software so appealing I.e. becuase it holds promise to solving such problems, to producing software complexity no human developer can acheive.

Quote from: Numsgil
So what I'm trying to suggest for DNA is that we move away from the serial strand and move towards a more parallel structure, where genes form an interconnected web, communicating with each other only indirectly through the byproducts of their actions.  I don't know if a purely parallel structure is even possible, but it's an ideal I'd like to move towards.  By specifically limiting what a gene can know about other genes, we force them to decouple.
I don't disagree.   I'm a big fan of codules, but they won't be implemented in the VB version.
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Block coding
« Reply #11 on: October 26, 2007, 09:31:25 PM »
I don't think we're going to convince each other, so I'll bow to popular opinion.  If others want the DNA to have the power to govern itself, then I'll hold my tongue.  I just think it will hamper complexity.

Offline Welwordion

  • Bot Destroyer
  • ***
  • Posts: 325
    • View Profile
Block coding
« Reply #12 on: November 30, 2007, 06:57:13 PM »
First:
The basic unit of Darwinbots Dna is not what we have named Gene, the true Gene( in that it function is the equivalent of a biological gene) consists of:
1)a store or inc or dec command
2) the code that produces the numbers used by these commands
3) the conditions attached to the fragments of code.

For this reason a virus that addresses DNA from point A to point B might be less constricting, but not less artificial than a virus that transfers a genome cause the parts of a true gene are not necessarily spatially close to each other.
For this I would propose a numeration of genes according to store, inc dec commands and the viruses as well as delgene should use a tracking back mechanism to identify the parts belonging together.
(beware of dup commands as when two or more genes share the values copied by those only the dup command has to be deleted)

Second: Independant of what system of numeration you choose, it is true that, as long a genes work not parallel, the order of genes is important .
Particularly genes that store to the same numbers tend to make their predecessors inactive.(The rule here is if the memory locations that are stored in, are not referred too by other true genes before the new gene, the previous gene is inactive)
To solve this order problem in regards to reproduction schemes, without making viruses to powerful, I propose that  there is a variant of .delgene (or its could be done  by .sexrepro) that leaves an interface a placeholder behind.
This interface basically has 2 functions, it keeps the current numeration intact by reserving a number and
when a virus is inserted into the bot the virus will be placed into the reserved spot, instead of the end of the genome.

Third: There are some thinks like the supposed slow process of software I have my doubt or thoughts about but for reasons of quality and cause I do not have a hundred percent clear opinion yet I will be silent about these for now.
The only thinks I would like to say is what I said already a long time ago many of the solutions, features implemented and proposed to darwinbots are a little artificial compared to their purpose and the inherent structures that predated them, sometimes a little bit more careful and indeep consideration has to be done cause for DNA development easier can often be better (but beware of to easy solutions that destroy complexity)
« Last Edit: November 30, 2007, 07:05:05 PM by Welwordion »