Darwinbots Forum
Code center => Darwinbots3 => Topic started by: Prsn828 on April 29, 2009, 10:45:06 AM
-
I put this poll together real fast, so if you want to add something, please do.
I appreciate any feedback.
-
A species forking system would be interesting, but not that important. It could be left optional, or evaluated only on user command.
I think there should not be specifically assigned veggies, but instead just bots with their body consisting largely of chlorophyll. This has been the single most important feature I've been waiting for in DB3. No more zerosims with complicated feeder shepherds, they can now take care of themselves and still evolve to animals! Chloro, on the other hand, should have some kinds of movement slowing/shot weakening/other downsides, to prevent veggyism from becoming the automatic best solution.
An in-sim DNA editor would definitely be helpful, so that one wouldn't have to constantly reload a sim when tweaking with a bot. As of DNA visibility, it could be done pretty much like it's now: the DNA itself is invisible, but certain aspects of it can be seen through ref-sysvars.
DNA should be quite flexible, allowing complicated structures and maybe some obscure stack manipulation (stacks are preserved betweed codules, perhaps?). But, on the other hand, the sysvars need to be redesigned so that an exact value is seldom needed for a task. If shooting is implemented, it should be broken into as many sysvars as there are shot types, for example. This way, mutations on the control flow and conditional structures could be dramatic, but changing numbers little by little probably wouldn't.
-
We still need to tweak the pros/cons for the different substances, like chlorophyll (which I think we'll call leaves from now on, since that's easier to spell), shell, fat (body), muscle, etc.. It's on my to do list. Mostly there's a lot of thick science-y writing (http://www.nova.edu/ocean/messing/protozoaC.html) I (or anyone else who wants to) need to plow through.
Not in the immediate future, but at some point I think we can do a bot debugger to let you step through bot DNA and see changes to the stack as they happen. And an edit-and-continue feature. For the immediate future, we should be able to let you edit bot DNA and recompile it inside the program. That should be very straightforward.
Codules work sort of like a function, except that the stack isn't modified calling into the codule. So it should allow some complex calls. I'm also playing conceptually with the idea of some sort of preprocessor defines, so you could essentially create your own commands as either a macro or a codule call. So if you want a command that isn't provided, like abssqrt, you could do something like: def abssqrt abs sqrt. At this point I'm mostly considering how it should play with mutations. If the macro is an actual physical codule that mutations can learn to call and mutate, or if it's just inserted into the code like a C/C++ macro.
For sysvars my goal is to "normalize" every one of them to have useful output over the range -1000, 1000. Or maybe -10000 to 10000. And for this range to be continuous without any "magic" values. For things like .shoot, I'll separate out each shot type as its own sysvar. So you'd do .nrgshoot, .venomshoot, etc. etc.
-
Nums, you never cease to amaze me. Honestly though, I have a feeling that if we get a few more votes, it will be clear that the options I intended people to want will be chosen the most
I have a feeling we all want the same things here, give or take an option or two.
-
How important is species forking?
A nice addition. It's nice to be able to keep track of species through generations and it could increase competition between new species that evolves, which could show interesting behaviors. If the number of species are fixed from the beginning it will only end up in species going extinct until you only have one left, at least if you're running a smaller sim. In a larger sim on the other hand you may be able to overcome that by seperating various populations of species into areas where bots can occasionaly wonder between but not completely whipe each other out. Something I haven't tried yet myself though.
Veggies should get energy based on surface area as it is now and should definitely be greenish to resemble clorophyll. The less green the less efficient they should be at getting energy from the sun. Maybe you could make it so they can evolve to change slowly from being autotrophs to heterotrophs for instance (should be able to evolve into animals somehow)?
I would vote for slower veggies, but not as a forced restriction on moving speed, instead the accumulation of sun energy should be too slow for a bot to waste it on swimming around. In my own sims I have restricted the energy intake to 1 per kilobody point for veggies so they can't afford to waste it on swimming.
The DNA questions I have no opinion about but I had to click on something there to make a vote so I chosed other.
-
Would people be interested in a REST based link with the online bestiary?
-
I'll have to change my previous comments a bit, because a thought hit me. In the vision thread someone mentioned linking vision to light, so that bots couldn't see in the dark and would have to use smell, hearing etc. instead. But to have working ecosystems in the dark, we must also have an energy source that isn't dependent on light. So, maybe we could have the substance leaf linked with sunlight, but also explicit veggies that receive energy independent of sunlight, something like chemosynthesis.
-
Hey prsn,
While you're at it, there's an idea I had from a while ago where sunlight would come from the top of the screen and any bots present would cast a shadow under them. We never got anywhere with it, but I think there may have been supporters of this idea other than myself. The intention is to make algae grow in a more "plant-like" manner. For instance, we should start to see stems, leaves, etc... if this change is put into effect. Just an idea.
-
Veggies should have higher costs!
This will promote a more sedentry lifestyle.
If we have chloroplasts/any substance that confers photosynthisis; maybe it should also reduce efficency?
-
How are body substances going to be handled? Although it may be wise to try multiple ideas and test each of them individually, I think the best way to go would be some sort of exponential pricing system. For example, if every 50 units of substance will halve the cost, then 50 muscle and 50 fat will cost way more than 100 muscle or 100 fat. Such a system would allow a large room for single-cell flexibility, but still richly reward a species for multibots and specialized cells. Another idea closely linked to this is paying for chunks of material-if you want to increase your fat storage from A to B in one cycle, an linear approximation of the cost curve results in an overhead paid for large chunks. This encourages bots to increase their storages by small increments, as sudden growth results in extreme wastefulness.
Other methods of handling this could include a body-based material cap, or one requiring a focus on one or two material types, or a mix of these. Anyway, just thought I'd throw a few ideas around, anyone else got any other ideas on the topic of cell materials?
-
I thought I wrote up a topic on this a while back but I can't find it.
I'm not entirely certain what the final system will look like (as you mention, some experimentation is needed), but I think it'll work something like this:
1. Substances are always measured as ratios. Eg: I'm 40% muscle, 60% fat.
2. Bots control which substances are produced each cycle, in what ratios, and how much to make.
3. Bots can try and produce as much of everything as possible, but there's opportunity costs. Muscle requires upkeep, maybe. Fat makes you heavy and less manueverable. Chloroplasts make you very very large (lots of surface area), so other bots can see you from further away. Things like that.
The substances are slow to build up (maybe changes by at most 1% per 100 cycles or something like that), so there's a lot of inertia so bots can't easily change specializations.
-
I can't wait to see the in-sim dna editor. Instead of just reading the dna and moving bots around, you can play a much more active role. Some people might be against it. but I think you should have the options to guide evolution or interfere with the simulation more. Also I like the idea of specialization but how is it going to be done. Do you have to put a comand at the begging of the dna, like you do for custom variables, or is it hidden in the dna. If its at the begging then you could add another mutation type that only affects specialization. A bot loaded into the sim from previous versions would be given default specialization and could change through mutation to suit the bot. Also specialization would evolve to suit the bots behavior better, not the bots behavior adapting to what kind of specialization it has (though it would work the other way around to.) If its hidden in the dna then its alot more fragile and older bots wouldn't be compatible with it (would they?). The whole point of specialization is to cause diversity and encourage complex multibots. Poor zerobots will have another obstacle of evolution to face either way.
-
Specialization will be more of the Lamarckian variety. Ie: inheritable improvement through exercise. Not quite biologically sound, but I think it'll make for the behavior we want.
-
so the bots have to exercise?
-
Yeah, something like that. You shoot a lot and you get better at shooting, etc.
-
So the bots have xp. That could be interesting.
-
Yeah, something like that. You shoot a lot and you get better at shooting, etc.
Sounds very wrong. If you want your bot to learn, program a feedback loop.
-
How does this work for veggies. Do they have to make clorophil (sorry I can't spell) and when they do they get better at it or is it the same as it is now. Sorry, I need to get around to reading all the old threads on db3.
-
Is it going to be that chlorophyll makes the bot big or the larger surface area of the bot the better the bot works, I believe that the 2nd one is more true to life.
-
Yeah, something like that. You shoot a lot and you get better at shooting, etc.
Sounds very wrong. If you want your bot to learn, program a feedback loop.
I am entirely with ikke on this. At least provide an option to turn lamarckian selection off.
-
I wouldn't call it XP. It's more like a snapshot of what the bot's been doing the last several thousand cycles, that provides feedback when new muscle is created, or maybe modifies existing muscles (I'm not entirely sure yet).
If anyone can think of a better way to control specialization with DNA that's not entirely arbitrary I'm all ears
Understand, though, that bots would still control building muscles, etc. and the high level ratios involved. The specialization of those muscles is what's handled automatically.
The problem is that specialization is something like a really unbalanced tree. General muscles might make you a little bit better at everything. Movement muscles might make you better at moving. "up" muscles might make you better at moving forwards.
...
Veggies mostly build mass, so I imagine any "muscles" a veggie has would be to allow them to build more chlroplasts/chlorophyl at a higher efficiency. Or maybe I treat chloroplasts like a muscle that can become more efficient, so each chloroplast provides more energy or something like that.
-
Would you have to modify alga_minimalis to make chloraplast. Also I am in favor of a menu that would let you change the costs and benefits of different muscle types. As you said, specialization is like an unbalanced tree. If the default values make one stragtegy even slightly more benificial to the bots survival than another, diversity is thrown out the window. To force diversity and specialization on the bots the costs/benifits have to be perfectly balanced or at the very least you have to make it so an ecosystem can't survive without certain niches being filled.
I read up on Lamarckism (http://en.wikipedia.org/wiki/Lamarckism). Its interesting. Even though it may not apply to real biology, darwinbots isn't exactly real biology. I don't think it should apply to musscles or specialization. Instead mabey make it optional for a bots genes to degrade more or dissapear entirely when it doesn't use them and attempt to modify the genes that are used alot and make them more complex. Multibots would count every gene in every bot in the multibot when they do this. Im not sure if it would work or how but its an idea.
-
Would you have to modify alga_minimalis to make chloraplast.
Yes, but it'll have to be rewritten either way to use the new system.
Also I am in favor of a menu that would let you change the costs and benefits of different muscle types. As you said, specialization is like an unbalanced tree. If the default values make one stragtegy even slightly more benificial to the bots survival than another, diversity is thrown out the window. To force diversity and specialization on the bots the costs/benifits have to be perfectly balanced or at the very least you have to make it so an ecosystem can't survive without certain niches being filled.
There'll be a "maximum" which represents 100% energy efficiency that I'll use as a cap, so things can't get too crazy. Within that 0-100% range I can probably give global multipliers for each level of the tree.
I read up on Lamarckism (http://en.wikipedia.org/wiki/Lamarckism). Its interesting. Even though it may not apply to real biology, darwinbots isn't exactly real biology. I don't think it should apply to musscles or specialization. Instead mabey make it optional for a bots genes to degrade more or dissapear entirely when it doesn't use them and attempt to modify the genes that are used alot and make them more complex. Multibots would count every gene in every bot in the multibot when they do this. Im not sure if it would work or how but its an idea.
Lamarckian evolution/soft inheritance works on phenotypes, not genotypes. Meaning it only makes sense for traits and not on a genetic level. I just don't see a clean way of doing specialization in DNA. All the schemes I can think of involve having dozens to hundreds of essentially sliders that bots would have to tweak, with arbitrary reasons (cost, efficiency, etc.) why bots shouldn't change them too fast. With a hybrid hard/soft inheritance like I'm proposing we allow genetics to handle behavior (the "brain") and the system to handle capability (the "body"). Considering how much of the bot's body is already automagically handled (reproduction is handled very automagically, for instance), it seems a good fit. Bots still decide on how much muscle/fat, etc. to produce. The system just handles how that is distributed on a finer level.
If we really want to have a strictly genetic component to body management I might play around with a baser level genetic code to handle the body. It probably wouldn't work like current DNA. Maybe more like the genetic code in DarwinPond where it's just an array of sliders that get tweaked over time with mutations. I just don't see a clean way of having all those slider values exposed on the DNA level, especially since you don't want bots changing specialization in the middle of a fight, and you don't want body management to be so hard that bots can kill themselves off just by tweaking values too aggressively.
-
Well girraffes stretch their necks and so over time they grow longer necks and their children are born with longer necks to. If and when having a longer neck no longer becomes nessacary then why keep it if it just takes alot of energy and resources to grow in the first place? obviously this is not how girraffes or any other animal evolved to be what it is but it would be a quick and easy adaption as opposed to thousands and millions of years of evolution and hundereds of thousands of generations. You could make this apply to darwinbots by increasing deletion mutations or copy error mutations for genes that aren't used in a bots life time. Genes that are used alot would have a chance of being copied then being modified. A single gene that cooridinates movement, for example, could become two independent genes which coordinate movements in different directions (left, right, backwards, forwards, etc.) This line of thought seems to become real complicated real quick but I think a fully Lamarckian alife sim could be doable. I would love to see the results of soft inheratence vs. our standard random mutation and natural selection evolutions.
-
Well girraffes stretch their necks and so over time they grow longer necks and their children are born with longer necks to. If and when having a longer neck no longer becomes nessacary then why keep it if it just takes alot of energy and resources to grow in the first place? obviously this is not how girraffes or any other animal evolved to be what it is but it would be a quick and easy adaption as opposed to thousands and millions of years of evolution and hundereds of thousands of generations. You could make this apply to darwinbots by increasing deletion mutations or copy error mutations for genes that aren't used in a bots life time. Genes that are used alot would have a chance of being copied then being modified. A single gene that cooridinates movement, for example, could become two independent genes which coordinate movements in different directions (left, right, backwards, forwards, etc.) This line of thought seems to become real complicated real quick but I think a fully Lamarckian alife sim could be doable. I would love to see the results of soft inheratence vs. our standard random mutation and natural selection evolutions.
Mostly the problem is that, in real life and in Darwinbots, defining what a "gene" is is rather complicated. Segments of DNA spatially isolated from each other might work together to form what might be called a "gene". I guess you could keep a tally of how often a given bp is executed, and mutate unused ones. Though that won't catch all junk DNA.
-
The definiton of gene could be flexible. In darwinbots, even with boolean logic in the body segment of a gene, you can still identify when a statement has no use because its followed by another statment without a "and" or "or" bp. You can then find series of bps wich connect to each other, depend on each other, or read/write to the same memory locations. For starters mutate any genes which write to the same memory locations on the same cycle. You can have the bot assign resources to each gene, for example how much energy it can use per cycle or what memory locations it can write to and if another gene tries to write to that same location is it overriden. You can judge the genes usefulness by checking to see if it is interacting with other genes in useful ways, like if it shoots - 1 shoots and the shots return nrg, then reward the gene, else, punish it for lossing nrg shooting the shots. Good genes could be modified by adding a new condition or a new action, waiting to see if it has an effect than proceeding to modify it again by deleting the series of bp it put in or not. The controls for all of this wouldn't be arbitrary but would be decided by the bot itself and through natural selection or its own system of soft inheritance and it could optimize them. Sorry if i sound like im rambling.
-
If this training-based physical definition system is implemented, trying to design a bot that has a specific set of physical features would require a lot of strange behavioral contortions.
Perhaps we can borrow from life here and let DNA define physical characteristics in broad strokes, but severely limit the changes a bot can undergo while alive.
People are preprogrammed to grow to about a certain size, have a prescribed number of arms and legs, have hair in predetermined places. Using extreme effort, we can shrink or grow in size (to an extent), and train or atrophy our muscles, but these are programmed physical reactions rather than a global rule of life.
-
Think of it like this:
Given the behavior of a bot's germline over the last, say, 100K cycles, there is an optimal muscle distribution which would have minimized the energy cost of those actions. That's true regardless of how we approach specialization. Assuming that future behavior is going to be similar to past behavior, we can use that past behavior to predict future behavior. And from that, a muscle distribution which should minimize costs in the future.
We can cheaply keep track of past behavior, weighted more heavily for more recent behavior, by using a exponential moving average (http://en.wikipedia.org/wiki/Moving_average#Exponential_moving_average). Even if specialization is controlled in the DNA I think we'd still want to keep a record of how a bot has spent energy in the past so that a bot's DNA can at least make informed decisions. And again, assuming that past behavior will be an indicator of future behavior, that moving average represents the idealized muscle distribution. Which means bots which deviate from that are less fit almost by definition, so it's not necessarily an interesting problem to solve.
That said, to play devil's advocate, there are some problems:
1. This does not work well for somatic cells. Eg: organs in a specialized multibot. A multibot might easily want specialized shooting cells, for instance.
2. This does not work well for something like a caterpillar/moth lifecycle, since there are very different metabolic needs for a moth compared to a caterpillar.
For both cases, I think what we need is something like a "muscle profile" that can be saved/loaded/modified. But I don't want to have magic ID numbers that bots have to use to load up the correct profile. And I also don't want to have dozens of sliders that bots have to tweak or, worse, remember dozens of configurations of the dozens of sliders.
-
Veggies mostly build mass, so I imagine any "muscles" a veggie has would be to allow them to build more chlroplasts/chlorophyl at a higher efficiency. Or maybe I treat chloroplasts like a muscle that can become more efficient, so each chloroplast provides more energy or something like that.
What I meant was the ammount of energy a veggie gets depends on the amount of chloroplasts and surface area or circumfrance.
-
Veggies mostly build mass, so I imagine any "muscles" a veggie has would be to allow them to build more chlroplasts/chlorophyl at a higher efficiency. Or maybe I treat chloroplasts like a muscle that can become more efficient, so each chloroplast provides more energy or something like that.
What I meant was the ammount of energy a veggie gets depends on the amount of chloroplasts and surface area or circumfrance.
Dependent on the amount of chloroplasts, but chloroplasts have a large volume so bots with lots of chloroplasts will be larger as well.
-
Given the behavior of a bot's germline over the last, say, 100K cycles, there is an optimal muscle distribution which would have minimized the energy cost of those actions. That's true regardless of how we approach specialization.
What if the bot doesn't live 100k cycles?
-
Veggies mostly build mass, so I imagine any "muscles" a veggie has would be to allow them to build more chlroplasts/chlorophyl at a higher efficiency. Or maybe I treat chloroplasts like a muscle that can become more efficient, so each chloroplast provides more energy or something like that.
What I meant was the ammount of energy a veggie gets depends on the amount of chloroplasts and surface area or circumfrance.
Dependent on the amount of chloroplasts, but chloroplasts have a large volume so bots with lots of chloroplasts will be larger as well.
I understand now, thanks. I was wondering how they would work.
-
It's a running average carried over generations. If it's the start of a sim you could still seed your bots with a given profile, though. So league bots could still be tweaked for a given specialization, either by hand or by running it through some mock leagues and saving out the running average every round and averaging those together.
-
Why can't specialization be controlled the same way everything else is. A veggie might have the gene "10 .mkchloroplast store". Sure its more fragile, harder to evolve, and makes hand coding bots more complicated, but thats true for everything else in darwinbots. If you want to change the fundamental way bots' input, output, and mutations work, thats an entirely different subject. It seems to me like the only way to do it without destroying multibots and leagues.
-
You still make muscle, fat, chloroplasts, shell, slime, etc. manually. This is more how the muscles specialize (shooting muscles vs. more general purpose muscles). Or maybe the efficiency with which your chloroplasts can convert sunlight in to nrg. Or how efficiently you can convert stored fat in to energy. Things like that.
-
I have two gripes with this idea that aren't on your list:
1) In internet mode or in something like EricL's island sim, a bot may change environments and hence behave differently. The bot would be penalized for this.
2) A bot's behavior in non-critical situations can hamper it's ability to respond to critical ones.
An example of 2 would be a bot that runs from things that are bigger than it. If it becomes a big bertha for a while and then reproduces and loses the size advantage, the ability to run away well is lost for the original bot (and maybe even the offspring!). DB3 simply can't know beforehand what muscle distribution a bot will need to survive, so letting a bot make it's own informed guesses seems a lot more fair.
-
Heres an idea. What if the bots can manually change there specializiation but also have the ability to adapt over time like what you mentioned. "100000 .adapt store" would let the bot adapt its muscles over the course of 100,000 cycles based on what it does and doesn't do. It would be a fair shortcut, not so arbitrary as just saying "you and your children will only be good at doing what you did over the last x cycles". For multibots or ant bots, the bots could choose what kind of muscles there children inhereted, not nessacarily there own.
-
I have two gripes with this idea that aren't on your list:
1) In internet mode or in something like EricL's island sim, a bot may change environments and hence behave differently. The bot would be penalized for this.
I think that's like the caterpillar/butterfly analogy. If you're in a new environment and want to dramatically change specializations, you need to go through some sort of transformation phase.
2) A bot's behavior in non-critical situations can hamper it's ability to respond to critical ones.
An example of 2 would be a bot that runs from things that are bigger than it. If it becomes a big bertha for a while and then reproduces and loses the size advantage, the ability to run away well is lost for the original bot (and maybe even the offspring!). DB3 simply can't know beforehand what muscle distribution a bot will need to survive, so letting a bot make it's own informed guesses seems a lot more fair.
Specialization here is less to do with how strong of a force you can produce, and more to do with how much that force costs you. So when you .5 up, it means you accelerate forward 5 units/cycle^2, and not that you spend 5 nrg to move forward. So your specializations won't prevent you from doing actions that are uncharacteristic, it just means they'll be more expensive.
Heres an idea. What if the bots can manually change there specializiation but also have the ability to adapt over time like what you mentioned. "100000 .adapt store" would let the bot adapt its muscles over the course of 100,000 cycles based on what it does and doesn't do. It would be a fair shortcut, not so arbitrary as just saying "you and your children will only be good at doing what you did over the last x cycles". For multibots or ant bots, the bots could choose what kind of muscles there children inhereted, not nessacarily there own.
The running average I mentioned doesn't really cut off after 100000 cycles or anything like that. Past signals are just slowly degraded towards zero as each new datum is recieved. So values from indefinitely long ago still factor in, it's just a matter of how much. The equation does have a value to tweak which controls how strongly weighted towards present activities the average is. That could certainly be exposed to DNA.
Ant bots are another example of something like a somatic specialization. I don't have a good plan for that just yet.
-
Specialization here is less to do with how strong of a force you can produce, and more to do with how much that force costs you.
My statements were based on this assumption. How much an action costs limits how much the bot can perform that action. It may be that accelerating at full tilt has become an almost suicidal idea due to energy constraints and atrophy. Especially in situations involving reproduction, where a bot suddenly has much less energy to play around with than it did before.
-
Specialization will be more of the Lamarckian variety. Ie: inheritable improvement through exercise. Not quite biologically sound, but I think it'll make for the behavior we want.
Wait a sec, didn't someone else and I post a response to this? Was it deleted? Well, anyway, it just said I don't think that's a good idea.
-
Specialization will be more of the Lamarckian variety. Ie: inheritable improvement through exercise. Not quite biologically sound, but I think it'll make for the behavior we want.
Yeah, something like that. You shoot a lot and you get better at shooting, etc.
Sounds very wrong. If you want your bot to learn, program a feedback loop.
I am entirely with ikke on this. At least provide an option to turn lamarckian selection off.
Not deleted, it's up there
[div class=\'quotetop\']QUOTE ( @ Jan 22 2010, 04:59 AM) [a href=\"index.php?act=findpost&pid=1381398\"][{POST_SNAPBACK}][/a][div class=\'quotemain\'][!--quotec--][!--quoteo(post=1381397:date=Jan 22 2010, 12:04 AM:name=Numsgil]Specialization here is less to do with how strong of a force you can produce, and more to do with how much that force costs you.
My statements were based on this assumption. How much an action costs limits how much the bot can perform that action. It may be that accelerating at full tilt has become an almost suicidal idea due to energy constraints and atrophy. Especially in situations involving reproduction, where a bot suddenly has much less energy to play around with than it did before.
[/quote]
I'll have to build a model to be sure, but I think the moving average will still result in the best energy usage over the long haul. Even if short life/death burn through a lot of energy.
If you think about real life, right after reproduction is the perfect time for a predator to attack.
-
Well, in real life the atrophy/exercise system that you intend to simulate really is there in more complex things. I also think it's going to be closer to a long-haul best than any bot is likely to achieve.
I think on a gut level I just don't like shifting control of a bot away from its DNA and into DB itself.
-
Well, in real life the atrophy/exercise system that you intend to simulate really is there in more complex things. I also think it's going to be closer to a long-haul best than any bot is likely to achieve.
I think on a gut level I just don't like shifting control of a bot away from its DNA and into DB itself.
Yeah, I can understand where you're coming from. In the end it'll probably need to be something of a hybrid system to handle the butterfly/somatic cells.
-
I think that the amount of material should not really be a bottleneck for development. Using the butterfly logic, There is still a need for the capacity to turn specialized materials into base resources, so a good way to balance this would be a weighted cost system that allowed exponential-decay costs (another idea is to make the accumulation rate increase), that allowed specialization, and perhaps an increasing cost to develop body mass, which would act as storage space for fitting in more materials. This would mean that a bot with plenty of muscle would have trouble developing fat (but still has the ability to do so), but could still convert that muscle into fat with vastly reduced cost. In this case, the bottleneck for development should either be a.)making more free space or b.)the conversion of resources (which could have other benefits, eg. fat can be digested faster than chlorophyll, so can act as a space/energy holder).
I have a feeling I failed to address about a dozen arguments. Feel free to remind me of anything I may have ignored.
-
I think that the amount of material should not really be a bottleneck for development. Using the butterfly logic, There is still a need for the capacity to turn specialized materials into base resources
I think caterpillars do it by storing up a lot of fat. The end butterfly is much less massive than the starting caterpillar, because the transformation is extremely expensive to perform.
so a good way to balance this would be a weighted cost system that allowed exponential-decay costs (another idea is to make the accumulation rate increase), that allowed specialization, and perhaps an increasing cost to develop body mass, which would act as storage space for fitting in more materials. This would mean that a bot with plenty of muscle would have trouble developing fat (but still has the ability to do so), but could still convert that muscle into fat with vastly reduced cost. In this case, the bottleneck for development should either be a.)making more free space or b.)the conversion of resources (which could have other benefits, eg. fat can be digested faster than chlorophyll, so can act as a space/energy holder).
I don't necessarily want the system to favor bots who choose a "middle way" approach. If anything, it should reward bots who specialize. So I don't want to make fat comparatively cheaper to produce even if the bot already has lots and lots of muscle.
My thinking is that muscle is expensive to produce but you don't get much energy back from it if you try to unmake it. This encourages, if not specialization, than at least inertia in not changing specialization on a whim. Fat lets you get back all or most of the energy you spent producing it, but it doesn't actually provide much or any benefit beyond that energy storage. Chloroplasts are like muscle: they require nrg to produce but don't give much nrg back when you unmake them.
I was playing with the idea of body size. I'll probably relate it to shell. If you produce shell beyond a certain point you sort of "lock" yourself in and you'll have to molt the shell to actually get any bigger. Most cells can grow larger (to a point) just by letting more water in. Ideally I'd like to have "soft shell", which all bots have, which would mimic a cell wall/membrane. If it becomes too thin the cell ruptures, but within that bound the cell can change volume at will. In addition there would be "hard shell", which would add protection but at the "cost" that the cell can't change size until the hard shell is molted. I just haven't entirely decided how best to make that work and how the bot would control it.
-
Will there be an option for disabling these new features?
-
Maybe it has been suggested before but is something like allowing a bot to select a single command to be performed more efficiently (against lower cost) not a better option? like: .up . specialization store resulting in .up performed at half cost. The multiplier may be adjustable. In order to balance you might want to increase other cost.
Will there be an option for disabling these new features?
I have suggested the ability to disable all commands individually in a sim in the past.
-
Would it be a bad idea to have a slider control specialization costs. If you had it set at 1 youd get 1 species of veggie like bots. 2 would adjust it so you got 2 species of say a animal bot and a veggie bot. 3 gives you 3 species and so on.
-
Will there be an option for disabling these new features?
You mean just nix all specialization? Yeah, I suppose that's doable. If you're talking about the substances (fat, muscle, etc.) probably not. That's pretty central.
Maybe it has been suggested before but is something like allowing a bot to select a single command to be performed more efficiently (against lower cost) not a better option? like: .up . specialization store resulting in .up performed at half cost. The multiplier may be adjustable. In order to balance you might want to increase other cost.
The problem here is that bots would probably need some meta information about their DNA that I sort of want to avoid (how many .up do I have? How many were executed last cycle). And a sort of slippery slope argument: if we give them the meta information, and the bots behave optimally (always specialize towards most expensive operations), we essentially have the system I was proposing anyway. Just with the added difficulty of managing the specialization from within the DNA.
The way the DNA works right now, it's almost like we're modeling instinct, with very little low level body control. Every layer of body management we add is another layer of logic that has to be in sync with the rest of the DNA. Like a veggie that changes from motility to shooting for defense. The specialization needs to change, too, for this to be effective but the probability of that happening with a hard coded specialization is rather small.
I've been thinking of it like this: most real life shares something like 80% of their genome (I'm making this figure up, and it depends how far up the tree of life you climb, but it's something like that), because these are well established, well conserved, very low level metabolic genes. Things like converting glucose to energy. So it's like the operating system of life. The remaining different genes are the user level software the differentiates life. For Darwinbots, the we hide a lot of that complexity without exposing it to the bots (reproduction, converting body to nrg, etc.) because doing it incorrectly results in death instead of interesting behavior. I can appreciate wanting to expose more things to the DNA, but I just think it'll result in "lock in" where a species can't adapt because to do so it would need to change behavior and specialization at the same time.
Would it be a bad idea to have a slider control specialization costs. If you had it set at 1 youd get 1 species of veggie like bots. 2 would adjust it so you got 2 species of say a animal bot and a veggie bot. 3 gives you 3 species and so on.
I'm not sure what you mean.
-
I'm not sure what you mean.
I mean that it would be like the dynamic costs. If you set it to 2 it will make specialization more favorable and generalization less favorable than if you just set it to one. You might also have to have a sensitivity slider to define how sensitive it would be to classifiying species.
-
I'm not sure what you mean.
I mean that it would be like the dynamic costs. If you set it to 2 it will make specialization more favorable and generalization less favorable than if you just set it to one.
Oh, yes, we can do a slider. It wouldn't be an integer slider like that, though. It'd be more a continuous [0,1] multiplier or something like that.
You might also have to have a sensitivity slider to define how sensitive it would be to classifiying species.
The core program doesn't really understand the concept of "species". That's more a high level concept we use for graphs and starting conditions and such.
-
I think that calculations involving mutations should be avoided if unnecessary. Evosims are already slow enough without having to make a global cost highly individualized.
-
I just meant that it would loosely define species, at least for the purposes of this slider, by the type of specialization they had, not by analyzing there entire genome or mutation details. Anyways that might work for multibots if you average the entire bots specialization, but antbots and butterflys might not work as well.
-
I just meant that it would loosely define species, at least for the purposes of this slider, by the type of specialization they had, not by analyzing there entire genome or mutation details. Anyways that might work for multibots if you average the entire bots specialization, but antbots and butterflys might not work as well.
I guess I'm missing something. Let's say the simulation determines that there are currently 3 different "species", and the slider is set to 2. What happens?
-
I guess I'm missing something. Let's say the simulation determines that there are currently 3 different "species", and the slider is set to 2. What happens?
Generalization becomes cheaper, specialization becomes more expensive or at least less beneficial than it would normally be. But do we really need to be worrying about there being less species. If you could get it to evolve a small ecosystem it would great.
-
Ah, okay, I see. Like with bac's suggestion, I want to try and avoid substances costing more the more you have. Instead I'd like to see it being an issue of opportunity cost. Eg: given that you want to be a certain size, to cut down on your visibility and movement costs (from drag), what's the optimal distribution of muscles, fat, chloroplasts, shell, etc.
Like if anyone's ever played Magic the Gathering (a card game). If you add too many awesome cards to your deck you end up with an 80 card deck and your cards don't really work together very well. But if you pick a smaller subset of that you can make a lean and mean 45 card deck.
-
Since this thread has become pretty broad, I think I'll stick my suggestion in here. It would be nice to have some strictly "aesthetic" robot features that other bots could possibly use to recognize a species or individual bot. Some of these could be worked into how the bot is displayed.
-
I think something like a serial number for individual bots would work. Have a refid and myid.
-
Like if anyone's ever played Magic the Gathering (a card game). If you add too many awesome cards to your deck you end up with an 80 card deck and your cards don't really work together very well. But if you pick a smaller subset of that you can make a lean and mean 45 card deck.
Ah, that makes everything sooo much clearer. Randomness isn't the solution though. What other limiting factors can we introduce?
Instead I'd like to see it being an issue of opportunity cost. Eg: given that you want to be a certain size, to cut down on your visibility and movement costs (from drag), what's the optimal distribution of muscles, fat, chloroplasts, shell, etc.
This seems to me to be a good place to start, but also a very risky approach. This could be a nightmare to learn and remember, like some form of grand-scale paper-scissors-rock. The best way to handle this would be to define a standard set of aspects (eg. weight, cost, bulk) which would handle the downside part of the materials easily, then have specific traits which define the material (eg. energy production, movement efficiency, motion). This would cut down on complexity greatly while still allowing a lot of flexibility for different materials.
While on the topic of materials, I thought I'd throw in a rough summary of basic materials that would probably be baseline:
-Chloroplasts (energy production)
-Cilia (Linear Motion)
-Muscle (Rotational Motion-as cells will be bonded on the surface and non-spherical, rotational forces will have to be much greater than in DB II.)
-Photosensitive (Horrible fill-in name for vision cell)
-Enzyme Gland (Shot power)
-Poison/Slime/Shell etc.
There's probably others that will be needed, but that seems to cover most necessary bot functions.
-
This seems to me to be a good place to start, but also a very risky approach. This could be a nightmare to learn and remember, like some form of grand-scale paper-scissors-rock. The best way to handle this would be to define a standard set of aspects (eg. weight, cost, bulk) which would handle the downside part of the materials easily, then have specific traits which define the material (eg. energy production, movement efficiency, motion). This would cut down on complexity greatly while still allowing a lot of flexibility for different materials.
Primarily I was thinking these:
- payload (eg: what it actually does. Usually positive)
- volume
- mass
With maybe some other special characteristics. But mostly it's a matter of volume and mass.
While on the topic of materials, I thought I'd throw in a rough summary of basic materials that would probably be baseline:
-Chloroplasts (energy production)
-Cilia (Linear Motion)
-Muscle (Rotational Motion-as cells will be bonded on the surface and non-spherical, rotational forces will have to be much greater than in DB II.)
-Photosensitive (Horrible fill-in name for vision cell)
-Enzyme Gland (Shot power)
-Poison/Slime/Shell etc.
There's probably others that will be needed, but that seems to cover most necessary bot functions.
I'm including things like cilia and "enzyme gland" as part of the muscles. Maybe vision organelles as well (add more, increase your sensitivity).
-
I'm including things like cilia and "enzyme gland" as part of the muscles. Maybe vision organelles as well (add more, increase your sensitivity).
Does that mean different types of specialized muscle or just that muscle does all those functions?
-
If i may make a protest here. You are talking about cillia, organelles, and enzymes. I didn't think darwinbots was intended to simulate only single celled creatures. Single celled creatures are fascinating but higher level behaviors are more on a level we can understand and interact with. DB3 shouldn't become bogged down in the simulation of one aspect of biology. Without specialization db is pretty much universal in that you can simulate, or at least attempt to simulate, various ecosystems and parts of real biology. Im hoping db3's specialization will enhance this, not defeat it.
-
I disagree with the new material system specialized cells are encouraged meaning that it is no longer advantageous to simply have each cell in the multibot do the same task It forces diversity within multibots and pushes the entire program more towards developing complexity
Sorry about thelack of punctuation My keyboard has gone haywire and it ook me two hours just to boot this morning Going back and correcting miskates is also no longer an option thanks to this
-
I'm including things like cilia and "enzyme gland" as part of the muscles. Maybe vision organelles as well (add more, increase your sensitivity).
Does that mean different types of specialized muscle or just that muscle does all those functions?
Both. There are specialized muscles and more general muscles. I'll try to balance it so that under certain circumstances lots of general muscle gets built (if you're a generalist), and under other circumstances lots of specialized muscles get built (if you're a specialist).
If i may make a protest here. You are talking about cillia, organelles, and enzymes. I didn't think darwinbots was intended to simulate only single celled creatures. Single celled creatures are fascinating but higher level behaviors are more on a level we can understand and interact with. DB3 shouldn't become bogged down in the simulation of one aspect of biology. Without specialization db is pretty much universal in that you can simulate, or at least attempt to simulate, various ecosystems and parts of real biology. Im hoping db3's specialization will enhance this, not defeat it.
They're just words which describe components common (or nearly so) to all life: movement, senses, metabolism, etc. You can easily replace organelle with organ and the analogy would still hold. When it comes time to actually implement I'll probably pick words that are the least jargon-y, so long as they have a nice mouth-feel when you say them.
-
Both. There are specialized muscles and more general muscles. I'll try to balance it so that under certain circumstances lots of general muscle gets built (if you're a generalist), and under other circumstances lots of specialized muscles get built (if you're a specialist).
That seems like the best option to go, and the best compromise for multi- and single-bots but wouldn't it be easier to have a general command make equal proportions of all the specialized muscle instead of making a specific type of muscle that adds no unique functionality?
EDIT=>Yay, punctuation's back!
-
Maybe something else to think about-this is probably extremely obvious and no doubt already exists, but I should probably mention it anyway.
When handling trig functions, is the angle stored and sin/cos calculated when needed, or are the sin/cos values stored on angle change with the angle having no direct impact on the physics? As I said, pretty obvious, but it has saved me hours of rendering in some of my strange attractor codes.
-
Both. There are specialized muscles and more general muscles. I'll try to balance it so that under certain circumstances lots of general muscle gets built (if you're a generalist), and under other circumstances lots of specialized muscles get built (if you're a specialist).
That seems like the best option to go, and the best compromise for multi- and single-bots but wouldn't it be easier to have a general command make equal proportions of all the specialized muscle instead of making a specific type of muscle that adds no unique functionality?
EDIT=>Yay, punctuation's back!
I'll have to work it out to figure if we need a hierarchy of generalized to specialized muscles like I was thinking originally, or if we can get away with evenly building across all specialized muscles. But it should be a mostly internal detail I think.
Maybe something else to think about-this is probably extremely obvious and no doubt already exists, but I should probably mention it anyway.
When handling trig functions, is the angle stored and sin/cos calculated when needed, or are the sin/cos values stored on angle change with the angle having no direct impact on the physics? As I said, pretty obvious, but it has saved me hours of rendering in some of my strange attractor codes.
I'll pick a range for sysvars such that it's some multiple of 360, so you can exactly represent angles in degrees (the only sensible integer representation for angles ). Cosine and Sine will be mapped to that same range. So cos,sin will be functions mapping [-360,360]->[-360,360] (assuming the range for sysvars was 360). Angle/distance seems to work better for bots than x/y vectors, so most sysvars will operate with that convention.
-
Angle/distance seems to work better for bots than x/y vectors, so most sysvars will operate with that convention.
I don't necessarily mean x/y vectors-I'm talking about using polar vector for DNA purposes and such, and having an unseen Cartesian unit vector which only changes on the angle changing, then multiplying by the magnitude of motion. This part will interact with the physics engine, as using cos/sin functions within the physics engine is exactly the same as updating this unit vector every cycle, which is mostly unnecessary.
-
Oh, I see. Yeah, the core engine isn't angle based. It's all vectors and matrices.
-
Quick thought - is it possible to have some substances act as gradients, so that each cell will distribute its concentration to cells bonded to it? It's simple, but could be useful in determining multibot size etc.
-
Possibly. Can you think of a really compelling use case for something like that?
-
I was just thinking of most real-life organisms using a chemical gradient to differentiate cells. I also picture a multibot plant that when attacked produces a chemical that quickly transfers through the entire organism, instead of having to send a message one tie at a time.
Another way to solve this which would also help in many more situations would be to make .readtie a command rather than a variable - this way, multiple ties can be manipulated over one cycle. For a more complex organism, chemical gradient would still be the best way to go for reflex responses that have to act rapidly.
-
Thats an awesome idea, making .readtie a command. That would solve alot of tie communication problems. May I suggest that it be easier to write and read on the tin/tout sysvars also. You could have a .tout command/sysvar that writes to the .toutx of the tie specified on the top of the stack. It would also be nice to have a .tin command to because you can write to the number specified on top of the stack but you can't exactly read from it, instead you have to have seprate "*" symbol for each sysvar you plan to read from. Maybe a read command would be a good idea because we already have a store command. Is this to radical for DB3?
-
I was planning on something like that. I haven't worked through the details, but basically when you're connected to another bot (not using ties, but using "joints", for lack of a better word) you have access to their entire memory structure and can read and write to it. There's some special code right now that will queue any changes a bot wants to make to another's memory so that there aren't any issues with which bot was executed first.
We might also be able to do something like "port forwarding". Any memory values written to a specific location get broadcast to other connected bots in the same cycle. So there wouldn't be a cycle lag for each step in a multibot. I'd have to play with it a bit, though, to make sure impulses can't travel too quickly. And I'm not quite sure how it would get set by bots in their DNA. Maybe bots register codules for events like "something was written to location 459". I'm probably doing something similar for vision anyway.
-
In real life cells first evolved chemical signals to communicate. Each cell waits till it recieves enough of a certain chemecal or combination of chemicals to reach a threshold then it sends out more chemicals and the proccess continues. This is like what we have now, each bot in a multibot has to communicate with the cells around it one cycle and then wait till the next cycle to communicate with more cells around it. Then evolved the ability to send electrical impulses and suddenly brains were possible. Immagine if you had to wait minutes, even seconds for information from your eyes to go through you brain and then go to your muscles. You wouldn't be able to react to anything! I like this idea of impulses because with well written code, the sky is the limit for what multibots can do.
-
Electrical impulses would be the next logical step up from chemical gradients, but I'll settle for just the switchable ties, eh?
In other words, now for the ramble to get some more ideas into circulation:
-About species forking, I don't think too much time should be spent developing a system to handle this. The definition of species is pretty patchy and subjective anyway.
-Mutations can't really be improved, but I would suggest something a little more radical - a type of mutation that would fragment a piece of the DNA and eject it as a virus. This mutation should be extremely uncommon, as it could have a significantly larger effect on an environment.
-Regarding viruses, is it possible to have them accumulate inside a bot until fired or the bot dies? This would be a little more realistic and would make them that much more interesting.
-This is mostly just a detail, but I'm bursting with ideas that will be lost in a few seconds (I had one a second ago that was awesome, but I already forgot)-can enough pressure in the right spot destroy ties? The only real application would be for 'chewing' bits off your prey.
-I heard talk about this before, but I may as well bring it up again-is it possible to have shots that do not directly siphon energy, but rather weaken the cell wall, eventually spilling out the contents of the cell? If so, this shot should probably replace the body shot. This could, in turn, lead to all sorts of different paths. For example, the shots could be modified to either damage the wall immediately, erode it over time, gnaw away on any shells or prevent it from healing, to name a few. Cell walls could be reinforced or protected with a shell; larger bots would have a weaker shell, and more shell would allow less cell growth.
-For senses such as touch, another way of detecting such things is instead of detecting the angle, the cell uses areas (north, west etc.) to determine roughly where it came from, which would encourage MB behavior without making it impossible for bacteria to use these features, and compensate by measuring the magnitude of impact as well?
Sorry about the rambly post, I hope you got at least one useful idea out of it
-
Speaking of mutations, there should be a mutation to copy an entire gene or series of genes or even just a condition or action statement within a gene. This is more realistic to how real mutations work and with DB3s codules it could have interesting effects. Speaking of codules, Im not sure how they work, but shouldn't there be a whole new mutation just devoted to them?
-
vegies should get energy maybe based on light spots.
so whitin the range of the spots there is more light so you get green and les green areas.
nice would be an easy polunation from seed to plant, beeing for x cycles moveable with a speed y in direction z (i make plants like that, now with code)