Author Topic: Costs  (Read 3507 times)

Offline shvarz

  • Bot God
  • *****
  • Posts: 1341
    • View Profile
Costs
« on: January 07, 2007, 07:03:03 PM »
I don't like imposing costs on DNA maintenance, so in my sims I usually try to reduce all the command-related costs and bring the cost of "doing things" up instead.  My thinking is that most costs should apply to physical actions in the world, not to having some commands in DNA.  But we are quite limited in the amount of physical costs.  There are shots, tie formation, movement and creation of some substances, but that is about it.  So as a result, the energy does not go out of sim quickly enough and I have to come up with other ways to drain energy, such as impose age-related costs or higher friction.  

I think we should simplify the costs for DNA by charging some flat cost for DNA maintenance/command and instead add more physical costs.  So far I came up with the following: Costs for rotation, costs for pumping energy through ties, differential costs for different kinds of shots, costs for expelling waste, costs for moving ties around.

Any other ideas?
"Never underestimate the power of stupid things in big numbers" - Serious Sam

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Costs
« Reply #1 on: January 07, 2007, 11:58:52 PM »
I concur with the direction here 100%.  We may not want to remove legacy DNA costs for backward compatability reasons, but I'm all for focusing on morphological action costs.

That said, where possible, I favor having costs be imposed implictly as a fucntion of physics instead of adding tons of new explicit costs for each and every possible action.  For example, if we completed the code necessary for tie drag, then in addition to enabling swimming and other more realistic modes of locomotion, the cost asccessed for moving a tie would be implicitly proportional to the force necessary to move the tie against the fluid resistance/friction of the tie and tied bot (we might want to move to an effort-based paradym instead of an absolute paradym like has been discuessed previously for rotation so that bots deicde how much effort to apply to the movement attempt and pay a cost proportional to this instead of ensuring the movement and charging whatever it takes).  The cost of a multibot or a battery bot moving would be impacted by the tie drag forces.   Instead of adding a new entry line for a new cost, nrg loss would be  imposed implictly as a function of and proportional to the physical actions.

Another idea to simplify and standardize costs would be to agree on a (optional) vector of store costs for every location in the memory space and then allow the user to have a single setting that simply scales this vector - a pre-defined cost-set if you will.  Since most morphological actions are associated with a store/inc/dec to a memory location, we just decide how expesnive each location should be relative to each other.  Stores to .shoot might cost 10X, stores to .up might cost 5X the value, stores to .eyeNWidth might cost 2X, stores to non-sysvar locations might be free.  You can store to the same location as many times per cycle as you want, you only get charged for one.  Reads from memory are always free.

Another idea is to charge costs using a non-nrg based effeciency currency based upon the frequency or infrequency of certain events.  For example, if the bot has had no nrg intake with a certain number of cycles, regardless of it's absolute nrg level, extoll a "hunger" effectiveness cost by reducing any movement value it stores by X% due to hunger or by reducing it's eye sight distance by X% until it eats again.  If it goes too long without eating, kill it even if it has nrg.  Similar things could be done for going to long without reproducing, etc.

Additional morpholigcal cost ideas:

Costs for changing eye widths, direction or changing the focus eye.
Non-linear movement costs - going 2X faster takes 4X nrg, etc.
Tie length, angle, rigidity changes.

FYI, there is already a cost for voluntary rotational movement.

Here's another idea.  The reason we have costs is to provide selective pressure, right?  Survival of the most effecient and all that?  Well, in nature, most selective pressure isn't a function of how much nrg it takes to chase or flee or bite or produce posion or move our arms.  Its about behaviour that influences competecy that ultimatly impacts competitive success.  Outrunning the lion is often less about speed and more about strategies of avoiding being the one closest to the lion or letting a lion get too close to the herd or confusing the lion with lots of vertical stripes.  Said another way, most organisms don't starve, they get eaten with lots of nrg still left in their tank.  There are other ways to provide selective pressure besides nrg costs.  One might be a built-in, population level driven super preditor that adjusts to the human defined targets.  As bot populations rise above some target, the built-in preditor gets better a culling the pack.  It moves a little faster or shoots a little better or sees a little better or increases in numbers.  As popualtions fall, it gets worse at doing it's job.  At some level, it does nothing.  Tada!  Selective pressure without costs!
Many beers....

Offline shvarz

  • Bot God
  • *****
  • Posts: 1341
    • View Profile
Costs
« Reply #2 on: January 08, 2007, 01:10:14 AM »
OK, I'm glad that we are thinking in the same direction.  I like your ideas, except for the one with "hunger" - that is just too weird.

I actually don't see the costs as necessarily a way to impose selective pressure.  It's just a way to set the total energy input equal to total energy output and to keep the population stable.   Well, not exactly stable, but cycling up and down.  Your predator idea is OK, but that predator may be kind of hard to code.  Things like scripts would do the same and would be much easier to manage.  For now just applying age-related cost is a good stimulus for bots do procreate
"Never underestimate the power of stupid things in big numbers" - Serious Sam

