Code center > Darwinbots3

Anyone out there?

<< < (2/5) > >>

Endy:
I was thinking that one designed around bot vs. bot battles could work. You could set up an internet match system and make the design stage easier.

trimalchio:
I was sort of depressed when I made my first paragraph-less mushy post, but I've decided that starting my own project is a poor decision. I could help with DB3, as long as you aren't serious about the 3D thing. That seems to be what mostly put me off. It would make every other part of the program many times harder, but I suppose you've thought about this more than me already. Anyway, I've looked at your ideas so far, and I'll just ramble and hope some ideas emerge:

Similar to certain compression algorithms, each bot would have a "library" or "table" of body parts, such as an eyespot or motor. It would be defined by a polygon, perhaps with enforced symmetry, with each segment referencing a part in the library. Mutations would jitter the points defining the segments, and the length of the segment would determine how powerful that part is. Larger eyes would see farther. Larger motors would push harder. The library would also define an efficiency for the part, which would be some sort of ratio between the cost for each part at reproduction and the cost to use it. A motor on the back of a small prey bot would be inexpensive at birth but expensive to use, since it wouldn't be used much except to run from a predator. A predator bot would have an expensive motor at birth but cheap to use, since it would move around chasing so often. Other parts would work similarly. Part 0 would be the standard skin, which could have toughness, color, friction, bounce, or whatever. A high enough friction could become a sticker for parasite gnat bots. Color might be visible to advanced eyes, or perhaps each eye would be sensitive to certain color ranges. An eye might only return a positive number if it sees green, for plants. This brings me to the hardest part of the whole thing, which seems to be necessary to make truly interesting evolution bots: a neural network. They are very complicated, but I think I have a simple way to make them work using matrix multiplication. The size of the table would be proportional to the square of the number of line segments on the bot, plus some. I'll explain later. It might not work. I haven't had any way to test it yet, but it seems robust and computationally efficient. Each part would get its own "neuron" which would serve as input/output/both for the part. The eye neuron would respond to the eye seeing its favorite color. The motor neuron wouldn't really serve as an input, but move when the other neurons influenced it. Perhaps the motor neuron may respond when the bot smacks into a wall. The skin would respond to touch. A chameleon bot might be able to change color. If an eye is attacked, the neuron would max out with pain. A poison spot might release poison when its neuron is excited, respond to touch, and therefore release poison when anything touches it. A plant might have photosynthesis spots for skin. A part could be a mouth, which could pull other bots when its neuron is activated and respond to taste, or negatively to poison. That way it would automatically "swallow" if it tastes food or spit out poison. The sticker could simply respond when it sticks to something. The sticker would be very helpful for any multibots, being able to make a circle easily, since other shapes would be impossible if the stickers were placed correctly. Blobs would be even easier. Mutation would be simple and robust, change the library value of a segment here, split a segment in two there, switch two library parts, delete a part, jitter segment points, shuffle this, randomize that, whatever. Sexrepro would work pretty well, too. If a part referenced a library position that didn't exist or was out of range, it could be expressed as part 0, or perhaps modded around. This would even allow for recessive genes and more interesting hybrids. Hybrids from completely different species wouldn't work almost every time, which is good. They would die a mutanty death. Bots could also have specialized repro spots, which wouldn't copy all the genes. Perhaps a bot might want to reproduce a small, sterile, simple, cheap, suicide/search minibot. It could perhaps copy the mouth and motor only. This would greatly encourage multibot specialization, with starting "stem cells" that systematically produce simpler bots around it with partial DNA. I need to wrap this up, this is one of the longest forum posts ever. I think that's about all. Fluid dynamics is too hard, and would go with the env grid. There must be a better way, so I'll think about it. Oh, I almost forgot: the neural network is able to learn and adapt faster and smarter than mutation. I think this about covers it. The relationship between mutation and learning is very important. If you've gotten this far, I congratulate you. I'll see what I can do with what you've got so far if I happen to find a few hours of free time lying around. Could I borrow some paragraphs from someone so my posts aren't all in one blob? If you have any questions, read it again. Maybe even three or four times. Five couldn't hurt. I haven't said anything useful for a while now, so I'll push the Add reply button now.

Numsgil:

--- Quote from: trimalchio ---I was sort of depressed when I made my first paragraph-less mushy post, but I've decided that starting my own project is a poor decision. I could help with DB3, as long as you aren't serious about the 3D thing. That seems to be what mostly put me off. It would make every other part of the program many times harder, but I suppose you've thought about this more than me already. Anyway, I've looked at your ideas so far, and I'll just ramble and hope some ideas emerge:
--- End quote ---

Nah, I've abandoned 3D for the time being.  It... complicates things.  It's doable but for another time.


--- Quote ---Similar to certain compression algorithms, each bot would have a "library" or "table" of body parts, such as an eyespot or motor. It would be defined by a polygon, perhaps with enforced symmetry, with each segment referencing a part in the library. Mutations would jitter the points defining the segments, and the length of the segment would determine how powerful that part is. Larger eyes would see farther. Larger motors would push harder.
--- End quote ---

Sounds reasonable for an alife sim.  I've even been sort of toying with making Darwinbots along those lines, and have bots make certain strategic reinvestments in its parts during life to enhance the features it uses more.  If you haven't yet, check out Genepool.  It's a pretty simple little alife sim, but it has some neat emergent properties with the bodies of the swimmers.


