Code center > Suggestions
Eyes
Numsgil:
I would have all eyes a bot has cover the same angle. I can see problems otherwise.
Maybe something like this: each bot gets a field of view, centered around its aim. This field of view is subdivided into n eyes. Using a command similar to the one I'm developing for ties, a bot can change which eye has the focus during a cycle, which updates the different sysvars. Maybe you can switch focus only between eyes you designate as focusable eyes. Eyes without focus can only tell you the distance to the nearest object.
The more eyes a bot has, the more nrg the bot has to pay in upkeep costs. Focusable eyes cost more to maintain than the peripheral kind.
Turning eyes on, adding eyes, and increasing the field of view costs a significant amount of nrg, which should prevent bots from overly abusing their eyes, and encouraging specialization (narrow lookers for dog fighters, broad vision for grazers).
We can reserve sysvars 500 through 549 for eyes.
EricL:
--- Quote from: Numsgil ---I would have all eyes a bot has cover the same angle. I can see problems otherwise.
--- End quote ---
Such as?
--- Quote from: Numsgil ---Maybe something like this: each bot gets a field of view, centered around its aim. This field of view is subdivided into n eyes. Using a command similar to the one I'm developing for ties, a bot can change which eye has the focus during a cycle, which updates the different sysvars. Maybe you can switch focus only between eyes you designate as focusable eyes. Eyes without focus can only tell you the distance to the nearest object.
--- End quote ---
I'm not sure I know what you mean by "during a cycle". I think you mean that the bot can change which eye has the focus and update the refvars based on the new focus eye all in the same cycle. The same can easily be acheived in the model I outline. The bot could change the field of view and direction of eye5 and the code would update the refvars based on the new direction/focus all in the same cycle. In fact, this is how it works today I beleive. eye refvar values are a function of the new .aim value and are updated the same cycle.
I beleive the model I outline is the more general one. That is, with the exception of changing which eye is used to update the refvars (which could be added but is largly unecessary in my model because the direction of eye5 can be changed, potentially overlapping or subsetting other eyes without the bot turning) what you outline is a special case of what I outline in that in your model the eyes are not movable and have fixed field of view. Your model has the advantage (as does mine) of allowing bots to get information on the different objects they see without turning by changing the eye used for loading refvars, but unlike mine, does not allow bots to evolve different visual strategies w.r.t. the direction their eyes face and/or evolve strategies to narrow or widen their field of view dynamically as needed.
--- Quote from: Numsgil ---The more eyes a bot has, the more nrg the bot has to pay in upkeep costs. Focusable eyes cost more to maintain than the peripheral kind.
Turning eyes on, adding eyes, and increasing the field of view costs a significant amount of nrg, which should prevent bots from overly abusing their eyes, and encouraging specialization (narrow lookers for dog fighters, broad vision for grazers).
--- End quote ---
Eyes corrospond to sysvars. I do not see an easy way to allow some bots to have more eyes than others unless we add additional eye enable/disable sysvars, which personally, I don't favor for several reaons amoung them that a single point mutation can cause a bot to be charged for something it does not really use. I similarly dislike the idea of trying to determine which eyes a bot is using and how as part of DNA flow by trying to catch sysvar reads in order to charge more or less as that is extremely problematic given the various ways (that you recently pointed out in another thread) that exist to address sysvar locations.
In my model, all bots have the same number of eyes, but how they use them, wide or narrow and where they point them, ahead, to the sides, all around, behind them, wide and overlapping or narrow with gaps between them, or spinning around like a lighthouse beam is completly under the control of selection. If we wanted to charge bots for changing how their eyes are used (something I don't advocate but am not opposed to) we could choose to charge for sysvar operations such as changing the field of view of an eye or changing it's direction, which would be a a straight forward charge for storing to the corrosponding sysvars. But the issue of whether we charge for changing how bots use their eyes is IMHO somewhat orthoginal to what the right eye model should be.
--- Quote from: Numsgil ---We can reserve sysvars 500 through 549 for eyes.
--- End quote ---
My model requires 3 sysvars for every eye plus whatever refvars we choose to add for describing the properties of objects other than bots. For each eye, we need one read/write sysvar for the eye's direction relative to .aim, one read/write for the width of the field of view of the eye and one read-only for the eye value itself.
Given that each eye is movable and the width of field of each eye changable, I see no great need to add additional eyes beyond the current nine that we have.
Numsgil:
It's late night for me, so excuse me if I start to ramble...
--- Quote from: EricL ---I'm not sure I know what you mean by "during a cycle". I think you mean that the bot can change which eye has the focus and update the refvars based on the new focus eye all in the same cycle.
--- End quote ---
Say a bot is focussing on eye3. It can change the focus to eye5 and the refvars are all updated in the same cycle. Something like ".eye5 setfocus". All the refvars are updated to reflect the new visual target in eye5. The bot continues executing its DNA, then decides to switch to eye6. It does ".eye6 setfocus" and now its looking through .eye6. All the refvars get updated to reflect what eye6 sees. All this happens in the same cycle, while the DNA is still executing. Different parts of your DNA can see refvars through different eyes in the same cycle.
The idea is that we extend the system set up for using multiple ties in a single cycle to eyes as well. For this to make any sense at all, you'll need to know what I'm talking about with the new tie paradigm. It should be in the wiki.
In the present system, you would need to physically turn, which would take a full cycle, if you want to see refvars of what's in eye3.
--- Quote ---Eyes corrospond to sysvars. I do not see an easy way to allow some bots to have more eyes than others unless we add additional eye enable/disable sysvars
--- End quote ---
The above system I outlined takes care of this by overloading the existing refvars. .refnrg would correspond to the nrg of whatever you're looking at with your currently active eye. As you move your focus around, different data gets loaded into the refvars. You wouldn't need any additional refvars for 1 eye or 1 million, other than to allow for backwards compatibility with the eye1-9s.
--- Quote ---In my model, all bots have the same number of eyes, but how they use them, wide or narrow and where they point them, ahead, to the sides, all around, behind them, wide and overlapping or narrow with gaps between them, or spinning around like a lighthouse beam is completly under the control of selection. If we wanted to charge bots for changing how their eyes are used (something I don't advocate but am not opposed to) we could choose to charge for sysvar operations such as changing the field of view of an eye or changing it's direction, which would be a a straight forward charge for storing to the corrosponding sysvars. But the issue of whether we charge for changing how bots use their eyes is IMHO somewhat orthoginal to what the right eye model should be.
--- End quote ---
I'm thinking in terms of large creatures here. Binocular vision is a tradeoff against wider field of view. We could probably have both, but it would mean additional eyes placed on the sides or even the back of our heads.
We can't move our eyes around our head to change our field of view except through evolution. This is something that's difficult to do with the bots. We could have them only be able to change their eyes in the first 100 cycles of birth, or have it change randomly, but that's largely missing the point. If you let bots actively take control of their eyes, at any time in their life, there needs to be a cost associated with that. My body can't just grow another eye during a battle for nothing. Supposing it could grow an eye at all, of course. That eye takes effort to grow and connect into my brain.
The costs associated with vision are going to be instrumental in how they're used.
Ultimately wether we have 9 very customizable eyes or a greater number of more rigidly defined eyes, is largely a matter of taste. They're probably effectively the same. Feel free to cherry pick aspects of mine if they suit your fancy.
EricL:
Ah. I understand what you mean now by 'during a cycle'.
Independent of the eye model, I consider it beyond the scope of what I'm willing to do with the VB version in the short run to allow for multiple refvar updates within a single cycle.
I think we are in agreement on the way refvars should work as a means to gather a lot of information about whatever the bot is focused on I.e. the refvars should reflect the properties of whatever the bot is focused on, be it another bot or something else. How that focus is achevied, by changing the direction of one eye or by switching from one eye to another is still a point of debate.
I suggest that only advanced, corridnating multi-bots should be capable of true binocular vision, that we should never allow eyes anywhere on a single bot other than at it's center. Note that since eyes read back distance, we already have some aspects of paralax vision with single bots (we are lacking depth of field) even when only using a single eye.
I am not suggestting that the number of eyes a bot has is changeable or that it can "grow eyes" as needed. What I am suggesting is that a bot can look around without turning it's body.
Most biological organisms (that have eyes) can move their eyes independent of their body, including us and there are many bilogocal organisms capable of wide ranges of eye socket movements including some with eyestalks that can cover the full 360 degrees with a single eye.
Because all eyes are at the bot's center, what I propose is much more akin to eyeball movement within a socket, not physical movement of an eye around onto different places on an organism and given that bots are virtual organisms, I see no reason for us to artifically restrict the potential degrees of eye socket movement.
We can have costs for changing the properties of an eye if people want, the direction it points and it's field of view, but I see such costs as much less critical than you do since I equate these operations to simple eyeball movement within a socket and changes in lens focal length, bascially inexpensive muscle movements for biological organisms.
And I should point out there is a natural cost tradeoff of sorts in being able to change the field of view of an eye. The wider the field, the more I can see, but the less I know aboat the things I do see I.e. I give up resolution for width of field. This alone seems sufficient to me to provide selective pressure on eye field of view.
Numsgil:
Sounds good.
Multiple sysvar updates in a cycle isn't as hard as you might think. The trick is really storing all your data in the eyes and loading them into memory as your focus changes. If changing your focus is a command, it acts much like a store or inc command, in that its changing memory values.
I can probably rig up this part of the system if you don't want to hassle with it.
Are you still restricting eye5 as being the only eye that can receive focus? My primary concern is providing potentially different costs between peripheral "eyes", that only give distance and no information, and focus eyes, which give more information. This is sort of moot if only one eye can be used to focus.
Everything else I'm pretty indifferent about.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version