Darwinbots Forum
Code center => Suggestions => Topic started by: Light on December 04, 2006, 06:57:55 PM
-
Jez's high level of work recently (and persistant nagging about leagues not working ) has inspired me to try and work through all the settings. It would be good to have a few days for any discussion before setting them in stone.
Settings for Leagues
Species
Number of individuals = 5
Starting energy = 3000
Mutations = All Disabled
General
Width Control
Field size = 1 (9237 X 6928)
Random Numbers
Enable user seed = No
Wrap Around
Toroidal = Yes
Top/down wrap = Yes
Left/right wrap = Yes
Waste
Threshold = 0 / very big (whatever disables it)
Misc Controls
Disable Ties = No
Nrg shots no decay = No
Fix bot radii = No
Corpse Mode
Enable = No
Population Control
Pond mode = No
Maximum number of veggies = 25
Repopulation threshold = 10
Veggies per repopulation event = 10
Repopulation cooldown period = 1
Veggy Energy = 40 - Veggy per cycle
Energy Management = No
Veg body/Nrg distribution = 50
Physics and Costs
Big Blue Screen Acts Like = Solid - Metal
Movement Efficiency = Biological
Brownian Movement = Animal
Vertical Gravity = None
Max Velocity = 180 (Fast)
Collision = 1 (Marbles)
Costs = F1 Default
Energy Exchanged on Hit = Proportional – 100%
-
As of 2.42.9i, selecting F1 Contest conditions on the league dialog now forces the settings as Light indicates. Here's the code:
If TmpOpts.F1 = True Then
'Zero out all Costs
For t = 1 To 70
TmpOpts.Costs(t) = 0
Next t
'Now set the ones that matter
TmpOpts.Costs(SHOTCOST) = 2
TmpOpts.Costs(COSTSTORE) = 0.04
TmpOpts.Costs(CONDCOST) = 0.004
TmpOpts.Costs(MOVECOST) = 0.05
TmpOpts.Costs(TIECOST) = 2
TmpOpts.Costs(SHOTCOST) = 2
TmpOpts.Costs(VENOMCOST) = 1
TmpOpts.Costs(POISONCOST) = 1
TmpOpts.Costs(SLIMECOST) = 1
TmpOpts.Costs(SHELLCOST) = 1
TmpOpts.Costs(COSTMULTIPLIER) = 1
TmpOpts.DynamicCosts = False
TmpOpts.CorpseEnabled = False ' No Corpses
TmpOpts.DayNight = False ' Sun never sets
TmpOpts.FieldWidth = 9237
TmpOpts.FieldHeight = 6928
TmpOpts.FieldSize = 1
TmpOpts.MaxEnergy = 40 ' Veggy nrg per cycle
TmpOpts.MaxPopulation = 25 ' Veggy max population
TmpOpts.MinVegs = 10
TmpOpts.Pondmode = False
TmpOpts.PhysBrown = 0 ' Animal Motion
TmpOpts.Toroidal = True
TmpOpts.BadWastelevel = -1 ' No Waste Threshold
' Nobody fixed
For t = 0 To TmpOpts.SpeciesNum - 1
TmpOpts.Specie(t).Fixed = False
Next t
TmpOpts.FixedBotRadii = False
TmpOpts.NoShotDecay = False
TmpOpts.DisableTies = False
TmpOpts.RepopAmount = 10
TmpOpts.RepopCooldown = 1
TmpOpts.MaxVelocity = 180
TmpOpts.VegFeedingMethod = 0 ' Straight nrg /cycle feeding method
TmpOpts.VegFeedingToBody = 0.5 ' 50/50 nrg/body veggy feeding ratio
TmpOpts.SunUp = False ' Turn off bringing the sun up due to a threshold
TmpOpts.SunDown = False ' Turn off setting the sun due to a threshold
TmpOpts.CoefficientElasticity = 1 ' Marbles
TmpOpts.Ygravity = 0
' Surface Friction - Metal Option
TmpOpts.Zgravity = 2
TmpOpts.CoefficientStatic = 0.6
TmpOpts.CoefficientKinetic = 0.4
'No Fluid Resistance
TmpOpts.Viscosity = 0#
TmpOpts.Density = 0#
DispSettings
End If
-
Jeez Eric,
Do you have a nitro button installed on you somewhere? Just over 3 hrs!
Thanks for trolling through all the settings Light, I shall grab Eric's handy little buddy drop in a while and try the running the previous losers with these settings. So long as most of the bots still work using these settings it'll be fine.
I think my physics and cost settings were different to what you've suggested and hopefully that was what was causing the problems.
-
Ok, that looked a bit strange, partly 'cause bots and veg can change size now also it looked like some of the bots had real problems traveling (previous top speed was about 40 I think) unless they were barged by another, faster, bot in which case they seemed to scoot across the screen. Sometimes the bots crawl inside a veg and then explode into babies.
It didn't do much good for the previous loser bots. (I tested the first five or six again)
Putting myself out on a limb here; the common them seems to be that tie bots generally cope and shot bots generally can't get food. Even if they sit by a veg shooting it they go 'pop' after a short while. In fact I think all the bots that survived the first league tests I ran were tie bots.
Can anyone suggest a shot bot that works for them under F1 conditions using the latest buddy drop? That way I'll have a point of reference.
I'd be happy with those settings if everyone else is.
-
Go to the costs page. There should be a setting about what shots return. Select proportional, and set it to 100 instead of 0.
For some reason, it keeps defaulting to 0. 0 is bad, as you've found out.
-
Mine was set at 'fixed' and 0
Also running a shot bot with F1 conditions for a while to see how it coped when that was changed showed two things;
1. They mutated
2. The marble physics put shot bots at a disadvantage, I think the collision elasticity needs to be softer. Maybe a 1/3rd of what it is.
Thanks Nums for working out what was causing me problems.
-
Im not sure that its the marble physics that are the problem, I think its the fact that with max velocity at 180 bots are travellling a lot faster than they did in previous versions, where a bot might be lucky to reach 40. Maxvel used to be governed by the size of the bot but now seems to be governed by the program, im not sure. With the added velocity its harder to hit moving bots.
-
Max vel is set in/by the program. It is the same for all bots and independent of their size. If friction and fluid resistance is low, bots can obtain the maximum velocity through continued acceleration. The cost charged for accelerating is scaled by the acceleration request amount (accelerating more in a cycle costs more) but is not currently a function of bot mass (though the degree to which a bot is slowed by friction and/or fluid resistance is - larger/heavier bots are slowed more). It probably should be.
-
In the end making bots' sysvars kinematic probably makes more sense than making them dynamic. That is, bot sysvars should code for actions, not effort.
-
I'm not sure it's the max vel, I like the idea of giving them a much larger range of speed and anyway a lot of recent bots (mine anyway) use *.maxvel? to set their speed. The problem I saw was that when bots hit a veg with 'marble' collisions, the veg sped away at the same speed. A tie bot doesn't have that problem because it ties to the veg and minimises the escape velocity of the veg.
Certainly when I set the collisions to ~1/3rd the shot bot I was testing managed to survive a little better. With 'marble' collisions you are pretty much forcing the shot bots to have a 'non collision' routine.
Although tie bots are F1 and shot bots F2 it would be nice to see the F1 league shared between them, tie bots shouldn't have a distinct advantage over the F2 bots. (I am F2 biased though )
-
The problem I saw was that when bots hit a veg with 'marble' collisions, the veg sped away at the same speed. A tie bot doesn't have that problem because it ties to the veg and minimises the escape velocity of the veg.
Right now the league code forces the veg to be unfixed. I could change that to be fixed or make it under the control of the user....
Also happy to change the coeffecient of elasticity so collisions are less elastic. Whatever people want.
-
I think it depends on the bot, newer bots tend to have something like *.eye5 50 > .... *.refvelup .up store to stop them ramming veg, Excalibur + Ymir do this off the top of my head. Older bots didn't really slow down quickly when approaching vegs, which was okay in 2.37 when they might make 30 max, but now they go much faster its causing problems. Im happy for collisions to change if you want, to try and balance things.
-
Right now the league code forces the veg to be unfixed. I could change that to be fixed or make it under the control of the user....
Also happy to change the coeffecient of elasticity so collisions are less elastic. Whatever people want.
Having fixed veg is not a good idea, we want the league settings to imitate the original setting for the leagues as best as they can.
I'd appreciate the collision elasticity to be severly reduced though, min 1/3 orf what it is or less. Also fixing the 'energy exchanged 0' to 'proportional 100%' plus checking that mutations are defaulted to off.
Part of the problem is that we shouldn't punish older bots for not having a collision routine because it didn't used to be needed, it should be an advantage not a necessity.
-
I'd appreciate the collision elasticity to be severly reduced though, min 1/3 orf what it is or less. Also fixing the 'energy exchanged 0' to 'proportional 100%' plus checking that mutations are defaulted to off.
2.42.9j will be as you say.
-
I think old bots suffer from not using refvelup + refveldx, they go flying a long see an object, turn to face it and their momentum carries them straight past it. Not a lot you can do except maybe increase friction, but even then I dont think it helps that much
-
2.42.9j will be as you say.
Aah crikey, I's and j's look so similar that had me confused
Tyvm Eric
Light; bots have suffered from not using a sideways detection to compensate forwards movement for as long as I can remember, (when I was a lad...) not a problem as I see it. F2 bots not being able to feed off veg they have knocked is.
-
As long as we have settings that most of the bots work reasonably well in thats okay, given that collision works from ghost -1 to marbles +1, what sort of value are we looking at 0.3 maybe 0.2?
-
I'm wondering how much difference using the metal background makes. As an F2 afficionado I guess the bots would cope with a fairly low collision setting. I'll run a few sims later and see what looks most familiar.
If anyone sees PY bend his ear about it, he is the default designer of leagues after all...
-
Would anyone be opposed to my forcing the first bot in the species list to be the veg and disabling it's DNA when running leagues? I keep forgetting to make the first bot an autotrof as I'm testing leagues.
By disabling the bot's DNA, it wouldn't matter what bot people used as a veggy to run leages - any bot would do and the result would always be the same for everyone since the thing would essentially be a non-reproducing, non-executing autoroptic empty husk. Veggy repopulation would be the sole means for veggies coming into the sim.
-
There are a small handful of bots that use the fact that refeyes for veggies are 0, and things like that. If those properties stayed in tact, it's probably find to forego DNA execution.
-
Would that not stop veg multiplying? Growing patches of veg are sometimes an important part of the league sim, such as when bots have just had a big battle and the last few survivors are desperately running around trying to find food.
On the other hand it might reduce the randomness of the league, which would be a good thing. Plus it would speed the league up, although with the max bot speed of 180 I can barely keep track of what they are doing anyway.
Certainly putting the veg alga minimalis (agree with nums about the veg recognition for some bots) in the league settings as a default or something would be great. I'll try disabling the veg dna and see how it affects competitors.
EDIT
Light, I think a collsion value of 0 would be about right. A lot of bots are going to have a hard time with the new top speeds and might find it easier with a lower value than this but it looks about the same as it used to be then.
Eric, switching off the veg dna made me laugh. Looking into my crystal ball I forsee that forcing totally new behaviour patterns to arise. Predominantly symbots or food protectors winning hands down and ambush predator bots losing. Also a greater advantage to bots that stop by their food rather than bump it. It certainly would make the leagues interesting but would probably preceed a mass extinction event. Perhaps the sort of punctuated equilibrium that DB would benefit from. I will go with mass opinion on this idea.
-
It's the kind of thing that can easily be changed later as we gather more data. Anyone who wants to run a league with the DNA disabled for the veggy can do so.
So, to be clear, I will be forcing the veg option upon the first entry in the species dialog but I will NOT be disabling it's DNA. Additionally, I am leaving the max speed up high at 180, but will be reducing the collision elasticity to 0.
-
Just want to check that people want absolutly no brownian motion when running leagues, correct? I ask because when you enter a a couple of very stupid bots that don't move when they can't see anything, it can take them a long time to die with F1 costs. Adding a little brownian motion would allow them to slowly drift around until they see something. Not critical probably. Just checking.
-
Should be fine without brownian motion. Bots have to wait for veg to reproduce and get close enough if they are that stupid and not already been wiped out by a competitor.
-
Can the league settings have waste back pls, max value or something, it's just otherwise every time I run into a big Bertha type bot running the leagues it's going to take hours or maybe days to run one match. Reaching max waste seems to take ages as well but it was certainly quicker.
I missed the altzheimer effect...
-
Do you want it forced to some value or free to be set by the user running the league?
-
Forced so all league matches are the same. If anyone's got a better suggestion for how to do it or what value to set then they can speak up before you change it.
3.2.1...
-
How about I set it to 10000. That is high enough that reletivly fast reproducing bots without a waste handling gene, which I think covers a lot of older bots, won't be adversely effected but it should help considerably with big bertha stalemates.
-
Sounds reasonable to me, (biased I admit as I'm running the matches), and seeing as nobodies questioned the idea that motion is passed.
-
er new problem, I have Devious E acting as a gentle giant and I. Venia that loses no energy whatsover when it is sitting still. Some of them have as little as 12 nrg, and are already several 1000 years old. Plus Devious uses viruses that have inactivated all the I. venia's...
What do you think about adding a very modest cost per turn to the leagues?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Certainly we can tweek once we find an example of a bot winning with taxes when it couldn't win without.
-
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.
-
I would do .00001 nrg per body and .01 nrg per bot to start with and see what that does.
-
I'm happy with that.
-
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...
-
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 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.
-
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.
-
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).
-
It was in one of the older buddy drop versions because I hadn't upgraded yet. So that might be it.