Author Topic: Camoflage  (Read 10460 times)

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Camoflage
« on: November 30, 2007, 01:41:45 PM »
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?
« Last Edit: November 30, 2007, 01:48:59 PM by EricL »
Many beers....

Offline MacadamiaNuts

  • Bot Destroyer
  • ***
  • Posts: 273
    • View Profile
Camoflage
« Reply #1 on: November 30, 2007, 01:52:51 PM »
Could eyewidth fit in the formula?

The abuse of the omineye has got to shameless levels lately.    
Sometimes you win, and sometimes you lose...

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Camoflage
« Reply #2 on: November 30, 2007, 02:06:52 PM »
Quote from: MacadamiaNuts
Could eyewidth fit in the formula?
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.    
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.
Many beers....

Offline Peter

  • Bot God
  • *****
  • Posts: 1177
    • View Profile
Camoflage
« Reply #3 on: November 30, 2007, 03:26:48 PM »
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.
Oh my god, who the hell cares.

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Camoflage
« Reply #4 on: November 30, 2007, 03:47:45 PM »
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.
Many beers....

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Camoflage
« Reply #5 on: November 30, 2007, 03:54:45 PM »
Quote from: 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.
This is incorrect.  It is .camo/radius NOT .camo/.body and the same calculation is done for all eyes, not just .eye5.
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Camoflage
« Reply #6 on: November 30, 2007, 05:08:07 PM »
I have no problems with this, I'm planing on doing something similar with DB3 (increase vision radius to infinity and just limit sight based on apparent size, with camouflage (you spelled it wrong in the title btw) modifying this...)

For the present, I think speed needs to be incorporated in to it.  Real life camouflage is about looking like a rock or leaf-- that is, things that don't move, or move really slowly.  A cheetah running at 60 mph does NOT look like shadows interplaying on leaves.  It looks like a big hungry predator.  This would also encourage some smarter strategies for hunting.  You could just camouflage yourself real well and sit and wait in one place until something comes by, then leap out and kill it before it can react.
« Last Edit: November 30, 2007, 05:14:43 PM by Numsgil »

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Camoflage
« Reply #7 on: November 30, 2007, 06:17:47 PM »
Quote from: Numsgil
camouflage (you spelled it wrong in the title btw) modifying this...)
speling has never been one of my strong points.    Autocorrect has ruined me.  My fingers go the wrong places now.

Quote from: Numsgil
For the present, I think speed needs to be incorporated in to it.  Real life camouflage is about looking like a rock or leaf-- that is, things that don't move, or move really slowly.  A cheetah running at 60 mph does NOT look like shadows interplaying on leaves.  It looks like a big hungry predator.  This would also encourage some smarter strategies for hunting.  You could just camouflage yourself real well and sit and wait in one place until something comes by, then leap out and kill it before it can react.
A most excellent suggestion.  How about if I subtract |velocity| * X from the effective .camo value and defeat camo completely when |velocity| exceds 25% of maxvel?.  Suggestions for X welcome.  I'm thinking maybe 20?

Also, I need a degredation rate.  Slime degrades 2% per cycle.  I'll make .camo the same barring better ideas.
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Camoflage
« Reply #8 on: November 30, 2007, 06:26:22 PM »
I'm not a fan of linear relationships (as the bunches of weird atan formulas in the shot code probably told you ).  My new favorite kernel is 6t^5 - 15t^4 + 10t^3 where t is in [0,1] and gives results in [0,1] (makes it easy to scale the domain and range) because it's easy to calculate and has 0 first and second derivatives at its end points.  (Off topic: you might want to replace those weird atan formulas with this kernel since it's easier to visualize and graph).

Using a formula like this, moving slowly and not moving would be comparable in effectiveness, but then the loss in camo ramps up real fast.  Once you get near maxvel, the effectiveness bottoms out and changes very slowly from 95% maxvel and 100% maxvel.
« Last Edit: November 30, 2007, 06:27:22 PM by Numsgil »

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Camoflage
« Reply #9 on: November 30, 2007, 06:34:48 PM »
I like it having a non-linear relationship w.r.t. velocity.  Seems like a lot of exponentials to compute for something like this, but I'll make it work.  I'll use a look up table or something.

EDIT:  Also I wonder whether we want to scale it up to maxvel or only up to 0.25maxvel or similar.  Seems to me that at some speed, there's just no hiding and I can shortcut the computation that way.
« Last Edit: November 30, 2007, 06:36:27 PM by EricL »
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Camoflage
« Reply #10 on: November 30, 2007, 07:37:12 PM »
You can compute it in a numerically "good" way by doing:

t * t * t * (t * (t * 6 - 15) + 10)

I don't know how much you remember from whatever numerical methods study you probably did at some point in your career, but combining polynomials like this is considered the best way to minimize errors in the computation.  Also, I would avoid VB's ^ operator for this, since I'm not sure if it's smart enough to short circuit integer powers or not, and this way it'll match C code that uses this kernel.

Top speed-- I'm not sure.  At the extreme, I can imagine some sort of sci-fi cloaking device that manages to make a subject invisible even at high speeds.  A bot would have to spend crazy amounts on camouflage, but it could move around at higher speeds.  Of course, I'm not sure scifi has a place in the Darwinbots universe

Of course, one could imagine another sort of camouflage for high speed-- something like zebra stripes, killer whale shapes, and anteater stripes-- designed not to hide the animal but to hide characteristics of the animal, such as where the head is, heading, and speed.
« Last Edit: November 30, 2007, 07:38:52 PM by Numsgil »

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Camoflage
« Reply #11 on: November 30, 2007, 08:30:34 PM »
Quote from: Numsgil
I don't know how much you remember from whatever numerical methods study you probably did at some point in your career, but combining polynomials like this is considered the best way to minimize errors in the computation.
polynomials weren't invented yet when I was in school....
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Camoflage
« Reply #12 on: November 30, 2007, 09:53:14 PM »
heh

Offline Testlund

  • Bot God
  • *****
  • Posts: 1574
    • View Profile
Camoflage
« Reply #13 on: December 01, 2007, 08:09:11 AM »
I guess this might be an interesting feature, but I'm wondering about the realism of it. As I understand it most single cellular organisms are complete blind and they only know if something else is there if they bounce into it. That's why I once proposed shorter eye radius instead to simulate that, but nobody seemed to share my opinion.  
The internet is corrupt and controlled by criminally minded people.

Offline MacadamiaNuts

  • Bot Destroyer
  • ***
  • Posts: 273
    • View Profile
Camoflage
« Reply #14 on: December 01, 2007, 08:32:35 AM »
Oh, when I learned VB loong ago, I remember timing 2^2 vs 2*2 and the second one was a lot faster. It was VB 4 then, tho.
Sometimes you win, and sometimes you lose...