Code center > Suggestions
Eyes
EricL:
Something on my list is to add (obviously optional) switches to turn various single bot capabilites off. For example, I have been considerring an option that would turn off the movement sysvars. This would mean that bots would have to evolve their own mechanisms for locomotion based on the physics of the system, which would select heavily for multbots. For example, using ties for swimming or tie torque/tie length and fixing and unfixing to walk.
I could do the same thing for vision if people really wanted I.e. turn off all eyes but .eye5 or turn off the distance values so all you know is that there is something in the eye's field of view, but not how far....
Personally, I can think of many things that would favor the evolution of multibots but I think it may require some tweaks to costs and also increased topological complexity before they really take off. As to the former, I see cell specialization as a key driver for MB's. I.e. some cells get good at attacking, others good at storing nrg, others good at defense, etc. I'm wondering whether we need to tweak costs or add additional ones that favor this I.e. that make it more costly for a single cell to do multiple things that it is for two separate cells to specialize.
As to the latter, I can envision MB's being necessary to climb over obstacles, bridge chasms, fly, swim, move faster, dig deeper and perhaps more importantly, think better. A long distance goal of mine is to create morphological artifacts (think nurons) which favor MB's hooking up to be able to think better. It's not a complete idea yet, but something I would like to explore down the road.
Jez:
Wow, I come up with a bright idea and Eric's already so far ahead of me that he's ordering a pint down the local pub!!
I'd love the option to turn depth perception off for uni bots, especially if there was a way for MB's to still get the ability.
I've always wanted MB's to evolve into omethng more viable than web bots or cancerous veg imitators.
You get my full support for adjusting the game anyway you see fit when it comes to emphasising the difference between one cell and multi cell life.
Numsgil:
I think a step in the right direction is charging bots nrg for eyes, ability to move, shooting, etc. As bots turn off their capabilities to do various things, they are charged less and less for upkeep.
That encourages a high degree of specialization, especially if the reduction in nrg use is non linear.
EricL:
--- Quote from: Jez ---I'd love the option to turn depth perception off for uni bots, especially if there was a way for MB's to still get the ability.
--- End quote ---
Something I would love to see is someone hand-author a mutlibot that uses binocular vision to determine how far another bot is. No program changes would be needed to do this. Simply author a bot that divides, ties the two bots together using a known tie length, then ignoring the number that the eyes reads back, uses the relative eye angles on the two bots and a little triganometry to tranangulate on a third viewed bot and track that bot in motion.
This excercise would give us some insite into the complexity it would take to actually have binocular vision evolve.
--- Quote from: Numsgil ---I think a step in the right direction is charging bots nrg for eyes, ability to move, shooting, etc. As bots turn off their capabilities to do various things, they are charged less and less for upkeep.
--- End quote ---
I fully agree and this is exactly what I have meant in posts past when I indicated I favorred morphological costs over genotypic costs (such as DNA operations). IMHO, we shoudl charge bots for what they do, not how they do it. So I'm all in for, for example, adding costs directly tied to phsyical movement (including eye movement if we want) in addition to the other morphological costs we already have (producing posion, slime, shots, ties, etc). I'd also like to add costs for reproduction as described in previous threads.
Charging for using (I.e. reading from) specific sysvar values (such as the eye sysvars) that the system is populating anyway is more problematic. It's easy for me to see how we can charge for writing to a sysvar (and thus charge for the corrosponding/resulting morphological action that implies) but reading from mem locatiosn is harder to catch. I'm open to suggestions on how we might do this if people really want to say, make a bot with 9 eyes more expensive than one with 3.
Numsgil:
The simplest method I can imagine is to start every bot off with no eyes activated. Activate an eye only if the bot tries to read from its memory location. Activated eyes cost nrg to upkeep every cycle. Eyes that haven't been addressed in a while are automatically turned off, and aren't charged anymore (maybe over the length of 1000 cycles or something similar).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version