Author Topic: Anyone out there?  (Read 8107 times)

Offline trimalchio

  • Bot Neophyte
  • *
  • Posts: 5
    • View Profile
Anyone out there?
« on: February 12, 2009, 01:53:48 PM »
I'm still not sure what's going on with this community here, but this program is very interesting. If you're making Darwinbots 3, that's fine, but it doesn't seem to be moving very fast. I have many ideas about a similar evo/sim but it goes in a very different direction than what you seem to be visualizing. In fact, what I have in mind would be very different from what Darwinbots is or will be. I should probably look harder to see if anyone else is doing what I'm thinking, but it doesn't seem to be out there. Anyway, I have experience in C++/Java, I could learn C#, I'd rather not learn VB, and I am interested in making my own program, probably in Java for various reasons. I've never worked on a team programming project before, and I'll probably lose interest in a week or two. If there is actually anyone here, I would appreciate talking about whether I would help this project or do my own thing. I think that my ideas are strong and practical, and could eventually become a useful program. Anyway, I'd just like to know if there's actually anyone here, since there seem to be about six posts in the last month. I suppose I should get started. I could explain what I'm thinking if anyone is interested.
« Last Edit: February 12, 2009, 02:05:56 PM by trimalchio »

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Anyone out there?
« Reply #1 on: February 13, 2009, 06:33:51 AM »
I'm here at least   The forum kind of goes through spurts of busy and dead.

Progress on DB3 is indeed slow.  I haven't done anything with it in about a month (taking a vacation sort of), but when I left off I was trying to figure out a good way to build some data centric unit test functionality into the unit testing framework I built.  Nevermind if that doesn't make any sense

If you think it's unlikely that you'll actually finish anything you start, it would make more sense working on DB3 with me since at least then you'll have accomplished something worthwhile.  Also fee free to explain what you were thinking.  I won't make any guarantees about anything, but if nothing else I can give you some feedback.

If you want to work on DB3, I can probably find something interesting for you to work on (Incedentally if you know Java you'll find C# very easy to pick up.  I found it easy to move to Java from C#).  What sort of things do you have experience with programming?  For instance, one thing that needs doing is moving some unit tests I wrote using this one library to using this other library I wrote just for DB.  It isn't all that sexy a task, but it would be a finite task and a good way to kind of figure out the code that exists right now.

Offline Testlund

  • Bot God
  • *****
  • Posts: 1574
    • View Profile
Anyone out there?
« Reply #2 on: February 14, 2009, 09:31:54 AM »
The whole a-life scene is the slowest software technology of all. DB is the most advanced one which have gotten new versions released quite often.
I guess the reason why a-life is such a slow business is probably because it's very difficult to program with little economic reward. So programmers tend to play around with it on their free time. Is that a right assumption, Nums?
The internet is corrupt and controlled by criminally minded people.

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Anyone out there?
« Reply #3 on: February 14, 2009, 10:10:50 AM »
Yeah, that seems to be the case.  Occasionally there are commercial alife games (Creatures and Darwin Pond come to mind), but they're lucky to break even on development costs.  It requires a level of patience most users just don't have, so its commercial appeal is really limited.

On the technical side it's at least as complex as any other game.  Sometimes more so because it has to be pretty stable and bug free (if Civ4 or Fallout 3 crashed every 12 hours, it wouldn't be the end of the world.  If your alife sim crashed every 12 hours, it would literally be the end of the world )

Offline Testlund

  • Bot God
  • *****
  • Posts: 1574
    • View Profile
