Code center > Suggestions
Suggesting a cost for .fixpos
Testlund:
Some kind of cost for bots using the .fixpos sysvar would be nice, as discussed in this topic:
http://www.darwinbots.com/Forum/index.php?showtopic=2845
I think the most realistic would be a one time cost for the bot fixing itself to the background and then a timer you can set for it to wear off, though I guess just a cost per cycle is simpler to implement.
EricL:
My $0.02:
I don't really favor a cost for fixing or some limit of fixation duration.
First, I have a dislike for costs of any sort. I think they are over emphasized as it is. IMHO, they should play a minimal or non-existant role in applying selection pressure in evo sims because they drive selection towards simplicity rather than complexity. I prefer to use preditors, shepards and species-species competion (along lines other than cost-effeciency) as selction drivers in my evo sims so as to encourage spiraling co-evolution that selects torwards increasing complexity. My evo sims generally have no costs.
Second, it's not obvious how it should work. A cost per cycle? An initial fixation cost? A limit on fixation duration? A consensus could be reached, but it's not immediatly clear to me what it would be.
Personally, I prefer to simply add a global sim option to allow fixing or not. We already have the options to allow ties and to allow different bot radii. This would simply be another global sim setting that would provide the human option of disabling fixation in that sim. If so set, setting .fixpos would do nothing.
Nitus:
--- Quote from: EricL ---My $0.02:
I don't really favor a cost for fixing or some limit of fixation duration.
First, I have a dislike for costs of any sort. I think they are over emphasized as it is. IMHO, they should play a minimal or non-existant role in applying selection pressure in evo sims because they drive selection towards simplicity rather than complexity. I prefer to use preditors, shepards and species-species competion (along lines other than cost-effeciency) as selction drivers in my evo sims so as to encourage spiraling co-evolution that selects torwards increasing complexity. My evo sims generally have no costs.
Second, it's not obvious how it should work. A cost per cycle? An initial fixation cost? A limit on fixation duration? A consensus could be reached, but it's not immediatly clear to me what it would be.
Personally, I prefer to simply add a global sim option to allow fixing or not. We already have the options to allow ties and to allow different bot radii. This would simply be another global sim setting that would provide the human option of disabling fixation in that sim. If so set, setting .fixpos would do nothing.
--- End quote ---
A global setting would work, but there could be scenarios where bots might be able to make leigitimate use of .fixpos even if it had some costs assosciated with it - sims with fixed feeders and gravity, for example, where it might profit a bot to fix in clusters near a food source.
My only beef with it is that it breaks the physics model - a bot can anchor itself in space and time regardless of gravity or momentum; even the tiniest bot, when fixed, can stop a massively huge bot dead in its tracks. I have no problem with bots using it, if it's a functional adaption, but it shouldn't circumvent the physics of the sim.
I've always used phsyics-based costs rather than DNA costs in evo sims - DNA costs don't encourage evolution - along with predation and competition, so I would prefer a physics-based fix. There should be some way to make the bot pay for circumventing momentum - in a high g environment, high momentum environment, for example, or when a larger bot slams into it with high "marbleness" set. A movement cost, counter to momentum, or a body-associated cost would be ideal [if harder to implement]. A global .fixpos flag would preclude any legitimate use of a .fixpos strategy [not to mention that fixed veggies seem to use .fixpos behind the scenes; bots that reset .fixpos to zero will unfix veggies]. I suggested a .fixpos DNA costs more as a rough fix that would be easier to implement while not completely disabling .fixpos.
The fact that my zerobots in gravity environments keep selecting for it [particularily with energy-shot fix feeders] is not a problem - it makes sense that they would want to. Inserting a predator bot into the sim makes it a less effective tactic, but I've been rerunning sims in an effort to get the bots to keep their .fixpos strategy while finding a means to defend themselves - a reef or cluster seems kinds cool if it can be made to function sensibly. It just doesn't make sense for the bots to completely circumvent the physics model.
I'm not sure if it's noteworthy, but I never had this happen until I started using zerobot blanks for my evo sims
. Even then I can only replicate it using an environment where it confers a distinct advantage. Transitioning the sim to a more complex competive environment isn't working well for "reef" bots, but I'm hopeful that they might devise a defensive strategy that allows them to maintain their "reef" behavior. Some of these reefs utilize extensive ties, which is kind of cool. Overall I don't have a problem with this behavior; I'm just picky about the physics ;p.
EricL:
--- Quote from: Nitus ---A global setting would work, but there could be scenarios where bots might be able to make leigitimate use of .fixpos even if it had some costs assosciated with it - sims with fixed feeders and gravity, for example, where it might profit a bot to fix in clusters near a food source.
--- End quote ---
Good point. With fixing disabled, bots would be hard pressed to remain stationary in such an environment (unless we did somethign like the below).
Note that if I do it as a cost, I think I'd do it per cycle. Bots would pay a cost each cycle they remained fixed.
--- Quote from: Nitus ---My only beef with it is that it breaks the physics model - a bot can anchor itself in space and time regardless of gravity or momentum; even the tiniest bot, when fixed, can stop a massively huge bot dead in its tracks. I have no problem with bots using it, if it's a functional adaption, but it shouldn't circumvent the physics of the sim.
--- End quote ---
I share your beef. The simulator code is full of special cases for fixed bots w.r.t. collisions, shape overlap (shapes can move) and so on. Perhaps what we need is less of a binary mechanism and more a gradient - perhaps a way for bots to modify their own coeffecient of friction for example, a .texture sysvar. Setting it high (rough) enough would generally allow them to fix themselves in most or all environments (I'd include radius and mass in the calculation) but a strong enough collision with a large enoguh bot or a shape would dislodge them some distance. If we added this sysvar, we could also do the global fixation disable switch (for backward compatagbility with bots that use .fixpos instead of .testure) and not bother with costs unless someone really wanted a cost on bots changing their texture...
Testlund:
Sounds like a cool idea and I think a cost for bots changing their texture would be realistic because it would be a morphological process.
Navigation
[0] Message Index
[#] Next page
Go to full version