Cellular Turing Machines(Creature Genetics and Development)

Rewritten on 1/12/11
Genetic code for these creatures is going to be an 11 character language based off brainfuck. The commands for the creatures is as follows:
  • '<' and '>' increment/decrement the pointer to the primary node.
  • 'v' and '^' increment/decrement the pointer to the secondary node.
  • '.' link the secondary node and the primary node. If the two already linked, do nothing.
  • ',' unlink the primary and secondary nodes if they are linked, else do nothing.
  • '+' and '-' increment/decrement the value of the primary node (note that this value is cyclic!).
  • '[' and ']' will preform looping functions, as in brainfuck. The loop terminates when the value a the primary node is zero when a check is made.
  • '*' is a special character--it does nothing in the developmental code. Instead, it's used to mate creatures, maybe even to speciate them in a later version: '*'s are point of possible crossover. Actually, this command is where I can't wait to see what the program does. How will these characters, which have nothing directly to do with fitness, position themselves in the genome? Will it be random, haphazardly strewn around in the middle of loops and such? Could these start to partition off genes somehow, segments of the program which are independent from each other? I hope it's the latter. It would be really neat to see the evolution of alleles and such--some kind of more complex genetic code.

To ensure we aren't infinite looping, I'll probably limit the number of commands a creature can execute somehow--perhaps based on it's ancestral build times. Once a creature has been built from it's program, it needs to be cleaned up a little bit: we want to be sure that only one creature was built, and we don't want a bunch of unlinked nodes floating around. I'm going to take the build results and find the largest connected bunch of nodes--that'll be called the creature, and that'll be what is tested.

As for development, I see one important characteristic: I want determinism. There should be no chance that a single program creates radically different creatures every time it's run. If something works, I want to be able to go back and see exactly why. I fiddled around with the idea of some kind of pseudorandom placing of nodes before linking, but eventually rejected it on the grounds that I don't want some hidden pattern in the pseudorandom generator to influence evolution. I want all the patterns of evolution to be quite out in the open, and this includes developmental patterns.

I still have one qualm--I want chance to be part of the process. If I run this program twice, I expect slightly different results from the same starting conditions. I think, however, that I'll introduce this randomness into the environment, not into the development of the creatures themselves. Nodes will initially be laid out in a gigantic + sign, indexes spiraling clockwise from the crossing. Negative indexes will be converted to positive indexes in such a way that decreasing (i.e. increasing in magnitude) negative indexes will spiral counterclockwise. I'm going to make all the links, do the node culling process, then put the creature through a few rounds of the physics engine in zero gravity to pop it into an equilibrium shape, then a few more in gravity to get it ready to be simulated (we wouldn't want any gigantic one-shot springs winning the day, although I don't think my physics system will allow such creatures to exist anyways.).

This leaves four big (and not unrelated) problems to consider before I get down to the dirty part of coding:
  1. The physics simulation (which I have a basic plan for already).
  2. How fitness is determined (again, I have an idea).
  3. How this fitness affects what the program does with the creature.
  4. How mating of two creatures works.
Topic 1 will be the focus of the next post, 2, 3, and 4 the post after.


No comments:

Post a Comment