Darwinbots Forum
Bots and Simulations => DNA - General => Topic started by: EricL on March 16, 2006, 05:43:41 PM
-
.fixed and .fixpos are treated differently than other sysvars today with respect to venom. For example, if you use venom to overwrite another bots' .myeye, that bot will be confused about how many .eye statements are in their DNA for a period of time dependent upon how much venom was used. The period of influence is obtainable via .paralyzed and once .paralyzed gets to 0, the effect of the venom wears off and the venomized bot returns to normal. That is, referencing *.myeye will agian return the correct value. This happens without the effected bot having to have any anti-venom specific code in its DNA.
It doesn't work this way for .fixed / .fixpos as far as I can tell. Becuase of the asymetry in .fixpos and .fixed (one is kind of control only, one is kind of read only) when a bot gets fixed due to venom, they will be fixed forever more even after the venom wears off unless their DNA contains explicit instructions to do something about it.
Is this the correct behaviour?
-
It's not a bug if that's what you're asking. It's debatable if there's a better behavior
-
Understand its by design. My question is why it is the way it is. Is there some reason it was purposfully designed this way?
-
It wasn't necessarily specifically designed that way.
Originally PY added fixpos and fixed to let bots control their fixed-ness.
Then he added Venom.
The way the two interact forms the way it is now.
Most things are like that.
-
yea, I kind of figurred that, thus my question.
I like symetry. I'm not saying change it, but when one thing doesn't work the way all the other things do...
Probably should have posted in the Suggestions forum.
-
The problem is that it's a toggle instead of a command. memloc, pval, etc. are all other toggles. Toggles don't have to be reset every cycle by design, which makes them particularly vulnerable to venom and poison.
-
You should have an unfixing gene in your bots as standard
cond
start
.fixpos *.fixed mult dec
stop
This gene costs no energy at all and can even go in conditionless bots
If your combat bot gets fixed, then it's your fault for not putting an unfix gene in :P
-
Got it. My question was less about coding for anti-venom and more about generating discussion on the philosphy of the DB design in this area I.e. more about the question of what should be handled by the engine as part of the world's physics and what should be handled by the bot. Let me try to explain. I think of venom as three main things 1) the ability for a bot to semi-persistantly (I.e. longer than a single cycle) overwrite a mem location in another bot 2) the fact that the DB engine maintains state about this for how long it lasts and 3) the fact that the engine, not the bot, is generally resposible for putting things right when it wears off (else, why maintain the state?).
Now, 1) makes perfect sense to me because without the ability for bot A to potentially impact bot B's memory for longer than a single cycle, the world would be smaller, the scope of possible bot variation would be less. But a question I pose is why should the engine be resposible for making it wear off? Should venom wearing off be world chemistry or bot genetics?
2) is a design decision IMHO. We could decide that the engine should maintain absolutely no state what so ever about venom I.e. that it is entirely the responsibility of the bot to check for venom effects and code for anti-venom via DNA self-checking approaches for all types of venom. This raises the bar for coding for anti-venom, puts more stuff into the DNA, simplifies the engine but I don't think it has an impact on diversity I.e. it does not reduce the size of the space of all possible organisms or adaptations. Personally, I think I favor this approach. I like simplifying the engine and putting more into the DNA as long as it maintains maximum diversity potential. Besides, there are problems with the engine maintaining state about venomized bots. What if a bot shoots multiple kinds of venom? What it a bot gets venomized by multiple bots with different venoms? Should the engine maintain separate venom countdown state about each and every memory location for every bot I.e. have a separate .paralyzed sysvar and maintain separate countdown timers for all the different possible ways to get venomized? Today this is kind of broken in my opinion as there is only a single paracount for each bot.
3) Okay, so, we can decide (as the DB powers that be have in fact done) that venom wearing off is in fact chemstry, not genetics, that it is an artifact of the world physics and that it should be the responsibility of the engine to maintain state and track this. Okay, I'm fine with this, but then lets be consistant. If venom wearing off is the resposibility of the the engine, then all venom should wear off without the bot having to do anything. A bot might and should be able to make it wear off faster by adding anti-venom code to it's DNA, but IMHO this should not be a necessary condition for any and all venom wearing off eventually. If we are going to have the engine maintain venom state and make venom wear off, then it should do so regardless of what kind of venom it was. Personal opinion.
Now, I fully realize that there is a lot of code history and that the engine, design and sysvars/mem have evolved over time (pun intended). There will always be inconsistances like this in any version. I just wanted to generate some discussion as to whether in future versions, we want to address this in some way. The two possibilties I see are
a. Getting rid of all venom state in the engine and making it entirely the responsibility of the bot to code for anti-venom. Bots can use venom to write to another bots memory, most thigns work liek they do today I.e. the size of the victum's shell and the size of the venom shot dictate whether or not it gets through, etc. but how long it lasts if it does get through is completely the resposibility of the venomized bot. If the bot has no anti-venom DNA, the venom lasts forever.
b. Enhancing the engine to handle multiple types of venom and enhancing the state maintained by the engine so that it remembers the value of toggles before they were venomized and puts them back when the specific venom that impacted that memory location wears off.
Hey, if a newbie isn't good for stirring things up a little, what the hell good are they for anyway? :)
-E
-
I like this sort of discussion. I had many similar ones when I first joined, which resulted in several reworkings for the better.
I'm not sure I understand what you mean by "bot genetics" being responsible for venom wearing off.
At present, venom attaches itself to a memory location and rewrites it with a certain value for X many cycles, then it stop overwriting it.
What are you suggesting an alternative would be exactly? I agree with all the issues you've pointed out with the present situation, but I misunderstand the solution you pose.
-
It's not completly thought through. For example, it may end up being just too difficult for bots to code for policing their own memory, selection might favor having a super thick shell, etc. but here's he idea:
The engine would retain all the present code for deciding if venom makes it to a bot, .mkshell would work the way it does today in impacting venom shots, etc. But if the venom shot was successful, instead of the new value being 'asscoiated' with the specific memory location in the victum and used as that value by the engine if the bot is still paralyzed, the new value would actually overwrite the location in the bots' memory. The engine would no longer need to remember the previous "real" value becuase it would no longer be the engine's responsibility to put the "real" value back. The engine would no longer maintain a count for how long venom lasts. The .paralyzed sysvar would go away. Venom would last forever unless the bot heals' itself by detecting the change and rewriting the venomized location back to an appropriate value (or another bot of the same species helps perhaps - can you say 'anti-venom venom'?). How does a bot know what the 'real' value is? That would be entirely the resposibility of the bot. The engine would NOT remember this. It's stateless here. The bot would have to code for that in it's own DNA. Think of the way it works for .Fixed today, but for all memory locations. Venom wearing off becomes totally the resposibility of the bot, not the engine. Don't want to wory about policing your own memory? Grow a really thick shell!
The .shootval for a -3 shot would be used not for determining how long the venom lasts but instead perhaps imapcting the distance of the venom shot or the probability of it getting through the victum's shell (like it does for -6 shots I think). The more venom you used, the farther it goes, the higher the probability of it getting through the shell, the more it costs you. .mkvenom works the same way it does today.
-E
-
FYI, one reason I like the idea of venom replacing the actual location in the actual memory array is that the bot's memory is then the same for both the venomized bot and other bots around it who may look at it's memory. The engien doesn't have to "fake it out."
For example, when playing around with venom, I think I saw that even after bot A used venom to change bot B's *.myeye, *.refeye for bot A still returned the old value. Might be a bug, but I think what a bot sees when it looks at itslef and what other bots see should be the same.
-E
-
I see one major problem with leaving the bots to police their own memory.
It would remove the entire effectiveness of venom. You might as well delete venom entirely since it is already possible to rewrite any memory location to any value using information shots. In that system, the value is overwritten then the engine forgets all about it and the affected bot is free to detect it and fix it if it is able to.
The concept of venom is that a bot can fix another bot's memory location for a number of cycles equal to the power of the venom shot. This venom fixing is specifically designed to continue to overwrite the memory location, no matter how many times the victim tries to fix it. Effectively the envenomed bot is utterly helpless against the venom, as are real organisms effected by a neuro-toxin.
Your point about the toggle for fixed is a good one though. Maybe the engine should remember the old state and return it when the venom wears off.
Multiple venom shots. Right now, one venom is the cure for other venoms. The latest venom shot to hit will overwrite the effects of the previous one. Think of it as a chemical reaction of the toxins. the timer remains and is added to but only the latest shot will have an effect
If you can figure out how, you might be able to use this to cure yourself of venom by having another bot (like a conspec) fire a harmless venom shot at any envenomed conspec it finds, overwriting the damaged memory location.
How is it that I always think of these sneaky things while answering posts :blink:
-
For example, when playing around with venom, I think I saw that even after bot A used venom to change bot B's *.myeye, *.refeye for bot A still returned the old value. Might be a bug, but I think what a bot sees when it looks at itslef and what other bots see should be the same.
No it shouldn't. if the venom makes it read *.myeye wrong then that is simply because it's senses are screwed up. It has double vision or something.
Just because I think I have 13 fingers and 7 toes doesn't mean that you will count them that way. It just means that I am suffering from deusions.
-
Ah. The subtlty that one design point for venom was that the venomized bot is prevented from changing the impacted location back until it wears off escaped me. Also, I have not looked at info shots yet. Had I done so, I would have perhaps saved us all some typing. Please hang on a moment while I remove foot from mouth.
So, yup, my propsal is akin to getting rid of venom completly. Let's not. To prevent bots from changing the impacted location until the venom wears off, which sounds like a fine feature of the world to me, the engine [you]must[/you][/I] maintain the state. I humbly withdraw my proposal.
Perhaps I'll look through the code at all the toggles and propose something on expiring all types of venom... but not today... :banghead:
-E
-
I do like the idea of different flavors of venom not cancelling each other out.
There are two things associated with this:
1. Bots that make venom should have to make a specific flavor of venom, which can't be turned into other venom later.
ie:
If you target .myeye with venom, and start making it, you shouldn't be able to later target .shoot and use the old venom that targets .myeye.
2. Bots with multiple venom should have multiple venom effects.
This way I imagine a bot could make and use several varieties of venom that do all sorts of things, sort of a deadly coctail of various effects. Fir ethe conspec confusion the first cycle, then use paralysis the next cycle, etc.
-
FYI, that is preciesly what led me to this thread. My my first bot uses venom for exactly that: conspec confusion to avoid attacks then fixing in place to prevent the prey from running away. I also shoot different venom at differnt bots I.e. conspec confusion for attackers, .fixed venom for veggies in motion. The latter is useful for dumb bots like mine that don't have sophisticed vision, trajectory plotting or shot aiming (yet). Eating stationary salad is just easier.
-E
-
Random thought: I might be happy to restrict bots to one kind of venom. That way if you want to shoot multiple kinds of venom, you have to be a multi-bot. Simple way to keep the venom sacs and costs separate and one more reason to evolve MB level complexity.
-E
-
Here's something else to think about: Venom effect on 'species'
Venom doesn't affect conspecs: is this too artificial? Should bots be able to evolve venom resistance? How should resistance to venom be controlled?
etc.
:D
-
My $0.02. Warning, opinion spewage below.
/Soapbox on
Venom doesn't affect conspects: is this too artificial?
I would say yes. I changed my little learning bot to use info shots to fix prey instead of venom after the discussion above and quickly found they were fixing each other occasionally with all those fixing info shots flying around until I added the .fixed checking/resetting gene. So, I'm already coding my bots against a sort of anti-venom from conspecs. I'd (perhaps naively he says) state venom should indeed impact conspecs and that if a species needs to avoid venom from conspecs, either they grow a sufficient shell, aim better or code around the impacted location (e.g. if they shoot *.myeye venom, use *.refshoot for conspec recognition instead of *.refeye.
Should bots be able to evolve venom resistance? How should resistance to venom be controlled?
I'd say sure, bots can evolve venom resistance, but not in anyway that the engine is aware of, which is essentially saying no to what I think is the essence of your question. Bots can evolve whatever ways they want to work around the impacted memory location or evolve ways to prevent it from getting overwriten in the first place - thicker shells, etc. but I'm kind of naturally resistant to adding more n^2 feature-specific state for the engine to carry around for each bot. The engine would need to track each bots resistance to each type of venom, we would need to add some sort of *.mkvenres sysvar, etc. or whatever the point being the engine has special case code for this functionality.
Now, this is where a personal philosphy of mine rears it's ugly head. Gack, how do I say this clearly? I think a highlevel design philosophy for DB should be for the DB engine to focus as much as possibile on general physics, on simulating and providing data about artifacts of the bot's world and that it should try to remain out of low level features where possible and be as stateless as possible with respect to how much bot specific, feature specific state it carries around. That is, to a reasonable extent, my preference is for the engine to provide the environment and let specific features such as venom resistance evolve within the DNA. That's not very clear I know, but perhaps using an example....
Say we wanted to provide the ability for bots to dodge shots. On the one hand, we could provide all sorts of special case capabilities for this one feature: *.mkdodge and *.refdodge sysvars, etc. and let the engine do all the work of maintaining state about each bot's shot dodging ability, how that wears off over time, figuring out if and when bots successfully dodge shots, maybe shots with higher .shootvals are harder to dodge, etc. This is what I would term a whole bunch of feature specific code in the engine, a whole bunch of feature-specific state. In this design, the engine would be intemently aware of all the nuances of this specific feature.
But my preference would be to instead enhace the engine to make shots tangable and visable I.e. make them part of the world physics in a general way. Any shot dodging ability would have to evolve or be coded for in a bot's DNA, but so could potentially lots of other features without the engine being explicitly revved e.g. hiding behind veggies, shooting waste as a protective screen, anti-shot shots, child sacrifice, perhaps tieing to a shot? and so on. The engine remains as general as posssible - all it does is calculate who sees what shots and handle the physics of that (yea I know, not trivial) but the point is it remains focused on the physics of the world, providing the environment for specific capabilties/features to evolve or be coded for, but not getting bogged down in feature specifics.
Whew. I needed that.
/Soapbox off
-
Now, this is where a personal philosphy of mine rears it's ugly head
in full agreement.
you rant more clearly on this than I have in the past. ;)
let the engine provide the environment ... the general world physics ...
within which ... the bots are allowed to evolve, or not.
I know it's a give and take ...
and sure PY and Nums will have plenty to say/share.
-
I don't like artificial rule sets. I like to keep things relatively simple and have the interactions between the simple parts define the world, so I agree with you guys. That said, sometimes that's more difficult in practive than in theory.
Here's what I see we want:
1. A way for bots to produce and react to different kinds of venom. Different kinds of venom don't cancel each other out like they do right now.
2. A voluntary conspec recognition system. That is, bots can design or react to venom in such a way that they are immune to conspec's venom if that conspec agrees to doing so.
I've been thinking aout the combat system and how to change it for when I add phagocytosis. Here's what I'm thinking at the moment:
Revamp the entire combat system into the following:
Attack - Defense
-1 nrg shots - Shell
Phagocytosis (eating another cell whole) - Poison (with poison not acting like it does now. Instead, it would either drain energy from the digesting cell, or make the cell throw up, or something like that. It's highly discussable).
Tie feeding - Slime
Venom and Info Shots - Anti-Venom (or you could call it something else. Name isn't that important). Also stopped by Shell perhaps.
(Viruses wouldn't be an attack that would work well against another species (at least, not without some modifications probably). Viruses would be moved to be more for evolution simulations, where I think they belong. This is another topic all together...)
Venom would be produced with two characterstics:
Conspec value and memeory location/value.
Conspec value is something I've been wanting to introduce for a while. It's a value that a bot can set. Venom that tries to attack a bot with the same conspec value won't harm that bot. Ties that fire at a bot with the same conspec value won't be effected by that bot's slime. .conspecID or something similar would be a super private sysvar that other bots can't either write to or read from. Severeal existing sysvars would be moved to a similar private sysvar array for things generally accepted as private, such as delgene. (That is, there are already private sysvars, I would just be formalizing the idea into a specific memory range).
Memory location/value would be where and what the venom does.
Venom that effects a bot is placed in a venom array that keeps track of what memory is being effected, controls the venom countdown, etc.
Venom produced by a bot would similarly be kept in an array that keeps track of what kinds of venom have been produced and are ready for use.
Anti-Venom works just like Venom except it stays in the bot and reduces the time effect of venom, being used up in the process.
I don't present the above as a finalized idea. It's strictly a work in progress in my mind. I present it now as an idea. It does introduce alot of new crap that isn't strictly as clean as I'd like. Feel free to take it and modify/mutilate it to create a better idea.
-
Engine or not engine? That is the question.
Well first up you need to define what exactly you mean by the "engine".
If you mean the "physics engine" then what you say is entirely true. We need to develop DB such that this engine just maintains the environment and has little to do with what the bots do with it.
However there is a cross over in which the "engine" actually handles DNA actions. Something has to. The rules of the world's physics have to interact with the bot's DNA at some point. This is where we get the dilema. What exactly is the cutoff point where DNA handling engine stops and the physics engine takes over?
It would be great to get rid of all the arbitrary rules that plague DarwinBots but the problem is again.. What do you define as arbitrary? In real life, venom gets into the system of an organism and screws with it until either the organism dies or its metabolism manages to get rid of the venom. This, of course, takes time.
The present venom system is rather simple and was designed to replicate the effects of venom wearing off. It is rather imperfect and is one of the things that will benefit greatly from the new metabolism systems when they are implemented. It would be unrealistic to simply allow the DNA to remove venom as soon as it is detected. Even if we had a sysvar command such as .removevenom in which you can store energy to forcibly eject the venom, you still need some sort of "counter" that tracks the current level of venom in the robot's system. That counter has to be managed somehow.
Example: A robot has 4000 energy. It is hit by 16,000 points of venom (a really nasty dose). Some counter somewhere (possibly one of its memory locations) holds the venom value. It detects the venom and then saves some value into .removevenom to remove the venom. It can only spare 500 energy and this will remove 500 points of venom so it still has 15,500 left.
Now what? Does the venom remain until the bot can spare more energy to actively remove it? or do we just let it go away gradually? (like it does now) Either way it has to be tracked. We are just shifting the onus of tracking it from the main engine into the DNA engine.
Oh wait a minute. The two are actually the same thing as far as the program goes <_<
One improvement would be for the robots to have varying levels of resistance to certain venoms (ie. having memory locations forcibly changed for more than one cycle) This resistance could be learned and remembered but then we would have to track that too. A whole array equal in size to the actual memory array, would be need to track it.
Alternatively we use enzymes in the new metabolism system which are more or less efficient at removing venom. this allows for random mutations and selection based on venom immunity. That would be my vote.
Even so the enzymes would simply effect the efficiency of venom removal and th evenom still has to be track by some engine or other.
I just don't see any feasible way to totally remove venom from the physics engine, after all venom does have a physical effect on an organism. :unsure:
-
Like the idea of conspecID. Would remove alot of the unatural effects of bots being conspecs. Canni's should be affected by another's venom like any other bot.
Would also making MB's much easier. Slime wouldn't be the major drawback it is now.
Perhaps bots in confusion could also change it to receive some sort of assistance from family.
Poison isn't similarly neutralized between conspecs is it?
I have one of my main EvoBots using this to moderate cannibotism, and it always seems to work.
-
I thought poison was conspec immune, but I may have broke that when I rewrote the shot routines a while back. Or I could just be wrong (a first time for everything :P)
-
At least in 3.6 EvoBot5.4StemA seems to work right. A cannibalistic conspec is poisoned, making it a non-conspec(in regards to the bots feeding). The unfortunate bot is quickly recognized and eaten.
If it wasn't working right the bots under mutations shouldn't be able to reach anywhere near the population levels they routinly manage.
-
Poison isn't similarly neutralized between conspecs is it?
Conspecs should be imune to the poison of their brethren.
Unless it got broken somewhere down the line.