Anyone out there?
« Reply #4 on: February 15, 2009, 12:35:18 PM »
Quote from: Numsgil
Sometimes more so because it has to be pretty stable and bug free (if Civ4 or Fallout 3 crashed every 12 hours, it wouldn't be the end of the world.  If your alife sim crashed every 12 hours, it would literally be the end of the world )

Yeah, definitely! I never thought of it that way.  
The internet is corrupt and controlled by criminally minded people.

Offline Endy

  • Bot Overlord
  • ****
  • Posts: 852
    • View Profile
Anyone out there?
« Reply #5 on: February 15, 2009, 07:21:22 PM »
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.

Offline trimalchio

  • Bot Neophyte
  • *
  • Posts: 5
    • View Profile
Anyone out there?
« Reply #6 on: February 16, 2009, 10:00:16 PM »
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.

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Anyone out there?
« Reply #7 on: February 17, 2009, 08:49:51 AM »
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:

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.

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.

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.

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.

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.
« Last Edit: February 17, 2009, 08:51:30 AM by Numsgil »

Offline ikke

  • Bot Destroyer
  • ***
  • Posts: 300
    • View Profile
Anyone out there?
« Reply #8 on: February 17, 2009, 10:28:55 AM »
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.
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.
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

Offline trimalchio

  • Bot Neophyte
  • *
  • Posts: 5
    • View Profile
Anyone out there?
« Reply #9 on: February 17, 2009, 11:07:12 AM »
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...

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.

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Anyone out there?
« Reply #10 on: February 17, 2009, 11:28:27 AM »
Quote from: 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...

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.

...

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.

I'm not a fan of cost-at-birth.  I see where you're coming from with it, but I don't think it'll work as well as you think.

Instead, think of it as a "flatness" coefficient to the efficiency curve for a motor.  Most real world motors have an efficiency curve (see this).  Basically as the motor goes past its full load amount, it becomes less efficient (takes more energy per horsepower).  So a marathon motor would have high efficiency but a low full load amount.  It would produce very little thrust, but be able to sustain it for a long time.  A real world example in space might be an ion drive.  A fast twitch motor would have lower efficiency but a higher full load amount.  It could produce some really impressive thrust amounts, but a bot could only sustain it for a short time.  A real world example being current chemical rockets.  

They'd cost the same at birth, and the bots can even choose some combination between the two.  They just differ in their optimal use.  A prey animal might decide on a marathon motor, and just pay the extra energy if it has to go fast (run for its life).  A predator might decide on a fast twitch motor, basically not moving for most of the time and suddenly sprinting effortlessly to catch dinner.  That's how cheetahs hunt and live their lives.  Either motor can be used for either purpose (a cheetah can walk across the entire Savannah, and a prey animal can run very fast), but they're more efficient in their respective roles.

The point here is you want to be careful not to confuse how a motor is used during the lifetime of a critter, and how expensive it is to produce at birth.  Because expense at birth defines r-k selection, which can be entirely independent of how an animal otherwise lives its life.

Quote
I'll try to get DB3 working if I can. I'll think about some other ways to improve stuff.

Let me know how it goes

Quote
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.

Yeah, I had that issue with Darwinbots.  The current program is terrible at figuring out good values to replace existing ones with.  So instead of playing with it that way, in the new version I just normalize all actions over some range (-1000 to 1000 I think).  That way as long as you pick a value between -1000 and 1000, you're assured at having a meaningful mutation.

Quote
Changing (8 .shoot store) to (8 .mrepro store) is also bad.

Usually yes, but often times useful behavior results.  I've seen plants evolve to move instead of turn when they want to reproduce.  The move genome always outcompetes the turn genome.
« Last Edit: February 17, 2009, 11:31:30 AM by Numsgil »

Offline bacillus

  • Bot Overlord
  • ****
  • Posts: 907
    • View Profile
Anyone out there?
« Reply #11 on: March 13, 2009, 08:53:47 PM »
Hmm. Some interesting ideas coming through there, I think the parts may be a bit too specific, and would severely hinder the creation of single-celled organsims. What if sight, motion etc. were just components of a cell that can be invested in, while capping the amount of functionalities a cell can handle? That way, single-celled organsims can be built, while more complex organsims can make specialized cells, and even have access to certain 'specialist' cells that have some unique ability, such as breaking down venom and waste, which cannot support any secondary functions.

I agree with the argument of the mutations; the best way to resolve this issue would be some kind of mutation matrix, where similar functions/parameters are placed side-by-side, and instead of picking a competely random value, shifts the value to a nearby value. With a static grid, this shouldn't be too memory-intensive.
« Last Edit: March 13, 2009, 08:58:46 PM by bacillus »
"They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown."
- Carl Sagan

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Anyone out there?
« Reply #12 on: March 14, 2009, 05:09:07 PM »
The problem is constructing the grid.  The command set can be something like 3 dozen or more

Offline abyaly

  • Bot Destroyer
  • ***
  • Posts: 363
    • View Profile
Anyone out there?
« Reply #13 on: March 15, 2009, 12:06:35 AM »
It doesn't even need to be a grid. They could just be partitioned into (configurable?) subsets and set up so that moving within a subset is easier than branching into another one.
Lancre operated on the feudal system, which was to say, everyone feuded all
the time and handed on the fight to their descendants.
        -- (Terry Pratchett, Carpe Jugulum)

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Anyone out there?
« Reply #14 on: March 15, 2009, 07:36:53 AM »
Then you get into fuzzy areas.  Like do you group commands based on increasing vs. decreasing (so add and mult are grouped together, div and sub are grouped together).  Or do you group based on unary vs. binary.  Or based on which stacks they work with.