Code center > Suggestions
Camoflage
EricL:
I propose a new sysvar, .camo , which would impact the degree to which a bot can be seen by other bots. It can be thought of as a substance, like .slime. It costs nrg to make, it degrades over time, I'd probably make it relatively expensive, say a 1:1 ratio with nrg (takes 1 nrg to make 1 .camo)
What I would do is use a bot's .camo value along with it's radius and distance from a viewing bot to determine whether to populate the eye(s) of the bot viewing it. It would take more .camo to hide larger and/or closer bots, less when the bots are smaller and/or farther away.
As a first blush algorithm, I might do something like the following:
Compute the ratio of the .camo value to the bot's radius (call this A) and compare this value to what the viewing bot's eye value would be were there no camofladge (call this B ). If A>B, the bot is invisible in that eye for the specific viewing bot that cycle. If A<B, then the probability of the bot being invisible in that eye is proportional to the ratio of A/B.
An example. A bot has radius of 50. It has .camo of 200 that cycle. Thus, A = 4. If a viewing bot is far enough away that it's eye value without camofladge would be <=4 when viewing this bot, the bot is invisible. If it's closer, say the eye value would be 8 absent any camofladge, then the probability of the bot being seen - of an 8 being populated for the viewing bot's eye sysvar instead of 0 - that cycle is 4/8 or 50%.
Note that I do not want to make the actual eye value larger or smaller as a function of camofladge. Specific eye values to me are about distance, not camofladge. In my mind, camoflage impacts whether a bot is seen or not, not how far away it appears to be if it is seen. So, my proposal would result in the eye either having the same value it would have had were there no camoflage or 0 but not something in between.
Now, let me just head off an objection I know some people might make and that is that instead of just inventing a substance and making it work magically under the covers we should instead invest in lower level environmental artifacts such as color, texture, etc and allow camoflage to emerge out of this richer notion of vision. For example, making it harder to see bots of a given color or testure against the background of a shape or the field itself of a similar color or testure.
I'm all for this notion of camoflage and I hope we have it someday, but it predicates a bunch of stuff that doesn't exist today and will be costly from a cpu cycle perspective (e.g. a richer vision system, computing the visibilty of a bot against a background, etc.). Personally, I'm most interested in spending cpu cycles evolving interesting behaviour, not sensory machinery, so I take the position that my proposal could encourage the evolution of interesting behaviour in this area today with neglible perfromance impact (e.g. did I really just see something? Let me get closer to check even though I don't see anything now. Oh no, here comes a peditor! Quick, spend a bunch of nrg to create camo while fleeing or hiding in plain sight. and so on...).
Additionally, my proposal is in keeping with the way such things as .shell or .slime work today. While we want to have richer underlying facilities underlying such artifacts someday, we haven't yet invented mechanisms (for eaxmple) for aquiring calcium or other minerals and for creating an internal shell manufacturing process, a process for depositing substances on the outside surface or the bot, physics for different substances interacting with and potentially deflecting shots and so on. We just made .shell work magically through a single sysvar. I want the same thing for .camo, at least until things get rich enough to let it go.
The perf impact from this proposal would be neglible.
Comments?
MacadamiaNuts:
Could eyewidth fit in the formula?
The abuse of the omineye has got to shameless levels lately.
EricL:
--- Quote from: MacadamiaNuts ---Could eyewidth fit in the formula?
--- End quote ---
Right now, I'd say no. The reason is that I think of eyewidth as a kind of field of view and our eye value paradym today is only distance. In particular, it does not take resolution into account. If we added additional eye modes, which I want to do, which functioned on resolution and say, spread resolution across the eye width, than there woudl be a greater disadvantage to wider eyes (wider eyes, less resoultion per eye) and we could factor it in to the .camo calculation. For example, if the eye value was not a distance but rather a percentage occlusion, than we could have .camo impact this (I.e. reduce the percentage occlusion due to the viewed bot) but as it is, with the eye value a distance, I don't see a good way to factor in the viewers eyewidth into the .camo calculation.
--- Quote from: MacadamiaNuts ---The abuse of the omineye has got to shameless levels lately.
--- End quote ---
I'd be happy to entertain ways to address this. Put a limit of 90 or 180 degrees on the .eyewidth sysvars for example. Getting rid of xpos and ypos would help also. So would moving to an occlusion paradym as above.
Peter:
Okay, so the % chance a bot sees another will be
(.camo/.body)<--other bot:bot using camo(ratio camo/body) exact formula I don't know.
-------------
.eye5<------------your own.
So if this is true.
Well the contra points are
I gues CPU-speed as the seeing not seeing has to be calcucated for every bot.
Why it is good.
Well it is something new. That's always good. And it sounds like a whole new fun feature.
I am not yet sure what side to take.
If the CPU-hits will not be too bad. Well you have a better view there.
If it can't be used too abusived used into the leagues, as it seems as a powerful if cheap.
You said you wanted to make it reletevily expensive, then that is fine. Would be fun to see bots use camoflage.
My question.
How much calculating has there to be done extra, can it be avoided if the bots don't use it ot will it always be calculated.
EricL:
As I say above, the perf impact will be neglible. In fact, I have a vision optomization in mind which I'll do at the same time which could dramatically improve the performance of sims with dense clumps of bots and do away with at least some of that slow down that occurs when bots explosively reproduce in close proximity.
Navigation
[0] Message Index
[#] Next page
Go to full version