Code center > Darwinbots3

Anyone out there?

<< < (3/5) > >>

Numsgil:

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

...

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.

--- End quote ---

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.
--- End quote ---

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.
--- End quote ---

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.
--- End quote ---

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.

bacillus:
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.

Numsgil:
The problem is constructing the grid.  The command set can be something like 3 dozen or more

abyaly:
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.

Numsgil:
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page