I'm hoping to encourage some brainstorming about new DNA forms here. I'll start with some of my own observations and ideas:
1. First, the current DNA system has lead me to a strong conclusion. The stack is very easily manipulated by evolution. The memory locations much less so. A new system should take advantage of the stack more fully, and reduce or eliminate dependence on memory locations.
2. Viruses are key to most evo sims. They should be encouraged. But their method of propagation is a little overpowered in the current system, I think. It should be easier for bots to spread viruses, and more difficult for viruses to enter a non receptive host.
3. The linear nature of current DNA is limiting. It should be easier for bots to run several much shorter strands in "parallel" than one long, linear one. Especially with something like viruses, induced behavior should be additive and not necessarily disrupt existing behavior.
4. Conditions shouldn't be separated from the stores that they influence. Something like:
cond
*.nrg 5000 >
start
50 .repro store
stop
Would be better off looking like this:
*nrg 5000 > 50 .repro store
Maybe remove all the flow commands, or keep just start and stop (for junk DNA purposes). I'm not quite sure how a system like this would work, but probably the condition operators (>, <, etc.) toggle whether stores work or not.
Probably there would be a parallel boolean stack (as there is now), and stores simply check against the top of this stack to see if they are active or not.
5. DNA commands should be easily performed and understood by a human. Things like the bitwise operators tend to make the DNA look even more indecipherable than is necessary. Evolution will use whatever tools it has at hand, but humans don't like doing bitwise ANDing in their heads.
6.
Codules (basically sub functions that can't be set up recursively) are important for allowing branching logic. I'm further advancing the idea that there would be "core" codules that interact in very defined ways, passing control to each other, and lesser codules, that act simply as functions, returning when they're done to where they were called.
7. Probably something like half of the sysvars relate to vectors in one way or another. I'm playing with the idea of using vectors as the basic type instead of integers. But it's not as easy to do as I would like, so I may just sit on this idea. Basically, it would be alot better to do something like:
*.refvel .move store
instead of
*.refvelup .up store
*.refveldx .dx store
8. It's unrealistic to know exact details about your position, orientation, etc. I'd move sysvars towards being entirely relative. Sysvars would return information as if the bot is stationary and at the world origin (0,0).
9. Arbitrary values need to be removed where appropriate. For instance, instead of 100 .shootval store -2 .shoot store you might do something like 100 .nrgshot store. Eyes also should probably be redone to return values representing distance more accurately.
10. Most sysvars should be reworked to accept and return values in a normalized range. Something like -1000, 1000.
11. I was also playing with the idea of having all values be floating point in the range -1 to 1, but there are some places where this doesn't work out well (such as .body for instance)
12. Where possible, sysvars should give and return information. That is, act as both input and output.
13. As a general rule, passing A to a sysvar and passing B to a sysvar should mean that passing their average gives a result that is related to A and B. For instance, while -2 and -6 shots are both feeding shots, -4 is not.
14. Where possible, choices should be dumbed down where these choices aren't important. I was toying with the idea of making ties strictly for aggressive feeding and allowing only a single tie to be created per bot. (The connective properties of ties would be moved to another mechanism). Then instead of creating a tie and remembering its number, you'd just have to create a tie. Feeding wouldn't need to know about which tie to use, because there would be only one.
Haven't worked through all the consequences of this yet, but it's the track of thinking I'm on.
StructureThis is the big one. There are several ideas I've toyed with:
- The first involves creating a linear assembly line of codules. Something like a pipeline. After one codule is finished executing, it passes control to the next one, until finally the last one somehow gives values to sysvars to cause action. Mutations could change the order of the codules being executed. The result is somewhat similar to the evolution of metabolic pathways, but it's still too linear for my liking.
- The second involves a web of codules. Each cycle, a codule would receive a stack filled with its input parameters, manipulate those parameters, and produce an output stack (the stack after it's done executing). Codules could be connected to other codules by connecting one's output to another's input. Sysvars would be simple codules that give output and receive input.
The problem is that it would then take several cycles for data to be processed from the inputing sysvars, through the DNA, to the outputing sysvars. Also, this creates a problem when it takes one calculation 2 cycles to do, while a more sophisticated, branching calculation can take 10 or more. DNA would be encouraged to sacrifice sophistication for simplicity, which is backwards of what I'd like to aim to achieve.
- An alternative is to run the DNA several times in a cycle, but here there are issues with how many times to run the DNA.
- Another idea is to simply prevent any looping at all (no recursion), which collapses the web into more of a feed forward neural net. This is what I'm currently thinking.
Input sysvars would pass their values to any codules they're connected to. These codules process their data and send it to the next codule. But I'm not sure how to set it up so that the different execution paths don't end up with a racing condition against each other.
-------------------------------------------------------------
That's pretty much all I have at the moment.
Show Posts
or 