Offline Testlund

  • Bot God
  • *****
  • Posts: 1574
    • View Profile
Costs
« Reply #3 on: January 08, 2007, 03:23:39 AM »
Quote from: shvarz
OK, I'm glad that we are thinking in the same direction.  I like your ideas, except for the one with "hunger" - that is just too weird.

Have to agree with Shvarz here.  The only kind of energy in a sim is NRG numbers. In a real organism there are tons of various kind of energy sorces that needs to be balanced for an organism to work efficiently. If a human were like a darwinbot we whould work at top efficiency until the last joule gets consumed, then we just drop dead! That's not how it is though.  
The internet is corrupt and controlled by criminally minded people.

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Costs
« Reply #4 on: January 08, 2007, 05:26:44 AM »
Quote from: EricL
Another idea to simplify and standardize costs would be to agree on a (optional) vector of store costs for every location in the memory space and then allow the user to have a single setting that simply scales this vector - a pre-defined cost-set if you will.  Since most morphological actions are associated with a store/inc/dec to a memory location, we just decide how expesnive each location should be relative to each other.  Stores to .shoot might cost 10X, stores to .up might cost 5X the value, stores to .eyeNWidth might cost 2X, stores to non-sysvar locations might be free.  You can store to the same location as many times per cycle as you want, you only get charged for one.  Reads from memory are always free.

I've thought about this sort of thing from time to time, though not dealing with costs.  I've come to the conclusion that it's just too unweildly to let the user tweak things on so basic a scale.  There are hundreds of sysvars.  Users already have issues with the two dozen or so current costs.  It's just too much.

Most of the current costs page is just too much.  The options panel in general is too frightening to new users, and needs to be pulled back where possible.

I would like to pull DNA costs back to:
1.  Cost per execution - A standard cost for every bp that is executed.  DNA that isn't executed is free (junk DNA, conditions in start blocks, etc.).  DNA that is executed more than once (say, in a codule) has higher costs associated with it.  I would primarily like to see this used in leagues, not so much in evo sims (evolution seems to like alot of wiggle room.  Our own DNA is billions of base pairs, the vast majority of which do not (seem to) code for genes.  DNA efficiency doesn't seem to be the driving force behind natural selection.

2.  Base Pair Upkeep - A simple cost for maintaining each base pair every cycle.  Again, primarily for leagues I think, and maybe to prevent the DNA of bots from becoming insanely large.

That would pretty much be it.

The aging costs and cost overrides are also a little scary.  A user might want to change threshold values for every cost, or change specific costs based on population, etc.  If/when scrips are setup, I would relegate these sorts of things to scripts.  Try to tone down the complexity of the options panel for new users.

Quote
Non-linear movement costs - going 2X faster takes 4X nrg, etc.

This can be set up if you understand how the physical environment works.  For instance, a highly viscous environment is going to give you non linear movement costs because of fluidic drag.  A turbulent flow is going to give you quadratic costs.

Quote
FYI, there is already a cost for voluntary rotational movement.

Did you ever finish this?  I know it's setup in the C++ source, and I know you were asking about it, but I don't remember if you ever added it to the code.

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Costs
« Reply #5 on: January 08, 2007, 11:19:44 AM »
Quote from: Numsgil
Did you ever finish this?  I know it's setup in the C++ source, and I know you were asking about it, but I don't remember if you ever added it to the code.
It's always been there on the costs's dialog since I started on the code, but your right, it's not wired up.  You can set it, but it doesn't get used.  I'll wire it up in 2.42.9t.
Many beers....

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Costs
« Reply #6 on: January 08, 2007, 11:37:35 AM »
Quote from: shvarz
Your predator idea is OK, but that predator may be kind of hard to code.  Things like scripts would do the same and would be much easier to manage.  For now just applying age-related cost is a good stimulus for bots do procreate
You can't run from a script.  The predator would provide selection pressure because it would be something the other bots could see, fight, flee from, hide from, gang up on, fool into leaving them alone, etc.   Bots that did this better than others would be selected for.  Bots that didn't... would provide your nrg loss.

It would not be hard to code.  I'd do it the same way veggies are done.  You add an organism you want as the preditor.  Make it as good or as bad as you want but Animal Minimalis would work fine.  It's population is capped.  It gets repopulated if necessary acording to user set parameters.  Generally, it is restricted by the system.  At one extreme, when the bot population is low, it is prevented from doing anything - it can't move or shoot or tie or anything.  Other bots can eat it if they want.  As the bot population rises, the restrictions are lifted incrementally.  It can move a little, it shoots very week shots, etc.  At the far extreme, when the population gets too high, it's an armored T-rex with laser beams for eyes.  It can't be hurt, a single shot kills, it's ties cut right through slime, it's shots travel 10X normal speed, it can exceed the max speed limit, hell I can make it teleport right to you and have it kill you just by seeing you if I want!  

You see, it would easy to code since it doesn't have to play by the rules.  Think of them as Agents in the Matrix.  
« Last Edit: January 08, 2007, 03:40:50 PM by EricL »
Many beers....