--- Quote ---The library would also define an efficiency for the part, which would be some sort of ratio between the cost for each part at reproduction and the cost to use it. A motor on the back of a small prey bot would be inexpensive at birth but expensive to use, since it wouldn't be used much except to run from a predator. A predator bot would have an expensive motor at birth but cheap to use, since it would move around chasing so often. Other parts would work similarly.
--- End quote ---

I think you're underestimating the prey.  I'd bet at the end you'd have predators and prey with similar motors.  Instead, you might want to consider a fast twitch vs. marathon type motor.  Like a cheetah motor would give great bursts of speed but consume crazy amounts of energy to do it.  A marathon motor is capable of almost continous motion cheaply, but isn't capable of great bursts of speed.  And you could have a gradient between the two types.  That more closely models the way actual animals work.

That may or may not also address the size issues between an elephant and a mouse.  An elephant is so huge that it needs a more marathon type motor compared to the mouse.  But elephants are also capable of some pretty impressive bursts in speed, well above and beyond how fast a mouse can go...


--- Quote ---This brings me to the hardest part of the whole thing, which seems to be necessary to make truly interesting evolution bots: a neural network. They are very complicated, but I think I have a simple way to make them work using matrix multiplication. The size of the table would be proportional to the square of the number of line segments on the bot, plus some. I'll explain later. It might not work. I haven't had any way to test it yet, but it seems robust and computationally efficient. Each part would get its own "neuron" which would serve as input/output/both for the part. The eye neuron would respond to the eye seeing its favorite color. The motor neuron wouldn't really serve as an input, but move when the other neurons influenced it. Perhaps the motor neuron may respond when the bot smacks into a wall.
--- End quote ---

Personally I don't put quite as much stock in neural nets.  They're useful for purposes where you have a non changing problem and goal, with a lot of fuzzy factors that are hard to take in to account.  Handwritting recognition for instance.  Present neural net technology is way too limiting for something meant to be alive IMO.  You have to "train" them, and self training neural nets are at present a joke.

One thing I don't think is tried very often is a less time discrete model.  Like in the first step signals from the input neurons travel to the next neuron.  At each step, signals travel only to adjacent neurons, so the system isn't flushed after every step through.  Run some arbitrary number of steps per cycle in your sim.  You might see some more interesting behaviors.  Maybe not.


--- Quote ---I need to wrap this up, this is one of the longest forum posts ever.

...

If you've gotten this far, I congratulate you.
--- End quote ---

Other than the lack of paragraph breaks that was nothing.  You should see some of our older posts

If/when you try to get DB3 running, check out this page.  Let me know if/when you get confused, frustrated, or whatever.

ikke:
Short on time. Been thinking about it though

--- Quote from: trimalchio ---It would make every other part of the program many times harder, but I suppose you've thought about this more than me already.
--- End quote ---
It would require recoding which is not the same. A consistent (vector&matrix) approach would make code more transparent and easier to modify

--- Quote from: trimalchio ---Similar to certain compression algorithms, each bot would have a "library" or "table" of body parts, such.....
 now.
--- End quote ---
Along similar lines but more close to current DB: Add a specialize command for a cell. Something like .shoot (or .up or .repro or whatever) .specialize .store
Give specialised cells a bonus (or non specialised cells a penalty) of some sorts when executing the command. This favours multibots with specialised cells. Of course .specialize has a cost (or is hard coded to be a single time event). No need for a body part table. If you want it define .bodypart yourself

trimalchio:

--- Quote ---I think you're underestimating the prey. I'd bet at the end you'd have predators and prey with similar motors. Instead, you might want to consider a fast twitch vs. marathon type motor. Like a cheetah motor would give great bursts of speed but consume crazy amounts of energy to do it. A marathon motor is capable of almost continous motion cheaply, but isn't capable of great bursts of speed. And you could have a gradient between the two types. That more closely models the way actual animals work.

That may or may not also address the size issues between an elephant and a mouse. An elephant is so huge that it needs a more marathon type motor compared to the mouse. But elephants are also capable of some pretty impressive bursts in speed, well above and beyond how fast a mouse can go...
--- End quote ---

That's very close to what I was saying: the marathon motors are expensive at birth, so they would be smaller. The twitch ones are cheap at birth, but expensive to run, so they could be bigger. The bigger ones would go faster, no matter which type.

Also, I was thinking of each bot having a distinct body shape with different line segments as functional parts. The neural network does sound too ambitious, so I suppose I'll drop that for now. I do think my way would theoretically work well. Without the network, the parts thing wouldn't work either, and you would end up with what you seem to have now. I'll try to get DB3 working if I can. I'll think about some other ways to improve stuff.

See my nice paragraphs?

I think the (cost at birth)/(cost for use) relationship would work well, and would be a model for metabolism to build on. The plants could have an expensive shell at birth, costing energy for .repro, or a cheap shell that would lose more energy when they were attacked.

The mutations also need to be able to change numeric constants by little bits, such as changing (8 .shoot store) to (10 .shoot store). Changing (8 .shoot store) to (469 .shoot store) is not helpful or realistic. Changing (8 .shoot store) to (8 .mrepro store) is also bad.

Navigation

[0] Message Index

[#] Next page

[*] Previous page