League Settings

[EricL]

That or a DNA upkeep cost.  No objection to either here, but perhaps someone else who has actually written a combat bot (I.e. not me) should comment.  

[Jez]

Dna cost might punish bots that are less well written or evo bots (like Carlos's one at bottom of F1 atm). I'm happy to wait for a combat bot designer to add their 2 cents though.

[Numsgil]

If you want to add a very mild cost to speed up starvation matches, that's fine.  But it should only be the deciding factor for starvation matches.

I would also use the body upkeep for it.  You'd want the same upkeep cost between 10 bots with 100 body and 1 bot with 1000 body so you don't create any additional pressures between slow reproducers that bulk up and fast reproducers that don't.

[Jez]

If we use body won't that encourage bots to have less body?

I was thinking of a standard cost/bot/cycle something like 0.1 nrg per turn. (or less if you feel that is to high)

A sort of upkeep cost that I figured most organisms need to spend to mantain their cell integrity.

[Numsgil]

But there's also a large advantage to have more body, since it increases your shot strength.  A tax on each individual is going to cause more burden on bots like dominator invincibalis than something like Ymir.  But a very small tax on body is, in my mind, the most even way to tax.

Maybe we could also do a tax per species, that all individuals in a species share.

[Jez]

Valid points;

A tax per individual would discriminate against faster reproducing or larger populace bots, (the advantage through numbers idea), although I was thinking of it as cost for upkeep. (for cells).

A tax per species, though very beguiling, would discriminate in the opposite direction perhaps. Then again, as you point out, there is a distinct advantage to have a large body and maybe the upkeep for a large body should be larger.

Doing both, as you suggested, might be a sound compromise.

[Numsgil]

Certainly we can tweek once we find an example of a bot winning with taxes when it couldn't win without.

[Jez]

So have you had any idea about what these costs should be?

0.1 per bot/cycle
1 per species/cycle?

That would mean the five bots of a species at the start would be paying a cost per cycle of 0.3. It seems a bit higher than intended. Don't know how small you can make the fractions of energy before the program will just ignore it.

[Numsgil]

I would do .00001 nrg per body and .01 nrg per bot to start with and see what that does.

[Jez]

I'm happy with that.

[EricL]

Okay.  2.42.9p and beyond, F1 mode sets 0.00001 nrg/body/cycle and 0.01 nrg/cycle costs in addition to the other F1 costs.

Don't know how small you can make the fractions of energy before the program will just ignore it.

The program never igores.  The UI will round in the display, so the nrg may not appear to drop every cycle if costs are very very low, but the program always does the math and nrg is actually dropping even when too slow to see in the UI...  

[Numsgil]

I once set the DNA upkeep to something like .000 000 000 1 or something like that.  I don't think any of my bots ever lost nrg.  If you get a half second, can you check on this?

[Sprotiel]

I once set the DNA upkeep to something like .000 000 000 1 or something like that.  I don't think any of my bots ever lost nrg.  If you get a half second, can you check on this?

That's 10^-10 ! No wonder you didn't see any effect: say your bots have a 1000-blocks DNA, and live 100 000 turns, over the course of their life, they'll have lost 10^3 * 10^5 *10^-10 = 0.01 energy.

[Numsgil]

This was in a very long term sim where I would get a million cycles an hour.  Even after millions of cycles bots would still have 30 000 nrg, where they started.

[EricL]

I once set the DNA upkeep to something like .000 000 000 1 or something like that.  I don't think any of my bots ever lost nrg.  If you get a half second, can you check on this?

I looked at this and I think I fixed this farily recently.  In several routines, Upkeep() amoung them, local temp varibles of type Long were being used where Sinlge types should have been.  This resulted in rounding or in some cases overflows when very large or very small values were assigned.  My guess is that your small cost value got rounded to 0 in the assignment.  Pretty sure this won't happen today since I recently (like maybe a month ago) did a comprehensive look though all the source for such Single->Long assignments and fixed this one (and a bunch of others).